科技云報道原創。

軟件供應鏈安全如今已經成了一個世界性難題。從2021年底Apache Log4j“核彈級”風險爆發，時至今日影響仍然存在，保障軟件供應鏈安全已成為業界關注焦點。

但近2年時間過去了，軟件供應鏈安全問題似乎并沒有得以緩解，安全事件層出不窮，開源漏洞風險與日俱增。

Venafi對來自全球不同企業的1000位CIO調研顯示，其中82%的人表示他們的組織容易受到針對軟件供應鏈的網絡攻擊。

奇安信《2023中國軟件供應鏈安全分析報告》顯示，開源項目維護者對安全問題的重視度和修復積極性較低。

同時，不活躍（超過一年未更新發布過版本）的開源軟件，一旦出現安全漏洞，難以得到及時修復。

為什么人人都知道軟件供應鏈安全問題很重要，卻難以解決？

軟件供應鏈安全與開源息息相關

要搞清楚軟件供應鏈安全的癥結，先得厘清其涵義。

基于中國信通院的定義，軟件供應鏈安全是指“軟件供應鏈上軟件設計與開發的各個階段中來自本身的編碼過程、工具、設備或供應鏈上游的代碼、模塊和服務的安全，以及軟件交付渠道及使用過程安全的總和。”

這里是把軟件供應鏈安全分為了兩部分：一是軟件自身的供應鏈安全，二是軟件供應鏈交界面的安全管理。

軟件自身的供應鏈，可以簡單理解為應用的代碼來源，應用的代碼來源主要有兩個部分：一個是產品研發自己寫的代碼，另一個就是引入的第三方的開源組件代碼。針對這兩者的安全檢測也是我們常說的開發安全。

軟件供應鏈交接界面，針對的是開源軟件或者商業采購第三方軟件。

這部分的供應鏈安全管理，主要是在交付和使用過程中進行相關的準入檢測，并形成標準化可溯源的軟件物料清單。

事實上，軟件供應鏈的安全的重要性提升和開源的大趨勢是息息相關的。

軟件開源化的趨勢是一個累積的過程，十幾年的時間經歷了一個量變到質變的階段，現在全球的開發者都在依賴開源組件來做應用的研發，絕大多數現代代碼庫都包含開源組件。

但是開源的繁榮本身就建立在一系列自由許可協議和免責條款上——其中也包括風險免責，“使用者風險自負”是開源社區的共識。

近年來，開源軟件自身的安全狀況持續下滑，企業軟件開發中因使用開源軟件而引入安全風險的狀況更加糟糕，例如：危險開源組件的使用、自研代碼缺陷漏洞引入、容器鏡像漏洞引入等，這些風險導致軟件系統的整體安全防護難度越來越大。

因此，開源軟件供應鏈安全風險治理任重道遠。

直面軟件供應鏈安全治理挑戰

盡管業界已經普遍認識到軟件供應鏈安全的重要性，但治理起來依然面臨重重挑戰。

騰訊安全開發安全專家劉天勇表示，從技術角度看，軟件供應鏈安全的治理的難點可以分成三部分：

一是檢測門檻高。

開源組件的來源復雜，依靠單一的技術手段難以做到全面覆蓋。

市面上常見的開源組件檢測技術是基于源代碼的SCA分析，但基于源碼的SCA難以覆蓋軟件供應鏈交接界面的第三方軟件成品。

二是修復成本高。

在企業開始做開源組件的風險治理的時候，存量業務往往會發現大量的漏洞，但這些業務大多數處于上線運營的階段，修復的過程對研發資源是一個較大的消耗，同時對安全團隊來說也是較大的推動阻力。

三是攻擊影響范圍廣。

第三方開源組件的使用，間接擴大了軟件的受攻擊面，針對上游供應鏈環節的漏洞挖掘和惡意利用，能夠快速覆蓋大量的下游軟件，同時相關的攻擊具有較高的隱蔽性，常用的安全檢測手段難以進行全面的防御，目前軟件供應鏈攻擊已經成為攻防演練中非常常用的攻擊手段。

此外，供應商對產品安全性的重視程度不足、開發人員安全開發能力有限等，導致第三方供應商產品安全質量參差不齊，也加大了軟件供應鏈安全治理的難度。

那么，企業該如何應對這些挑戰？在技術上是否有對應的解決手段？

SCA和SBOM

當前，SCA（Software Composition Analysis）是目前業界主要的解決開源組件風險檢測的手段。

SCA是一類工具的統稱，可以通過分析源代碼識別其中引用的開源組件信息（名稱、版本、校驗值）、組件漏洞、開源協議等信息，從而幫助開發人員和安全人員快速對于企業代碼中的開源風險進行識別。

隨著供應鏈安全開始獲得更多關注，SCA工具內置了對與跟蹤組件相關的漏洞和安全風險的更深入分析和管理，并成為企業生成SBOM和管理其開源使用的主要方法之一。

Linux基金會最近的一項調查發現，SBOM的意識度很高，目前有47%的IT供應商、服務提供商和受監管的行業在使用SBOM，88%的受訪者預計將在2023年使用SBOM。

代碼掃描和滲透測試

保護軟件供應鏈的核心是一個應用程序安全問題，因此傳統的應用程序安全代碼掃描工具將在這個解決方案堆棧中發揮重要作用。

靜態應用程序安全測試(SAST)、動態應用程序安全測試(DAST)、交互式應用程序安全測試 (IAST)和運行時應用程序掃描保護(RASP)工具，以及明智地使用滲透測試，可以幫助企業測試他們自己的內部代碼，并提供對第三方代碼的進一步檢查，以作為應對風險的后盾。

相比于SCA和SBOM產品依賴于已知的、先前發現的漏洞，徹底的應用程序滲透評估可能會在檢查第三方庫和框架時識別出脆弱的代碼使用情況，而這些代碼以前可能在其他地方沒有報告過。

此外，共享機密掃描和管理也正在從一個獨立的工具類別快速轉變為一個功能，該功能正在融入軟件供應鏈安全工具的各個方面。

這是因為在開發和實際環境中，針對嵌入在源代碼、配置文件和基礎設施代碼中的機密數據的網絡攻擊活動仍然猖獗，因此迫切需要解決這個問題。

此外，依賴關系管理和分析、受信任的存儲庫和注冊中心、安全代碼簽名、CI/ CD管道安全性、第三方風險管理平臺、IaC安全和CNAPP，都是軟件供應鏈安全治理要重點關注的對象。

正如Gartner公司的高級主管兼應用安全分析師Dale Gardner所說：“當人們關注供應鏈安全時，他們關注的是使用SCA、SBOM等工具，這些都是解決方案中非常重要的部分，但它們實際上只是一種不全面的解決方案。”

軟件供應鏈安全治理并非純粹的技術問題

事實上，軟件供應鏈安全問題是人、流程和知識的問題，而非純粹的技術問題。

在解決軟件研發過程的供應鏈安全問題時，需要貼合SDLC（軟件開發生命周期）考慮供應鏈安全風險。

為此，Goolge提出了SLSA（Supply-chain Levels for Software Artifacts）框架，微軟提出了SCIM（Supply Chain Integrity Model）框架以及CNCF（云原生計算基金會）的軟件供應鏈最佳實踐，三種框架都強調對于源代碼、第三方依賴、構建系統、制品、發布、部署的安全性。

以SLSA框架為例，SLSA是一個標準清單和控制框架，用于緩解軟件項目中的代碼和軟件包的供應鏈風險。

SLSA框架從三個方面評估軟件供應鏈的安全等級，分別是源碼、構建和依賴，并可劃分為4個級別：

Level 1：構建過程是完全腳本化或自動化，且能夠基于結果識別來源源碼；

Level 2：使用有身份認證能力的版本控制和托管服務，確保構建來源是可信的；

Level 3：源碼和構建平臺符合可審計標準，且有成品完整性保證；

Level 4：所有變更均有雙人評審，且有封閉的、可重復的構建過程。

以Level 4等級要求為例，在軟件構建過程中企業需要實踐以下4點：可驗證的版本控制、雙人評審、安全的自動化構建流程/環境、可重復構建的流程。

結語

軟件供應鏈上每一個環節的安全問題，都有可能成為黑客攻擊的切入口。千里之堤毀于蟻穴，把住軟件供應鏈每個關卡，莫讓小小漏洞成為洪水猛獸。

【關于科技云報道】

專注于原創的企業級內容行家——科技云報道。成立于2015年，是前沿企業級IT領域Top10媒體。獲工信部權威認可，可信云、全球云計算大會官方指定傳播媒體之一。深入原創報道云計算、大數據、人工智能、區塊鏈等領域。

審核編輯 黃宇