作者 | Mary Branscombe

譯者 | 張增斌

　　超過90%的軟件應用程序使用開源組件，與開源軟件相關的依賴關系和漏洞極其復雜。使用開源軟件能夠提高開發人員的開發效率，但不意味著更加安全。在數字化轉型加速的當下，在推動創新的過程中，開源的復雜性和開發速度限制了軟件供應鏈安全控制的有效性。

　　軟件供應鏈攻擊變得如此普遍，以至于Gartner將其列為2022年的第二大威脅。據研究預測，到2025年，全球45%的組織將會遭受一次或多次軟件供應鏈攻擊，82%的CIO認為他們將更容易受到攻擊。這些攻擊包括通過廣泛使用的軟件組件(如Log4j)中的漏洞進行的攻擊，對構建管道的攻擊(例如：SolarWinds、Kaseya和Codecov黑客攻擊)，或黑客破壞軟件包存儲庫本身。

　　Cycode首席執行官Lior Levy解釋道：“攻擊者已經將優先級從生產環境轉移到軟件供應鏈，因為軟件供應鏈是最薄弱的環節。”，“軟件供應鏈仍然是相對容易攻擊的目標，軟件供應鏈攻擊依然會不斷增加。”

　　最近備受矚目的事件給軟件開發行業敲響了警鐘，Aqua Security戰略高級副總裁Rani Osnat說。“我們已經發現了幾十年來的不透明和缺乏透明度，這就是為什么它如此重要”。

　　對使用開源代碼的代碼庫的研究表明，漏洞和過時或廢棄的組件很常見：81%的代碼庫至少有一個漏洞，50%的代碼庫有多個高風險漏洞，88%的代碼庫使用的組件不是最新版本或兩年內沒有進行更新開發。

　　但是這些問題不太可能削弱開源的普及。當LastPass受到攻擊時，它不會丟失客戶數據，但未經授權的一方能夠查看和下載它的部分源代碼，這可能會使將來更容易攻擊密碼管理器的用戶，而Twilio漏洞使攻擊者能夠對下游組織發起供應鏈攻擊。

警惕“影子代碼”的威脅

　　CIO需要考慮到最糟糕的狀況：假設所有代碼，無論是內部還是外部，甚至他們的開發人員使用的開發環境和工具都已經受到破害，從而來制定相應的政策來保護他們的軟件供應鏈免受攻擊并將其影響降至最低。

　　事實上，Osnat建議CIO們像對待影子IT一樣思考“影子代碼”的潛在風險（在沒有 IT 監督或安全審查的情況下添加的腳本和庫）。他說：“這不僅僅是一個安全問題，而是一個需要你深入考慮如何獲得軟件的問題，無論是開源的還是商業的：你如何把它引入你的環境，你如何去更新它，你想要什么樣的控制措施，你想從你的供應商那里獲得什么樣的。”

提升透明度：推廣使用軟件物料清單

　　物理供應鏈已經使用標簽、配料表、安全數據表和物料清單，因此監管機構和消費者知道產品最終會出現什么結果。新計劃旨在將類似的方法應用于軟件，幫助組織了解依賴關系網絡及其軟件開發過程的攻擊面。

　　白宮關于軟件供應鏈安全的第14028號行政命令要求為聯邦政府提供服務的軟件供應商提供軟件物料清單(SBOM)，并使用軟件工件的供應鏈級別(SLSA)安全清單來防止篡改。正因為如此，“我們看到很多企業更加認真地看待他們的軟件供應鏈”，Forrester高級分析師Janet Worthington表示：“現在所有的公司都生產和消費軟件，我們看到越來越多的生產商來找我們說，‘如何生產安全的軟件，我可以用軟件物料清單來證明’。”。

　　有許多跨行業項目，包括NIST的全國供應鏈網絡安全改善計劃(NIICS)，微軟和其他IETF成員的供應鏈完整性，透明度和信任計劃(SCITT)，以及OpenSSF供應鏈完整性工作組。

　　Worthington說:“每個人都在采取更全面的方法，并說，等一下，我需要知道我將什么帶入我的供應鏈，我正在用什么來創建軟件”。

　　Linux基金會最近的一項調查發現，采用軟件物料清單的意識很高，目前有47%的IT供應商、服務提供商和受監管行業使用SBOM，88%的人預計在2023年使用SBOM。

　　SBOM對于已經擁有軟件組件和API資產管理的組織最為有用。Worthington說：“今天擁有強大軟件開發流程的人們會發現，插入可以生成軟件物料清單的工具更容易”。

　　SBOM可以由構建系統創建，也可以事后由軟件組合分析工具生成。她說，許多工具可以集成到CI/CD管道中，并作為構建的一部分運行，甚至當你移除庫也可以運行。“它可以警告你：'嘿，你的管道中有這個組件，它有一個關鍵問題，你想繼續嗎？'”

　　Chainguard首席執行官Dan Lorenc表示：“為了使這一點有用，你需要明確你的開發團隊如何獲取開源軟件的政策”，“開發人員如何知道他們公司的政策是什么，什么被認為是‘安全的’？他們如何知道他們正在購買的開放源碼(這是目前開發人員使用的所有軟件中的絕大多數)確實沒有受到任何損害？”

　　他指出了JavaScript、Java、Kubernetes和Python用來建立軟件包的開源Sigstore項目。他說：“Sigstore對軟件的完整性就像證書對網站一樣；它們基本上建立了一個托管鏈和信任驗證系統。”

　　Lorenc說：“我認為CIO應該首先向他們的開發團隊灌輸這些基本步驟：一是使用新興的行業標準方法，鎖定構建系統；二是創建一種可重復的方法，在將軟件構件引入環境之前驗證其可信性。”

為你使用的開源組件做出貢獻

　　Worthington指出，無論是組件、API還是無服務器功能，大多數組織都會低估他們正在使用的功能，除非他們進行常規盤點。她說：“他們發現其中一些API沒有使用正確的身份驗證方法，或者可能沒有按照他們預期的方式編寫，甚至有些API已經被棄用”。

　　除了漏洞之外，評估軟件包背后的社區支持與了解代碼的作用同樣重要，因為并非所有維護者都希望將他們的代碼視為關鍵資源。“并非所有的開源都是一樣的，”她警告說。

　　Worthington表示：“開源可能可以免費下載，但使用它肯定不是免費的。你對它的使用意味著你有責任了解它背后的安全態勢，因為它在你的供應鏈中。你需要為它做出貢獻。你的開發者需要參與修復漏洞。”，他建議各組織也應準備好以貨幣形式捐款，要么直接向開源項目捐款，要么向其提供資源和資金支持的倡議捐款。“當你創建一個開源策略時，其中的一部分就是了解預算和影響。”

　　不要認為這僅僅是一筆開支，實際上這反而是一個更好地了解你所依賴的組件的機會。“這甚至有助于留住開發人員，因為他們會認為自己是社區的一部分。他們能夠貢獻自己的技能。他們可以在簡歷上使用這一點，”她補充道。

　　請記住，漏洞可以在你的技術堆棧中的任何位置找到，包括大型機，這些大型機越來越多地作為工作負載的一部分運行Linux和開源，但通常缺乏其他環境中常見的安全流程和框架。

保護你的軟件交付管道

　　保護你的軟件交付管道也很重要。NIST的安全軟件開發框架(SSDF)和SLSA是一個很好的起點：它涵蓋了各種成熟度級別的絕佳實踐，從簡單的構建系統開始，然后使用日志和元數據進行審計和事件響應，直到完全安全的構建管道。CNCF的軟件供應鏈最佳實踐白皮書、Gartner關于降低軟件供應鏈安全風險的指南以及包括流程和工具的微軟OSS安全供應鏈框架也很有幫助。

　　然而，重要的是要注意，僅僅打開旨在查找惡意代碼的自動掃描工具可能會產生太多的誤報而沒有幫助。盡管BitBucket、GitHub、GitLab等版本控制系統包括安全和訪問保護功能(包括越來越精細的訪問策略控制、分支保護、代碼簽名、要求所有貢獻者使用MFA以及掃描機密和憑據)，但它們通常必須顯式啟用。

　　此外，諸如可重復安全創建工件工廠(FRSCA)之類的項目旨在通過在單個堆棧中實現SLSA來保護構建管道，但CIO應該期望構建系統將來包含更多這些實踐。

　　事實上，雖然SBOM只是答案的一部分，但創建和使用它們的工具也在不斷成熟，請求和使用它們也在不斷完善。Worthington建議，合同不僅需要指定你想要的SBOM，還需要指定你希望它們更新的頻率，以及它們是否包括漏洞報告和通知。“如果發現像Log4j這樣的新的重要漏洞，供應商會告訴我嗎，還是我必須在SBOM中搜索自己，看看我是否受到影響？”

　　組織還需要工具來閱讀SBOM，并制定流程來對這些工具的發現采取行動。Worthington說：“我需要一個工具，它可以告訴我（SBOM）已知的漏洞是什么，許可證的影響是什么，以及這種情況是否會持續發生。”

　　CIO們應該記住，SBOM“是一個推動者，但實際上并不能解決任何問題，確保供應鏈的安全。它可以幫助你應對可能發生的事件”，Osnat說，他對行業響應速度以及圍繞SBOM標準和代碼認證進行的廣泛合作持樂觀態度，這將有助于使工具互操作（這是Linux基金會研究中組織提出的一個特別關注的問題）。這可能會導致整個行業的透明度和報告標準得到與SOC 2相同的改進。

　　Osnat表示，盡管如此，CIO們不必等待新的標準或工具來開始讓安全成為開發人員角色的一部分，因為近年來質量已經成為了一部分。他的建議是：“首先讓你的CISO和首席工程師坐在一個房間里，找出適合你的組織的模式，以及如何實現轉型。”

原文鏈接：

??https://www.cio.com/article/410904/the-new-cio-security-priority-your-software-supply-chain.html??

譯者介紹

張增斌，51CTO社區編輯，多年的安全攻防從業經驗，主要研究方向：安全開發、逆向破解、漏洞挖掘、黑灰產攻防對抗。