2023 年正在如火如荼地進行着。但在進入新的一年之前，我們決定退後一步，反思一下與軟件供應鏈安全有關的開源管理在過去幾個月中的變化——以及它将如何在未來幾年繼續發展。
軟件供應鏈安全是指識别和解決作爲軟件開發一部分的技術和流程中的風險的做法。軟件供應鏈中的鏈接從開發延伸到部署，包括開源依賴項、構建工具、包管理器、測試工具以及介于兩者之間的大量内容。 供應鏈威脅不同于經典攻擊（并且可能比傳統攻擊更具破壞性），因爲單個漏洞可能會影響數百甚至數千個不同的目标，并且很難在下遊檢測問題。 值得注意的軟件供應鏈攻擊包括：
事件流
當項目維護者添加并使用惡意代碼修改依賴項（flatMap Stream）時，npm 包事件流遭到破壞。如果您更新了事件流包或任何依賴項，并且爲 flatMap 流定義了版本範圍，則會把存在惡意代碼版本拉入代碼倉庫中。
SolarWinds Orion
黑客獲得了對 SolarWinds Orion 平台的訪問權限，許多大型組織都使用它進行基礎設施監控。Orion 平台被認爲是一個單一的、受信任的資源——如果用戶從 SolarWinds 下載，他們希望有效載荷來自 SolarWinds。但是，一旦有效載荷被惡意更新，許多 SolarWinds 用戶，包括英特爾，微軟，思科和聯邦政府機構，都受到了影響。
Codecov Bash 上傳器
Codecov 是一種集成到您的 CI 環境中的代碼覆蓋率工具，當攻擊者在公司的 Docker 鏡像創建過程出現問題後訪問憑據時，它受到了損害。然後，攻擊者能夠更改 Codecov 文檔并修改用于在 CI 環境中安裝該工具的腳本（包含在文檔中）。Twilio，GoDaddy 和許多其他 Codecov 用戶都受到了影響。
這些供應鏈攻擊的細節各不相同——一個針對的是開發人員工具，另一個針對開源軟件包，還有第三個針對的是專有軟件。但共同點是，攻擊者通過破壞單個共享資源來攻擊多個目标。 鑒于現代軟件供應鏈中存在大量的組件，沒有單一的、萬無一失的解決方案來應對所有供應鏈威脅。但是有各種各樣的策略和工具可以提供幫助。
軟件物料清單 （SBOM）
軟件物料清單 （SBOM） 是組件（及其元數據）的列表以及組成軟件應用程序的組件之間的關系。SBOM 可用于多種目的，例如滿足客戶請求、滿足政府行政命令帶來的監管要求以及支持開源許可證合規性。 另一個越來越重要的用例是軟件供應鏈安全。現代應用程序通常由數十個單獨的軟件組件構建（這些組件會引入更多的傳遞依賴關系），這可能使涉及産品的實體（制造商、運營商、買家）難以了解潛在的供應鏈問題。SBOM 在爲組織提供降低風險所需的信息方面發揮着重要作用。生産和使用 SBOM 都有一系列安全優勢。
生産 SBOM
使組織能夠更輕松地監視其應用程序中的組件是否存在漏
支持爲軟件組件創建已批準 / 未批準的列表
幫助組織識别和更換即将報廢的組件
節省工程和安全團隊識别和審查代碼的時間
使用 SBOM
使組織能夠快速确定他們是否受到新報告的漏洞的影響幫助團隊主動解決可能由報廢組件引起的問題支持對組織風險狀況的準确評估，并允許更明智地緩解風險
軟件組合分析 （SCA）
軟件組合分析 （SCA） 已成爲幫助組織控制因使用開源軟件而産生的風險的日益必要的工具。現代應用程序中 OSS 的龐大數量 - 平均應用程序使用 147 個不同的開源組件（這些組件涉及更多的依賴關系） - 使組織難以掌握以下領域的問題：
安全
許可證合規性
代碼質量
長期項目可行性
軟件組合分析通過自動發現漏洞、許可證和潛在質量問題，然後提供可操作的見解來爲補救提供信息，從而幫助團隊降低這些風險。最後，SCA 工具通常還包括使團隊能夠大規模應用安全和許可證合規性策略的功能。（例如，一個組織可能會使用此功能在所有構建中标記具有 GPL 許可組件的任何内容。 許多組織将軟件組合分析（隻能與開源代碼一起使用）與專有代碼工具（如 SAST、DAST、IAST 和 RASP）相結合，形成一套完整的應用程序安全測試産品。
就像今天的開源軟件世界看起來與十年前大不相同一樣，軟件組合分析工具自早期以來已經有了很大的發展。雖然 SCA 最初用于執行手動和定期掃描（通常在 IPO 等特定事件之前），但今天的工具在确保整個軟件開發生命周期中的 OSS 合規性和安全性方面發揮着不可或缺的作用。 沿着這些思路，我們期望下一代 SCA 工具能夠在多個前沿領域提供更豐富的功能集。
策略引擎
下一代策略引擎将使不同的利益相關者能夠将審批和自動化作爲其日常工作流程的一部分。
開發人員友好
今天的一些 SCA 工具确實集成到 CI/CD 管道和開發人員的本機工作流中。但是，我們越是将 SCA 構建到開發人員的工作流程中，他們就越容易将風險管理融入到他們的日常生活中。下一代 SCA 解決方案不需要開發人員使用新工具或超越他們以前的經驗，這将有助于組織内的整體接受度和效率。代碼質量和來源
與提供有關代碼來源和質量的指導相比，當今的 SCA 工具在清點依賴項和許可證（以及标記安全問題）方面做得更好。我們預計這種情況将在未來幾年有所改變。下一代 SCA 解決方案将在代碼來源（是否來自安全和可信的來源？）和質量（企業可以長期依賴庫嗎？）方面提供更多實際指導。
下一代報告
今天的 SCA 工具确實提供了一系列報告選項，但未來十年将看到更豐富的功能。我們希望報告以技術和非技術利益相關者都易于理解的格式包含更全面的見解。例如，向銷售和客戶支持團隊近乎實時地提供合規性數據的 SCA 平台可以幫助他們及時解決客戶和潛在客戶提出的問題。
開源合規風險管理
在下文中，我們将探讨與任務關鍵型開源管理過程相關的趨勢、預測和觀察結果。其中包括使用 SBOM 數據、自動執行開源許可證合規性、保持對軟件組合的可見性等。
本博客基于兩個主要數據點：
對約 100 名知識産權顧問和開源許可合規專業人士開展的小型調查
與客戶成功和産品團隊進行對話，包括高級産品經理 Cortez Frazier Jr.
1. SBOM 将繼續成爲優先事項，但将更加關注理解和操作 SBOM 數據
我們的知識産權顧問調查問卷的結果以及和大量客戶對話都得出了明确的結論，即各行各業的組織都在優先考慮 SBOM。這并不奇怪 - SBOM 有幾個重要的用例，包括軟件供應鏈安全、法規遵從性和銷售支持等。
但對于 2023 年，我們聽到越來越多的組織表示，他們将優先采取更好的措施來操作 SBOM 數據——這在曆史上有些困難，原因如下：
現代應用程序由數十種不同的軟件組件構建而成，這意味着 SBOM 往往很複雜且難以破譯，尤其是在沒有正确工具的情況下。
機器可讀格式的日益标準化（以及 SBOM 工具的興起）可以使引入 SBOM 數據變得更加容易。但是，即便如此，解釋某些 SBOM 元素（例如不同依賴項之間的關系）仍然很困難。
并非所有 SBOM 工具都具有足夠的編程語言覆蓋範圍，并且某些工具無法與開發管道很好地集成。
某些 SBOM 格式比其他格式更好地支持漏洞數據。
我們預計組織将在 2023 年優先應對這些挑戰。這包括圍繞在哪裏添加 SBOM 工具（例如，添加到集中式 VCS 或中央 CI 系統）、SDLC 工具的哪個部分應該運行（例如構建過程）以及如何爲第三方應用程序導入（和使用）SBOM 進行更多讨論（并且更加緊迫）。
知名安全産品經理 Cortez Frazier Jr. 補充說：" 一緻的 SBOM 生成與使用漏洞或可利用性數據豐富 SBOM 之間的交集是組織開始從 SBOM 中獲得實際價值的地方。"
2. 當前的許可證合規流程是手動且耗時的——這将繼續鼓勵逐步轉向自動化
我們的知識産權顧問調查問卷的一個更令人大開眼界的結果是，許多組織仍然緻力于開源許可證合規性管理的大量手動工作。
例如，58% 的受訪者表示他們仍在手動生成歸屬通知。而且，隻有 26% 的受訪者擁有完全自動化的許可證合規性策略實施。
通常，這項工作落在内部法律顧問身上。大多數（73%）的受訪者表示，法律團隊最終負責生成歸屬通知。
從曆史上看，主流的主要用例之一是幫助組織從手動運行提升到自動運行開源許可證合規性檢查。而且，盡管出于預算考慮可能會減緩某些公司向自動化合規的過渡，但我們确實不斷聽到，這是許多公司的優先事項，無論在任何行業或地區都是如此。
" 考慮到在直接和傳遞依賴關系中發現的許可證合規風險，手動方法不僅耗時，而且可能不準确，因爲它與組件使用總量有關，"Frazier Jr. 說。
3. 軟件組成成分的可見性仍然是一個挑戰
SBOM 采用率的增加并沒有解決與理解軟件組成成分相關的所有挑戰。其中最大的兩個挑戰是：
代碼掃描工具（和相關流程）面向直接依賴關系。例如，我們調查中 58% 的受訪者表示，他們的組織将開源許可證合規性限制爲直接依賴關系。
代碼掃描工具（和相關流程）并不總是使組織能夠輕松快速識别他們是否以及在何處使用特定的開源包。
也許由于缺乏可見性而産生的最大的實際問題與組織如何應對零日漏洞有關。當披露嚴重性漏洞（如 Log4Shell）時，組織必須快速确定他們在哪裏使用某個軟件包的易受攻擊版本（然後成功升級到下一個安全版本）。
但這說起來容易做起來難，特别是對于擁有廣泛産品線的大型企業。而且，如果攻擊者成功破壞您的環境并引入新的惡意軟件包，則可能會特别棘手。
" 包管理器依賴項沖突解決隻會加劇可見性的缺乏，因爲清單文件中定義的包可能與構建時包含的包相對不同，"Frazier Jr. 說。
4. 持續監控您的意願變得更加重要——即使它以犧牲限制性的早期執行爲代價
在任何風險專業人士的工具中，最重要的工具永遠是一份準确和最新的資産清單，無論是實物資産，還是我們的數字資産。
這很重要，原因有很多，包括最新的清單使組織能夠持續監測其環境。在這種情況下，我們将持續監測定義爲在組織 SDLC 的每個構建或源頭階段進行實時軟件組件成分分析 （SCA）。随着影響現有開源軟件包的新漏洞的出現，組織準确評估總攻擊面的能力對于任何威脅建模或緩解活動都至關重要。
沿着這些思路，我們預計團隊将越來越多地采取預防措施，以避免可能妨礙持續監測的流程或活動。這方面的一個例子是，在使用新的軟件組成成分分析工具時，傾向于實施限制性策略。盡管這些策略的目标令人欽佩，但在實踐中，這種方法可能會激勵開發團隊延遲加入其存儲庫，直到這些高風險組件被預先消除。而且，這可能會産生隐藏而不是減少風險的意想不到的後果。
相反，爲了實現持續監控，我們希望風險專業人員優先考慮：
全面覆蓋目标風險狀況中的所有代碼存儲庫（例如分布式軟件、面向外部的應用程序或具有關鍵 IP 的應用程序），以構建準确的資産清單
大規模應用規範化的風險識别策略來暴露現有的軟件供應鏈風險
根據組織的内部策略定義，管理與高風險組件相關聯的元數據（例如，分布式項目的直接依賴項中的許可證被拒絕，或具有可用修補程序的直接依賴項中的關鍵漏洞）
除了避免可能妨礙精确組件庫存的過程之外，應該考慮使用工具來促進持續監控。" 通過将組件覆蓋範圍優先于限制性執行，風險專業人員将減少内部工具實施摩擦，同時爲任何緩解或取證事件定義準确的基礎，"Frazier Jr. 說。
