Cycode的首席執行官Lior Levy解釋道，“攻擊者已經把重點從生產環境轉移到軟件供應鏈，因為軟件供應鏈是最薄弱的環節。只要軟件供應鏈仍然是相對容易被攻擊的目標，軟件供應鏈攻擊就會不斷增加。”
Aqua Security公司負責戰略的高級副總裁Rani Osnat表示，最近備受關注的事件為軟件開發行業敲響了警鐘。它向我們揭露了該行業幾十年來存在的不透明或缺乏透明度問題，這無疑是一件值得關注的大事。
針對使用開放源代碼的代碼庫的研究表明，漏洞和過時或廢棄的組件是十分常見的：81%的代碼庫至少有一個漏洞;50%有一個以上的高風險漏洞;88%使用的組件并非最新版本或在兩年內沒有新的開發程序。
不過，這些問題不太可能削弱開源的流行——商業軟件和服務也很脆弱。當LastPass受到攻擊時，它并沒有丟失客戶數據，但未經授權的一方能夠查看和下載它的一些源代碼，這可能使它更容易在未來攻擊密碼管理器的用戶，而Twilio漏洞使攻擊者能夠對下游企業發起供應鏈攻擊。
“影子代碼”威脅
就像安全團隊在“假設網絡已被攻破”的情況下實施保護一樣，CIO也必須假設所有的代碼(內部和/或外部的)甚至開發人員使用的開發環境和工具都已經被攻破，并制定相應的策略來防止和最小化對其軟件供應鏈的攻擊影響。
事實上，Osnat建議CEO應該用對待“影子IT”的方式來看待這種“影子代碼”。他認為，“這不僅僅是一個安全問題，而且是真正深入到你如何獲得軟件(無論它是開源的還是商業的)的問題：你如何把它帶到你的環境中?你如何更新它?你想要有什么樣的控制措施?你想要從你的供應商那里要求什么樣的控制措施等?”
透明度：面向軟件材料清單(SBOM)
實體供應鏈已經使用標簽、成分表、安全數據表和材料清單，以便監管機構和消費者了解產品的最終組成部分。新的計劃旨在將類似的方法應用到軟件中，以幫助企業理解其軟件開發過程的依賴項網絡和攻擊面。
白宮關于軟件供應鏈安全的《14028號行政命令》要求為聯邦政府供貨的軟件供應商提供軟件材料清單(SBOM)，并使用軟件工件(SLSA)的供應鏈級別安全檢查表，以防止篡改。正因為如此，Forrester高級分析師Janet Worthington表示，“我們看到許多企業更加認真地看待他們的軟件供應鏈。如今所有的公司都在生產和消費軟件，我們看到越來越多的生產商來找我們，問我們，‘我怎樣才能生產出安全的軟件，并使用軟件材料清單來證明。’”
除此之外，還有許多跨行業的項目，包括NIST的改善供應鏈網絡安全國家倡議(NIICS)，來自微軟和其他IETF成員的供應鏈完整性、透明度和信任倡議(SCITT)，以及OpenSSF供應鏈完整性工作組。
Worthington表示，“如今，每個人都在采取一種更全面的方法，他們會說，‘等一下，我需要知道我要把什么東西帶進我的供應鏈。’”
Linux基金會最近的一項調查發現，SBOM的認知度很高，47%的IT供應商、服務提供商和受監管的行業目前使用SBOM;88%的人預計在2023年使用SBOM。
Worthington補充道，SBOM對于已經擁有軟件組件和API資產管理的企業來說是最有用的。如今，擁有強大軟件開發流程的人已經發現，插入能夠生成軟件材料清單的工具更容易。
SBOM可以由構建系統創建，也可以由軟件組合分析工具在事后生成。許多工具可以集成到CI/CD管道中，并作為構建的一部分運行，甚至當你下拉庫時也可以運行。它可以警告你：“嘿，你的管道中有這個組件，它有一個關鍵問題，你想繼續嗎?”
Chainguard首席執行官Dan Lorenc表示，要讓這種做法發揮作用，就需要明確開發團隊如何獲取開源軟件的政策。開發人員如何知道他們公司的“安全”政策是什么?他們如何知道他們正在購買的開源軟件(這些軟件構成了目前開發人員使用的絕大多數軟件)確實沒有被篡改?
他提到了開源的Sigstore項目，JavaScript、Java、Kubernetes和Python都使用這個項目來建立軟件包的來源。他表示，“Sigstore之于軟件完整性，就像證書之于網站;他們基本上建立了一個監管鏈和信任驗證系統。”
Lorenc建議稱，CIO應該首先向他們的開發團隊灌輸這些基本步驟，一是使用新興的行業標準方法，鎖定構建系統;二是在將軟件工件引入環境之前創建一種可重復的方法來驗證軟件工件的可信性。
資金預算
Worthington指出，無論是組件、API還是無服務器功能，大多數企業都低估了他們正在使用的東西的數量級，除非他們進行例行盤點。他們會發現一些API沒有使用適當的認證方法，或者可能沒有按照他們預期的方式編寫，甚至可能有些API已經被棄用。
除了漏洞之外，評估軟件包背后的支持社區與理解代碼的功能同樣重要，因為并非所有的維護人員都希望自己的代碼被視為關鍵資源。
Worthington解釋稱，“開源軟件可以免費下載，但它的使用當然不是免費的。你使用它意味著你有責任了解它背后的安全態勢，因為它在你的供應鏈中。你需要回饋它。你的開發人員需要參與修補漏洞。因此，建議企業應該準備好提供資金，要么直接給開源項目，要么用資源和資金支持他們的計劃。當你制定一個開源戰略時，其中的一部分是了解預算和影響。”
不要將這視為一筆開銷，而是一個更好地理解你所依賴的組件的機會。它甚至有助于留住開發者，因為他們覺得自己是社區的一部分。他們能夠貢獻自己的技能。他們可以在簡歷上用到這一點。
請記住，漏洞可以在你技術堆棧的任何地方找到，包括大型機，它們越來越多地運行Linux和開源作為工作負載的一部分，但通常缺乏在其他環境中已變得常見的安全流程和框架。
保護你的管道
保護你的軟件交付管道也很重要。NIST的安全軟件開發框架(SSDF)和SLSA就是一個很好的起點：它涵蓋了不同成熟度級別的最佳實踐，從一個簡單的構建系統開始，然后使用日志和元數據進行審計和事件響應，直到一個完全安全的構建管道。此外，CNCF的軟件供應鏈最佳實踐白皮書、Gartner關于減少軟件供應鏈安全風險的指南以及微軟的OSS安全供應鏈框架(包括過程和工具)也很有幫助。
然而，需要注意的是，簡單地打開旨在發現惡意代碼的自動掃描工具可能會產生太多的誤報，從而無法提供真正地幫助。盡管像BitBucket、GitHub、GitLab等版本控制系統包括安全和訪問保護功能(包括越來越細粒度的訪問策略控制、分支保護、代碼簽名、要求所有貢獻者使用MFA以及掃描秘密和憑證)，但它們通常必須顯式啟用(explicitly enabled)。
此外，像“可重復安全創建工件工廠”(Factory for Repeatable Secure Creation of Artifacts，FRSCA)這樣旨在通過在單個堆棧中實現SLSA來保護構建管道的項目，還沒有準備好投入生產，但CIO應該期望構建系統在未來包含更多這樣的實踐。
實際上，雖然SBOM只是解決問題的一部分，但是創建和使用它們的工具也在不斷成熟，請求和使用它們的過程也是如此。Worthington建議，合同不僅需要明確你想要SBOM，還需要明確你希望它們多長時間更新一次，以及它們是否將包括漏洞報告和通知。例如，如果發現像Log4j這樣的新的重要漏洞，供應商會告訴我嗎?還是我必須在SBOM中搜索，看看是否受到了影響?
企業還需要工具來讀取SBOM，并制定流程來對這些工具發現的內容采取行動。Worthington表示，“我需要一種工具，它能告訴我SBOM中已知的漏洞是什么，許可證的影響是什么，以及這種情況是否持續發生。”
Osnat補充道，CIO應該記住，SBOM只是一個使能者(enabler)，實際上并不能解決任何問題，以確保你的供應鏈安全。它只能幫助你應對可能發生的事件。不過，Osnat對行業響應的速度和圍繞SBOM標準及代碼認證正在進行的廣泛合作持樂觀態度，他認為這將有助于使工具更具互操作性，進而改善整個行業的透明度和報告標準化，就像SOC 2所帶來的結果一樣。
Osnat表示，盡管如此，CIO并不需要等到新的標準或工具才開始讓安全成為開發人員的一部分。CIO應該先和首席工程師們溝通，找出適合企業的正確模式，并仔細研究如何實踐這種變革以及變革可能帶來的影響。
關于企業網D1net(hfnxjk.com)：
國內主流的to B IT門戶，同時在運營國內最大的甲方CIO專家庫和智力輸出及社交平臺-信眾智（www.cioall.com）。同時運營18個IT行業公眾號（微信搜索D1net即可關注）。
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號