如今，軟件供應鏈攻擊已經(jīng)變得非常普遍，研究公司Gartner甚至將其列為“2022年第二大威脅”。Gartner預測，到2025年，全球45%的企業(yè)將經(jīng)歷一次或多次軟件供應鏈攻擊——82%的首席信息官認為他們將很容易受到此類攻擊影響。這包括通過廣泛使用的軟件組件(如Log4j)中的漏洞進行的攻擊，針對構(gòu)建管道的攻擊(c.f.、SolarWinds、Kaseya和Codecov黑客攻擊)，或者攻擊破壞包存儲庫本身。

Cycode的首席執(zhí)行官Lior Levy解釋道，“攻擊者已經(jīng)把重點從生產(chǎn)環(huán)境轉(zhuǎn)移到軟件供應鏈，因為軟件供應鏈是最薄弱的環(huán)節(jié)。只要軟件供應鏈仍然是相對容易被攻擊的目標，軟件供應鏈攻擊就會不斷增加。”

Aqua Security公司負責戰(zhàn)略的高級副總裁Rani Osnat表示，最近備受關(guān)注的事件為軟件開發(fā)行業(yè)敲響了警鐘。它向我們揭露了該行業(yè)幾十年來存在的不透明或缺乏透明度問題，這無疑是一件值得關(guān)注的大事。

針對使用開放源代碼的代碼庫的研究表明，漏洞和過時或廢棄的組件是十分常見的：81%的代碼庫至少有一個漏洞;50%有一個以上的高風險漏洞;88%使用的組件并非最新版本或在兩年內(nèi)沒有新的開發(fā)程序。

不過，這些問題不太可能削弱開源的流行——商業(yè)軟件和服務也很脆弱。當LastPass受到攻擊時，它并沒有丟失客戶數(shù)據(jù)，但未經(jīng)授權(quán)的一方能夠查看和下載它的一些源代碼，這可能使它更容易在未來攻擊密碼管理器的用戶，而Twilio漏洞使攻擊者能夠?qū)ο掠纹髽I(yè)發(fā)起供應鏈攻擊。

“影子代碼”威脅

就像安全團隊在“假設網(wǎng)絡已被攻破”的情況下實施保護一樣，CIO也必須假設所有的代碼(內(nèi)部和/或外部的)甚至開發(fā)人員使用的開發(fā)環(huán)境和工具都已經(jīng)被攻破，并制定相應的策略來防止和最小化對其軟件供應鏈的攻擊影響。

事實上，Osnat建議CEO應該用對待“影子IT”的方式來看待這種“影子代碼”。他認為，“這不僅僅是一個安全問題，而且是真正深入到你如何獲得軟件(無論它是開源的還是商業(yè)的)的問題：你如何把它帶到你的環(huán)境中?你如何更新它?你想要有什么樣的控制措施?你想要從你的供應商那里要求什么樣的控制措施等?”

透明度：面向軟件材料清單(SBOM)

實體供應鏈已經(jīng)使用標簽、成分表、安全數(shù)據(jù)表和材料清單，以便監(jiān)管機構(gòu)和消費者了解產(chǎn)品的最終組成部分。新的計劃旨在將類似的方法應用到軟件中，以幫助企業(yè)理解其軟件開發(fā)過程的依賴項網(wǎng)絡和攻擊面。

白宮關(guān)于軟件供應鏈安全的《14028號行政命令》要求為聯(lián)邦政府供貨的軟件供應商提供軟件材料清單(SBOM)，并使用軟件工件(SLSA)的供應鏈級別安全檢查表，以防止篡改。正因為如此，F(xiàn)orrester高級分析師Janet Worthington表示，“我們看到許多企業(yè)更加認真地看待他們的軟件供應鏈。如今所有的公司都在生產(chǎn)和消費軟件，我們看到越來越多的生產(chǎn)商來找我們，問我們，‘我怎樣才能生產(chǎn)出安全的軟件，并使用軟件材料清單來證明?！?/p>

除此之外，還有許多跨行業(yè)的項目，包括NIST的改善供應鏈網(wǎng)絡安全國家倡議(NIICS)，來自微軟和其他IETF成員的供應鏈完整性、透明度和信任倡議(SCITT)，以及OpenSSF供應鏈完整性工作組。

Worthington表示，“如今，每個人都在采取一種更全面的方法，他們會說，‘等一下，我需要知道我要把什么東西帶進我的供應鏈?！?/p>

Linux基金會最近的一項調(diào)查發(fā)現(xiàn)，SBOM的認知度很高，47%的IT供應商、服務提供商和受監(jiān)管的行業(yè)目前使用SBOM;88%的人預計在2023年使用SBOM。

Worthington補充道，SBOM對于已經(jīng)擁有軟件組件和API資產(chǎn)管理的企業(yè)來說是最有用的。如今，擁有強大軟件開發(fā)流程的人已經(jīng)發(fā)現(xiàn)，插入能夠生成軟件材料清單的工具更容易。

SBOM可以由構(gòu)建系統(tǒng)創(chuàng)建，也可以由軟件組合分析工具在事后生成。許多工具可以集成到CI/CD管道中，并作為構(gòu)建的一部分運行，甚至當你下拉庫時也可以運行。它可以警告你：“嘿，你的管道中有這個組件，它有一個關(guān)鍵問題，你想繼續(xù)嗎?”

Chainguard首席執(zhí)行官Dan Lorenc表示，要讓這種做法發(fā)揮作用，就需要明確開發(fā)團隊如何獲取開源軟件的政策。開發(fā)人員如何知道他們公司的“安全”政策是什么?他們?nèi)绾沃浪麄冋谫徺I的開源軟件(這些軟件構(gòu)成了目前開發(fā)人員使用的絕大多數(shù)軟件)確實沒有被篡改?

他提到了開源的Sigstore項目，JavaScript、Java、Kubernetes和Python都使用這個項目來建立軟件包的來源。他表示，“Sigstore之于軟件完整性，就像證書之于網(wǎng)站;他們基本上建立了一個監(jiān)管鏈和信任驗證系統(tǒng)?！?/p>

Lorenc建議稱，CIO應該首先向他們的開發(fā)團隊灌輸這些基本步驟，一是使用新興的行業(yè)標準方法，鎖定構(gòu)建系統(tǒng);二是在將軟件工件引入環(huán)境之前創(chuàng)建一種可重復的方法來驗證軟件工件的可信性。

資金預算

Worthington指出，無論是組件、API還是無服務器功能，大多數(shù)企業(yè)都低估了他們正在使用的東西的數(shù)量級，除非他們進行例行盤點。他們會發(fā)現(xiàn)一些API沒有使用適當?shù)恼J證方法，或者可能沒有按照他們預期的方式編寫，甚至可能有些API已經(jīng)被棄用。

除了漏洞之外，評估軟件包背后的支持社區(qū)與理解代碼的功能同樣重要，因為并非所有的維護人員都希望自己的代碼被視為關(guān)鍵資源。

Worthington解釋稱，“開源軟件可以免費下載，但它的使用當然不是免費的。你使用它意味著你有責任了解它背后的安全態(tài)勢，因為它在你的供應鏈中。你需要回饋它。你的開發(fā)人員需要參與修補漏洞。因此，建議企業(yè)應該準備好提供資金，要么直接給開源項目，要么用資源和資金支持他們的計劃。當你制定一個開源戰(zhàn)略時，其中的一部分是了解預算和影響?！?/p>

不要將這視為一筆開銷，而是一個更好地理解你所依賴的組件的機會。它甚至有助于留住開發(fā)者，因為他們覺得自己是社區(qū)的一部分。他們能夠貢獻自己的技能。他們可以在簡歷上用到這一點。

請記住，漏洞可以在你技術(shù)堆棧的任何地方找到，包括大型機，它們越來越多地運行Linux和開源作為工作負載的一部分，但通常缺乏在其他環(huán)境中已變得常見的安全流程和框架。

保護你的管道

保護你的軟件交付管道也很重要。NIST的安全軟件開發(fā)框架(SSDF)和SLSA就是一個很好的起點：它涵蓋了不同成熟度級別的最佳實踐，從一個簡單的構(gòu)建系統(tǒng)開始，然后使用日志和元數(shù)據(jù)進行審計和事件響應，直到一個完全安全的構(gòu)建管道。此外，CNCF的軟件供應鏈最佳實踐白皮書、Gartner關(guān)于減少軟件供應鏈安全風險的指南以及微軟的OSS安全供應鏈框架(包括過程和工具)也很有幫助。

然而，需要注意的是，簡單地打開旨在發(fā)現(xiàn)惡意代碼的自動掃描工具可能會產(chǎn)生太多的誤報，從而無法提供真正地幫助。盡管像BitBucket、GitHub、GitLab等版本控制系統(tǒng)包括安全和訪問保護功能(包括越來越細粒度的訪問策略控制、分支保護、代碼簽名、要求所有貢獻者使用MFA以及掃描秘密和憑證)，但它們通常必須顯式啟用(explicitly enabled)。

此外，像“可重復安全創(chuàng)建工件工廠”(Factory for Repeatable Secure Creation of Artifacts，F(xiàn)RSCA)這樣旨在通過在單個堆棧中實現(xiàn)SLSA來保護構(gòu)建管道的項目，還沒有準備好投入生產(chǎn)，但CIO應該期望構(gòu)建系統(tǒng)在未來包含更多這樣的實踐。

實際上，雖然SBOM只是解決問題的一部分，但是創(chuàng)建和使用它們的工具也在不斷成熟，請求和使用它們的過程也是如此。Worthington建議，合同不僅需要明確你想要SBOM，還需要明確你希望它們多長時間更新一次，以及它們是否將包括漏洞報告和通知。例如，如果發(fā)現(xiàn)像Log4j這樣的新的重要漏洞，供應商會告訴我嗎?還是我必須在SBOM中搜索，看看是否受到了影響?

企業(yè)還需要工具來讀取SBOM，并制定流程來對這些工具發(fā)現(xiàn)的內(nèi)容采取行動。Worthington表示，“我需要一種工具，它能告訴我SBOM中已知的漏洞是什么，許可證的影響是什么，以及這種情況是否持續(xù)發(fā)生?！?/p>

Osnat補充道，CIO應該記住，SBOM只是一個使能者(enabler)，實際上并不能解決任何問題，以確保你的供應鏈安全。它只能幫助你應對可能發(fā)生的事件。不過，Osnat對行業(yè)響應的速度和圍繞SBOM標準及代碼認證正在進行的廣泛合作持樂觀態(tài)度，他認為這將有助于使工具更具互操作性，進而改善整個行業(yè)的透明度和報告標準化，就像SOC 2所帶來的結(jié)果一樣。

Osnat表示，盡管如此，CIO并不需要等到新的標準或工具才開始讓安全成為開發(fā)人員的一部分。CIO應該先和首席工程師們溝通，找出適合企業(yè)的正確模式，并仔細研究如何實踐這種變革以及變革可能帶來的影響。