對于快速發展的軟件供應鏈安全技術來說，好消息是，快速的創新步伐提供了越來越多的機會，可以提高軟件產品組合中大量組件和代碼的可見性和透明度。
壞消息是，實驗和創新同時朝著許多不同的方向發展，安全工具領域是一個令人困惑的混合體，混雜著不斷發展的各種類別和利基產品。
其中一些是更傳統的應用程序安全工具，它們正在向更適合開發人員的方向發展。還有一些是傳統的開發工具，它們增加了以安全為中心的控制和功能，以應對供應鏈風險的挑戰。還有一些來自DevSecOps的領域，旨在促進開發和安全領域之間的相互協作。
Tanium公司的產品顧問Tom Going表示：“人們很難對軟件供應鏈的安全有一個清晰的認識，原因之一是供應鏈中有很多環節可能出錯。企業可能會在軟件中直接引入漏洞，就像幾年前的SolarWinds數據泄露事件一樣，在Log4j等常見庫中存在漏洞，甚至像一個受損的證書頒發機構這樣的東西。”
軟件供應鏈安全沒有黃金標準
雖然有一些軟件供應鏈安全產品棧和平臺開始在市場上整合，但這些產品的功能組合卻多種多樣。
這些平臺傾向于圍繞的主要工具類別是軟件組合分析(SCA)和生成軟件材料清單(SBOM)的工具，即現代軟件的所謂“成分列表”。雖然SCA和SBOM傾向于構成許多軟件供應鏈安全工具的支柱，但對于試圖構建路線圖以支持管理供應鏈風險全面計劃的首席信息安全官來說，這確實只是冰山一角。
Gartner公司的高級主管兼應用安全分析師Dale Gardner表示，“當人們關注供應鏈安全時，他們關注的是使用SCA等工具，他們關注的是SBOM。這些都是解決方案中非常重要的部分，但它們實際上只是一種不全面的解決方案。”
這還涉及許多其他活動部分，包括機密管理、依賴關系映射和管理、持續集成(CI)/持續交付(CD)管道安全性、有效的存儲庫管理等。大多數專家都認為，安全團隊將很難從一家供應商那里找到他們需要的一切。
咨詢機構Coalfire公司的應用程序安全高級經理Michael Born解釋說：“我認為，沒有一家供應商能夠以滿足所有企業需求的方式處理與軟件供應鏈安全相關的所有挑戰。”他表示，缺乏整合并不一定是件壞事。他說，“這可能會使企業陷入與供應商鎖定相關的風險，并且可能意味著企業成熟或變化的速度比供應商能夠跟上的速度快。”
這種碎片化不僅是來自幾個不同技術角度(以開發為中心的工具、以操作為中心的模具、以安全為中心的工具)的有機創新的結果，而且還有一系列不同的用例。
德勤公司的網絡風險安全供應鏈負責人Sharon Chand解釋說:“我們必須非常具體地了解正在談論的風險或用例，以便能夠找到合適的軟件解決方案或整體解決方案堆棧來解決這些問題。因為我真正需要什么樣的解決方案將取決于在軟件供應鏈安全場景中的位置。如果我是軟件生產者，那么看起來與軟件消費者不同。通常情況下，在整個供應鏈生命周期的某些階段，每個人都會同時處于這兩種狀態。”
企業如何將它們整合在一起將高度依賴于他們的用例、基礎設施，以及他們團隊的技能和文化的構成。不幸的是，目前還沒有簡單的方法來構建這個堆棧。
安全工具的十個類別
下面的安全工具列表為首席信息安全官提供了一個很好的入門清單，用于規劃適合他們的軟件供應鏈安全解決方案堆棧。這份名單雖然并不詳盡，而且可能很快就會改變，但是它包含了主要的工具類別和網絡安全領導者可能想要考慮的軟件供應鏈安全路線圖的特性。
(1)SCA和SBOM的生成
SCA工具目前最為人所知的是它們在軟件供應鏈安全中的作用，但這一類別的起源故事開始于更為平淡無奇的領域。這些工具最初是為了幫助開發團隊在其構建中跟蹤其開源組件的使用情況，以處理許可合規性。隨著供應鏈安全開始獲得更多關注，SCA工具內置了對與跟蹤組件相關的漏洞和安全風險的更深入分析和管理，并成為企業生成SBOM和管理其開源使用的主要方法之一。Mend.io(前身為WhiteSource)、FOSSA和Synopsys Black Duck就是這種進化路徑的主要例子。
SCA并不是生成SBOM的唯一選擇。其他一些SBOM生成方法包括使用命令行界面(CLI)工具，例如Cyclone DX CLI和SPDX Tool，運行時分析，例如Rezilion;或二進制分析，如ReversingLabs。但SCA往往是那些構建軟件供應鏈解決方案堆棧或生態系統的供應商的賭注。其中一些是SCA供應商，他們通過內部開發或收購擴展到下面描述的其他工具類別。其他公司可能從一開始就考慮到了開發人員的心態，包括混合供應鏈工具中的SCA;Snyk就是一個很好的例子。Synopsys和ReversingLabs最近宣布了更多的合作伙伴關系，在不將客戶鎖定在單一平臺的情況下擴大了供應鏈安全能力。
(2)代碼掃描和滲透測試
保護軟件供應鏈的核心是一個應用程序安全問題，因此傳統的應用程序安全代碼掃描工具將在這個解決方案堆棧中發揮重要作用。靜態應用程序安全測試(SAST)、動態應用程序安全測試(DAST)、交互式應用程序安全測試 (IAST)和運行時應用程序掃描保護(RASP)工具，以及明智地使用滲透測試，可以幫助企業測試他們自己的內部代碼，并提供對第三方代碼的進一步檢查，以作為應對風險的后盾。Coalfire的Born說，“使用常見的SCA或SBOM測試工具和技術可能會檢測不到這些風險。”
他說，通過全面的代碼掃描來維持多層安全是至關重要的，滲透測試的抽查也是如此。
他說:“SCA和SBOM產品依賴于已知的、先前發現的漏洞，而徹底的應用程序滲透評估可能會在檢查第三方庫和框架時識別出脆弱的代碼使用情況，而這些代碼以前可能在其他地方沒有報告過。”
(3)SBOM的豐富和聚集
當企業創建他們自己的SBOM并從他們的供應商那里攝取SBOM時，這些工件的聚合、豐富和管理將成為操作它們的一個日益重要的部分。例如，添加漏洞可利用性交換(VEX)信息將成為情景化SBOM的一個日益重要的部分。類似地，這些工具可以潛在地豐富SBOM信息的數據包括組件健康檢查，例如OpenSSF記分卡數據和CISA已知被利用漏洞(KEV)數據庫中的漏洞預測評分系統(EPSS)分數。
此外，簡單地匯總軟件組合和業務線中的SBOM信息將是網絡安全領導者日益關注的問題。這仍然是一個新興的領域，尚未真正整合成行業分析師確定的類別，因此首席信息安全官必須在SCA+類型的工具、開源工具和新平臺中尋找這些功能，這些工具正在開辟他們自己的類別定義路徑。這些例子包括Cybellum、Anchore和Rezilion，以及Bomber等新的開源工具。
(4)機密管理
共享機密掃描和管理正在從一個獨立的工具類別快速轉變為一個功能，該功能正在融入軟件供應鏈安全工具的各個方面。這是因為在開發和實際環境中，針對嵌入在源代碼、配置文件和基礎設施代碼中的機密數據的網絡攻擊活動仍然猖獗，因此迫切需要解決這個問題。
Gartner公司在最近發布的一份報告中建議：“憑證文件、私鑰、密碼和API令牌等機密信息不應提交給源代碼控制存儲庫。使用機密管理工具安全地存儲和加密，實施訪問控制，并管理秘密(即創建、輪換和撤銷)。”
這是一個基本的工具組件，因為網絡攻擊者可以利用共享的秘密來完全破壞企業軟件供應鏈的完整性。
(5)依賴關系管理和映射
依賴關系管理和分析是另一個有點模糊的類別，與SCA和SBOM聚合等其他工具類別高度重疊。但這是值得呼吁的，因為它觸及了一些最棘手的軟件供應鏈安全問題的核心。
安全倡導者對當今SBOM狀態的一些最主要抱怨是，它們仍然難以傳達與列舉的軟件相關的可傳遞依賴關系。
首席信息安全官和他們的團隊將需要更好的方法來規劃和管理隱藏的依賴關系網絡，這些依賴關系網絡橫跨他們的應用程序、API、CI/CD管道組件和作為代碼的基礎設施。一些可用的工具包括依賴映射工具，性能和彈性利益相關者也依賴于這些工具，例如Datadog和Atlassian。此外，SCA和SBOM管理工具經常將這些特性合并到它們的組合中。最近在這方面打入市場的一個值得注意的參與者是EndorLabs公司，該公司于2022年10月脫離隱身模式，將自己描述為“依賴生命周期管理”解決方案。上個月，該公司進入了RSA大會創新沙盒的決賽。
(6)受信任的存儲庫和注冊中心
雖然工件存儲庫和容器注冊表本身不是安全工具，但是將它們與規范的策略和過程一起使用可以在管理供應鏈風險中發揮重要作用。建立可信的工件存儲庫和容器注冊中心是為開發人員建立“安全護欄”基礎設施的基本部分。提供經過批準的組件的集中來源是一種主動的方法，可以避免出現問題，并對進入企業軟件的內容進行健全的治理。
Gartner公司的分析師寫道:“這些存儲庫是經過批準和審查的工件和軟件組件的可信來源。這實現了對軟件成分的集中管理、可見性、可審核性和可追溯性。”
(7)安全代碼簽名
隨著開發人員在其生命周期內提交和部署軟件，代碼簽名正日益成為確保代碼和容器完整性的最佳實踐。這個過程不僅對于建立強大的內部控制措施以防止篡改至關重要，而且對于建立客戶對交付給外部客戶的產品的信任也至關重要。當然，代碼簽名證書是軟件供應鏈攻擊者青睞的目標，因此首席信息安全官及其團隊需要確保他們選擇正確的工具并建立控制措施，以確保他們的代碼簽名過程真正安全。這一類別中的一些主要工具包括Garantir、Keyfactor、CircleCI、Cosign和Venafi。
(8)CI/ CD管道安全性
持續集成(CI)/持續(CD)交付管道是軟件“工廠”的一部分，開發人員依靠它來生產代碼，因此，它是整個供應鏈的內在組成部分。因此，加強這些環境的安全工具是健全的供應鏈安全計劃的重要組成部分。已經解決的機密管理問題是這個類別的一個重要方面。其他包括CI/ CD策略和治理管理，就像Apiiro和Cycode這樣的公司正在開發產品，以及實現良好的特權訪問控制和強身份驗證。
(9)第三方風險管理平臺
到目前為止，大多數工具主要集中于深入挖掘內部開發軟件中使用的第三方組件。但是，對于那些沒有太多可見性的第三方商業軟件怎么辦?這就是第三方風險管理(TPRM)工具和流程發揮作用的地方。即使SBOM要求在未來幾年內競相推動軟件供應商提高透明度，但目前大多數企業都很盲目。雖然TPRM風險評分工具(例如SecurityScorecard或RiskRecon)不能完全解決這個問題，但它們至少可以作為風險的代理，可能會讓企業確定他們需要與特定供應商和軟件提供商合作，以深入挖掘他們的代碼。
德勤公司的Chand表示:“我認為TPRM產品可以發揮作用的地方是，如果存在風險，我們能夠識別風險，也許這就是我真正希望將精力集中在SCA和理解軟件組成的原因。它成為了一種風險緩解技術，而不是我在生產或購買的所有軟件中普遍使用的解決方案。”
她說，軟件供應鏈安全領域仍然缺乏應用安全風險和業務風險之間的可靠工具聯系，她認為下一個重大創新機會可能在于供應商和從業者如何將TPRM平臺和更廣泛的供應鏈風險管理(SCRM)流程與來自SBOM和CI/CD管道的數據聯系起來。
(10)IaC安全和CNAPP
用于測試和部署代碼的底層基礎設施也是代碼，是供應鏈的基本部分。因此，首席信息安全官應該考慮至少將基礎設施即代碼(IaC)掃描和安全工具作為其更廣泛的供應鏈安全計劃的一部分。這些工具傾向于跨越軟件供應鏈安全工具和云原生應用程序保護平臺(CNAPP)之間的界限，這可以說是開始進入云安全和其他安全運營領域。但是云原生應用程序保護平臺(CNAPP)提供了很多其他的供應鏈安全支持，特別是在容器可見性和運行時安全性方面。容器是軟件供應鏈中主要的攻擊目標，在運行時采用的安全措施可以在工作負載進入生產環境之后為其提供支持。
