由於你的開發人員和系統提高生產力所依賴的東西充斥著如此多的未知因素 ─ 同樣的這些工具和程式庫輪番依賴的東西也面臨一樣的問題 ─ 所以現在該是認真思考如何確保軟體供應鏈安全的時候了。
文/Mary Branscombe‧譯/酷魯
開放原始碼深受當前企業歡迎的一個原因是,它提供了經過良好測試的組成元件,可以加速複雜應用程式和服務的開發。但是第三方廠商的軟體元件以及套件和容器的便利性在帶來好處的同時也帶來了風險,因為你所構建應用程式的安全性取決於這些相互依存元件的安全性。
軟體供應鏈攻擊(Software Supply Chain Attack)正變得如此普遍,以至於 Gartner 將其列為 2022 年的第二大安全威脅。該研究公司預測,到了 2025 年,全球 45% 的組織將經歷一次或多次軟體供應鏈攻擊,82% 的 CIO 資訊長認為他們很容易受到這類威脅的攻擊。這些攻擊包括透過廣泛使用之軟體元件(例如 Log4j)中的漏洞所進行的攻擊,還有針對 build pipeline 建置管線(例如 SolarWinds、Kaseya 和 Codecov 遭駭)的攻擊,抑或駭客入侵套件庫本身。
「攻擊者已經將優先攻擊的目標從生產環境轉移到軟體供應鏈,因為軟體供應鏈是最薄弱的環節,」以色列軟體供應鏈安全方案供應商 Cycode 執行長 Lior Levy 解釋說:「只要軟體供應鏈繼續成為相對容易攻擊的目標,那麼軟體供應鏈攻擊就會增加。」
[ 推薦閱讀:2023 金融及服務業 IT 投資重點 ]
最近一些備受矚目的安全事件無異為軟體開發產業敲響了警鐘,以色列雲端原生安全服務供應商 Aqua Security 資深策略副總裁 Rani Osnat 表示。「我們發現了幾十年來充滿不透明和缺乏透明度的狀況,而這也透露出軟體供應鏈安全為什麼如此重要的原因。」
針對使用開源程式碼之程式庫的研究表明,漏洞和過時或廢棄的元件很常見:81% 的程式庫至少有一個漏洞,50% 有一個以上的高風險漏洞,而且高達 88% 都是舊元件,它們不是最新版本,就是兩年內沒有新開發的元件軟體。
不過,這些問題不太可能削弱開放原始碼受歡迎的程度 ─ 因為商用軟體和服務也充滿許多安全漏洞。當熱門的密碼管理工具 LastPass 遭到攻擊時,其客戶資料並未因此外洩,但某個未經授權方卻能夠查看和下載它的一些原始程式碼,這可能會使該密碼管理工具的使用者未來會有更容易招致攻擊的安全風險,至於雲端通訊平台 Twilio 遭入侵事件則讓攻擊者能夠對攻應鏈下游的企業組織發起供應鏈攻擊。
「地下程式碼」威脅
就像安全團隊會假設自己已遭入侵般地防護他們的網路一樣,CIO 也必須假設所有的程式碼,內部或外部、甚至開發人員使用的開發環境和工具都已經遭到惡意劫持,如此才能完全落實安全政策,進而妥善防護,並將攻擊對他們軟體供應鏈的影響降至最低程度。
事實上,Osnat 建議 CIO 們用對待地下 IT (Shadow IT)的方式來看待這種「地下程式碼」(Shadow Code)問題。「我們需要認真看待的是,這不僅僅是一個安全問題,而是一個真正深入到你如何獲取軟體(無論是開放原始碼還是商用軟體)的問題:你如何將它導入到你環境中,如何更新,你希望有什麼樣到位的控制機制,你希望從供應商那裡得到什麼樣的控制措施,」他說。
透明度:面向軟體物料清單
實體供應鏈已經使用標章、成分表、安全資料表(Safety Data Sheet,SDS)和物料清單(Bill of Material,BOM),以便監管機構和消費者瞭解產品的最終物質成分為何。新的計畫旨在將類似的方法應用於軟體,幫助組織理解軟體組成元件之間的依存關係網(web of dependencies)和軟體開發過程中可能的攻擊面。
關於軟體供應鏈安全的美國白宮第 14028 號行政命令(EO 14028)要求軟體供應商向聯邦政府提供軟體物料清單,並使用「軟體製品供應鏈層級」(Supply Chain Levels For Software Artifacts,SLSA)的安全檢查表來防止篡改。,正因為如此,「我們看到很多企業開始更加認真地審視自己的軟體供應鏈,」市調機構 Forrester 資深分析師 Janet Worthington 表示。「今天所有公司會同時生產並使用軟體,我們看到越來越多的製造商來找我們說:『我如何製作安全的軟體,我可以用軟體物料清單來證明。』」
有許多跨產業專案,包括美國國家標準技術研究院(NIST)的「國家改善供應鏈網路安全倡儀」(National Initiative for Improving Cybersecurity in Supply Chain,NIICS),以及微軟和其他網際網路工程任務組(IETF)成員的「供應鏈完整性、透明度和信任」(SCITT)倡儀,以及開源軟體安全基金會(OpenSSF)的「供應鏈完整性工作小組」(Supply Chain Integrity Working Group)。
「每個人都在採取一種更全面的方法,他們並且說,等一下,我需要知道我要帶入到供應鏈中,並且用來開發軟體的是什麼東西,」Worthington 表示。
Linux 基金會最近的一項調查發現,人們對軟體物料清單的意識十分高漲,目前有 47% 的 IT 廠商、服務供應商和受監管產業正在使用軟體物料清單,同時有 88% 的人預計將在 2023 年使用軟體物料清單。
對於已經擁有軟體元件和應用程式介面(API)資產管理的組織來說,軟體物料清單將是最有用的。「如今,擁有強健軟體開發流程的人發現,嵌入能夠生成軟體物料清單的工具變得更容易,」Worthington 表示。
軟體物料清單可以由建置系統(build system)建立,也可以在事後由軟體組成分析(Software Composition Analysis,SCA)工具來產生。許多工具可以整合到持續整合與持續交付管道(CI/CD pipeline)中,並作為建置的一部分運行,甚至可以在你下拉函式庫時運行,她表示。「它可以警告你:『嘿!你的管線中有這個元件,它有一個非常重要待解的問題,你要繼續嗎?』」
要想讓這一點發揮作用,你需要制定明確的政策,規定開發團隊如何得到開放原始碼軟體,軟體供應鏈安全服務供應商 Chainguard 執行長 Dan Lorenc 表示。「開發人員要怎麼知道他們公司對於什麼被認為是『安全』的政策為何?他們又怎麼知道他們正在獲得的開放原始碼軟體(其構成了目前開發人員所使用軟體的絕大部分)確實沒有被篡改?」
他提到了開放原始碼 Sigstore 軟體認證專案,JavaScript、Java、Kubernetes 和 Python 使用該專案來建立套裝軟體的溯源。「Sigstore 之於軟體完整性,就像證書之於網站;他們基本上建立了一個監管鏈和信任驗證系統,」他進一步表示。
「我認為 CIO 應該首先向他們的開發團隊灌輸以下基本步驟:首先,使用新興的產業標準方法,鎖定建置系統;其次,在將軟體製品引進環境之前,建立一種可重複的方法來驗證這些軟體製品的可信度。」Lorenc 表示。
做出貢獻
大多數組織對於他們正在使用的元件、API 或無伺服器(Serverless)功能,莫不嚴重低估了一個量級,除非他們有進行例行的盤點,Worthington 指出。「他們發現其中一些 API 沒有使用正確的身分驗證方法,或者可能沒有按照他們期望的方式編寫,甚至可能有些 API 已經被棄用了,」她表示。
除了安全漏洞之外,評估套件背後的社群支持與理解程式碼的功能一樣重要,因為並非所有維護人員都想要有自己的程式碼被視為關鍵資源的負擔。「並不是所有的開放原始碼軟體都是一樣的,」她警告說。
「開放原始碼軟體可以免費下載,但使用它肯定不是免費的。你使用它意味著你有責任瞭解它背後的安全狀況,畢竟它就用在你的供應鏈之中。你需要有所回饋。你的開發人員需要參與安全漏洞的修復工作,」Worthington 表示,他建議組織也應該做好貢獻金錢的準備,要麼直接投注到開放原始碼專案,要麼推展透過資源和資金支援這些專案的計畫。「當你制定一個開放原始碼策略時,其中一部分就是要瞭解預算和可能的結果與影響。」
不要認為這只是一筆開支,而是一個更完美瞭解你所依賴元件的機會。「這甚至有助於留住開發人員,因為他們覺得自己是社群的一份子。他們能夠貢獻自己的技能。他們也可以在履歷上添上這筆貢獻經歷。」
請記住,安全漏洞可以在技術堆疊中的任何地方找到,包括大型主機(mainframe),雖然這些大型主機越來越多地將 Linux 和開放原始程式碼作為工作負載的一部分運行,但通常卻缺乏在其他環境中常見的安全流程和框架。
保護你的管線
保護你的軟體交付管線也很重要。NIST 的安全軟體開發框架(Secure Software Development Framework,SSDF)和 SLSA 是一個很好的起點:它涵蓋了各種成熟度等級的最佳實踐,從簡單的建置系統開始,然後使用日誌和詮釋資料(metadata)進行稽核和事件回應,直至全然安全地建置管道。雲端原生運算基金會(Cloud Native Computing Foundation,CNCF)的《軟體供應鏈最佳實踐》(Software Supply Chain Best Practices)白皮書、Gartner 關於降低軟體供應鏈安全風險的指南,以及包括流程和工具的微軟開放原始碼軟體(OSS)安全供應鏈消費框架(Secure Supply Chain Consumption Framework,S2C2F)也很有幫助。
但是,需要特別強調的是,僅僅打開旨在尋找惡意程式碼的自動掃描工具,很有可能會因為誤報太多,反而沒什麼作用與幫助。儘管 BitBucket、GitHub、GitLab 等版本控制系統包含了許多安全和存取保護功能(例如愈來愈精細的存取政策控制、分支防護、程式碼簽章、要求所有貢獻者使用 MFA 多因素身分驗證以及機密和憑證掃描等等),但它們通常必須明確啟用。
再者,像「可重複安全製品創造工廠」(Factory for Repeatable Secure Creation of Artifacts,FRSCA)這樣的專案,旨在透過在單一堆疊中落實 SLSA 來確保建置管線的安全,雖然這類專案還沒有為生產做好準備,但是 CIO 們應該期待建置系統在未來能涵蓋更多這樣的實踐。
[ 加入 CIO Taiwan 官方 LINE 與 Facebook ,與全球 CIO 同步獲取精華見解 ]
的確,雖然軟體物料清單只是答案的一部分,但是用於創造和使用軟體物料清單的工具,以及用於請求和使用軟體物料清單的流程,都還在不斷成熟之中。關於契約不僅需要明確指出你想要的軟體物料清單,還需要具體說明你希望它們多久更新一次,以及它們是否包含漏洞通報和通知,Worthington 建議道。「一旦發現了像是 Log4j 的新重大漏洞,供應商會告訴我,還是我必須在軟體物料清單中自我搜索一番以便看看是否受到漏洞攻擊?」
組織還需要工具來讀取軟體物料清單,並根據這些工具發現的內容來落實相應的流程。「我需要的工具是能告訴我(軟體物料清單中〕有什麼樣的已知漏洞,授權有什麼影響,以及這種情況是否會持續發生,」Worthington 表示。
CIO 們應該要記住的是,「軟體物料清單是一個賦能者,但它實際上並不能解決確保供應鏈安全方面的任何問題。它可以幫助你處理可能出現的安全事件,」Osnat 指出,他對產業回應的速度和以軟體物料清單標準為核心的廣泛合作,乃至有助於使工具具有互操作性的程式碼認證(其被一些企業組織當作一個特別關注的問題而在 Linux 基金會的研究中提出)都抱持樂觀的態度。這可能會導致整個產業透明度和報告標準方面出現和 SOC 2 系統與組織控制報告相同的改進。
Osnat 表示,也就是說,CIO 們不必等到新的標準或工具出現,才能像近年來品質問題一樣,讓安全成為開發人員職責的一部分。他的建議是:「首先讓你的資安長(CISO)和工程師主管同時聚在一個房間裡,共同找出適合你組織的正確模型,並一同釐清這種轉變是如何發生的。」
(本文授權非營利轉載,請註明出處:CIO Taiwan)