?如今，軟件供應鏈攻擊已成為突破業務防線的新路徑之一。在近幾年的重大安全事件、實戰攻防演練中，已頻現軟件供應鏈攻擊的身影。

2020年12月，基礎網絡管理軟件供應商SolarWinds遭遇軟件供應鏈攻擊，受到攻擊的不僅是SolarWinds服務的多家科技公司，還有其服務的大量制造業公司。

隨著時間的推移，此次供應鏈攻擊事件波及范圍極大，包括政府部門、關鍵基礎設施以及多家全球500強企業。

事故發生后的1個月，SolarWinds的股價下跌了50%。

2021年12月，Apache開源項目Log4j爆出核彈級漏洞，攻擊者僅需一段代碼就可以遠程控制目標服務器。

由于Log4j被廣泛地應用在中間件、開發框架、Web應用中，而這些中間件和開發框架作為軟件基礎又被其他軟件系統使用，因此Log4j被極其廣泛的應用在各大軟件系統里面。

利用此漏洞進行軟件供應鏈攻擊造成的嚴重性、影響面，堪稱2021年之最。

除此之外，Linux“臟管道”事件、周下載量超過700萬次的JavaScript流行庫ua-parser 賬戶遭接管、影響多家大廠的依賴混淆、PHP源代碼事件等供應鏈安全事件頻發。

據Sonatype公司的調查，供應鏈攻擊行為比去年增加了430%。

這盆冷水讓大多數開發人員意識到，他們的軟件供應鏈有嚴重的安全問題。

過去幾十年，大大小的公司都把注意力聚焦在軟件構建和各自的生產環境上，雖然在基礎設施方面做得非常好，但攻擊者卻到了更簡單的方法，即從敞開的供應鏈大門中進入。

事實上，軟件供應鏈安全風險防控并不容易，最大的挑戰就在于供應鏈的復雜性。那么，軟件供應鏈安全治理到底該如何做？

軟件供應鏈安全的復雜性

所謂軟件供應鏈攻擊，顧名思義，指的就是針對軟件供應鏈所發動的網絡攻擊，攻擊者會先攻擊軟件供應鏈中安全防護相對薄弱的部分，然后再利用軟件供應鏈之間的相互連接（如軟件供應、開源應用）等，將風險擴大至上下游企業，對大量的供應商和最終用戶帶來巨大影響。

與其它攻擊形式相比，軟件供應鏈攻擊往往會產生“牽一發而動全身”的效果。因此，僅僅對軟件供應鏈某個單一環節進行安全防護是遠遠不夠的，需要從其供應過程和軟件自身安全出發。

根據軟件供應鏈的特點，軟件供應鏈的業務流程可以抽象成開發、交付以及應用三個環節。

 開發環節

主要是指軟件開發商的編程人員根據用戶（含定制用戶）的需求，進行編程并完成軟件包提供的過程。

該過程主要涉及用戶需求、編程語言、開發環境、開發框架、測試和封包等。

在這個階段，尚未有統一的、經過安全檢驗的發布渠道，多數工具未經檢測直接發布；

工具及庫通常由商業公司或個人開發，因代碼復雜，編程人員往往依據將易用性作為選擇開發配套的唯一標準，缺乏安全的意識。

因此，在開發階段存在被病毒污染的可能，導致開發出的功能模塊默認感染病毒。同時，在進行源代碼打包或開發過程中，對功能模塊進行后門留存，給程序的開發環境以及后續的使用環境，都帶來了安全隱患。

此外，程序開發環境一般屬于核心區域，一旦編程人員下載了不安全的工具，則可能直接導致整體編程環境出現重大安全隱患，所有從該環境出入的代碼，都可能存在泄密、篡改等風險。

在軟件測試環節也是如此。如果進行源代碼測試、封包的工具存在惡意代碼感染，則可能感染整體測試環境；

測試人員不具備安全意識，測試電腦在不安全的環境進行操作，則帶來次生感染。

• 交付環節

主要是指開發商或者推廣商通過互聯網網站、在線商城、社交工具、在線網盤或者通過存儲介質，將開發或定制的軟件交付給最終用戶。

在發布渠道方面，目前主流的軟件發布渠道缺乏有效的監管，各應用發布商缺乏對軟件發布的安全審核；

從應用在上傳至渠道用于下載的傳輸途徑、存儲、發布等環節，易發生多維度的篡改行為，導致渠道風險的發生；

非官方發布平臺直接發布或被篡改并植入惡意代碼，造成感染。

在發布下載方面，軟件廠商出于推廣需要，多數軟件往往會對自有軟件進行捆綁安裝，已形成了完整的灰色產業鏈，缺乏對捆綁軟件的審核機制。

同時，常見如域名劫持（DNS）、內容分發系統（CDN）緩存節點篡改等，導致用戶在不知情的情況下，下載存在惡意代碼或后門的軟件。

•  應用環節

主要是指最終用戶使用該軟件產品，包括下載、安裝、注冊、付費、使用、故障修復、升級、卸載等全部過程。

在安裝方面，安裝源自身可能存在隱患，安裝時往往會配套一個腳本安裝工具代為執行，但是安裝工具的出現無疑會增加整體使用供應鏈的安全。

在升級方面，升級包是對原軟件進行升級的代碼包，未經認證的升級包存在一定的安全風險；

官方廠商以及第三方非認證組織往往會通過自身渠道進行補丁包發布，終端用戶多數不會進行分辨，下載即安裝。

在卸載方面，官方應用往往會將卸載工具內嵌至應用中，但是對于部分應用由于其卸載不便，且容易殘留，提供的第三方卸載工具，也會存在安全隱患。

軟件供應鏈安全治理框架的推進

為了應對不斷升級的軟件供應鏈安全威脅，業界已經在逐步推出軟件供應鏈安全框架。

最為知名的莫過于Google的軟件供應鏈安全框架SLSA，用于確保整個軟件供應鏈中軟件工件完整性的端到端框架。

SLSA以Google內部的“Borg二進制授權”(BAB)為主導——Google八年來一直使用這一流程來驗證代碼出處和實現代碼身份。

SLSA希望鎖定軟件開發鏈中的所有內容，從開發人員到源代碼、開發平臺和CI/CD系統、以及包存儲庫和依賴項。

CNCF基金會托管的in-toto項目，也是一個通過收集和驗證相關數據來保護軟件供應鏈的框架。

它通過使庫能夠收集關于軟件供應鏈行為的信息，并允許軟件消費者和項目經理發布關于軟件供應鏈實踐的政策來做到這一點，這些政策可以在部署或安裝軟件之前進行驗證。

簡而言之，它有助于捕獲軟件供應鏈中發生的事情，并確保它按照定義的策略發生。

在國內，中國信通院也在助力企業針對軟件全生命周期進行安全管控，以全鏈路安全保障為目標，建立了一系列軟件供應鏈安全標準體系，并落地評估測試。

中國信通院認為，針對軟件供應鏈安全保障流程，可劃分為軟件供應鏈入口（對內引入）、自身（自研應用）、出口（對外供給）三大階段，應從軟件來源、軟件安全合規、軟件資產管理、服務支持、安全應急響應多個維度，對軟件供應鏈安全保障能力進行規范，搭建軟件供應鏈安全模型。

在落地實踐方面，中國信通院已牽頭制定了研運安全工具標準體系，包括：靜態應用程序安全測試工具（SAST）、交互式應用程序安全測試工具（IAST）、軟件組成分析工具（SCA）、應用運行時自我保護系統（RASP）、軟件物料清單建設總體框架（SBOM）等多項標準。

事實上，要做好軟件供應鏈安全，不僅要在安全技術及工具上對軟件全生命周期的每個階段進行安全防護，形成開發運營安全閉環，還要從組織文化、安全開發流程等多角度考慮，不斷優化流程實踐，以建立更安全的環境。

軟件供應鏈安全的全球性政策

軟件供應鏈安全是一個全球性問題，究其根本，是由于軟件行業全球化、市場化、模塊化的特點。

為了防止諸如SolarWinds、Log4j等事件的再次發生，全球多國法規都在提升對供應鏈安全的管控要求。

近期，美國和歐盟都發布了新的供應鏈安全相關要求法案，要求廠商評估供應鏈數字化產品的安全性。

美國和歐盟在各自的法案都提到了軟件安全檢測，軟件物料清單(SBOM)等內容，這意味著通過強制性的網絡安全法規要求，企業必須通過披露SBOM、源代碼安全檢測等手段提升數字化產品安全性，才能繼續正常地銷售提供數字化產品。

美國白宮在9月14日發布了題為《通過安全的軟件開發實踐增強軟件供應鏈的安全性》的備忘錄，要求供應商產品需提供安全自我證明。

自我證明是指開發人員必須提供以證明其符合安全軟件開發框架的文檔。

此外，美國政府還發布了《ICT供應鏈風險管理標準》（NIST SP800-161）、商用信息技術軟件及固件審查項目（VET）等，清楚界定了軟件供應鏈中涉及存儲、檢索、修改、傳輸以及服務的相關標準與要求，在一定程度上規避了軟件供應鏈面臨的諸多風險。

歐盟在9月15日發布了題為《網絡彈性法案》（Cyber Resilience Act）的草案，旨在為聯網設備制定通用網絡安全標準。

法案要求所有出口歐洲的數字化產品都必須提供安全保障、軟件物料清單SBOM、漏洞報告機制，以及提供安全補丁和更新。

違反規定的公司將面臨最高1500萬歐元或全球營收2.5%的罰款。

在中國，近年來先后頒布的《中華人民共和國網絡安全法》、《網絡安全審查辦法》、《中華人民共和國國民經濟和社會發展第十四個五年規劃和 2035 年遠景目標綱要》、《關鍵信息基礎設施安全保護條例》等政策法規，都強調加強軟件供應鏈的安全保障。

在標準制定方面，我國出臺了供應鏈安全管理國家標準《信息安全技術ICT供應鏈安全風險管理指南》(GB/T 36637-2018)，從產品全生命周期的角度開展風險分析及管理，以實現供應鏈的完整性、保密性、可用性和可控性安全目標。

全國信息安全標準化技術委員會歸口的國家標準《信息安全技術軟件供應鏈安全要求》已形成標準征求意見稿，規定了信息技術產品供應方和需求方應滿足的供應鏈基本安全要求。

盡管國內對軟件供應鏈安全的重視認知稍微滯后于國外，但隨著國內技術的發展和安全意識覺醒，很快就能追趕上來。

結語

開源技術應用、國際形勢復雜、軟件供應鏈的多樣化，供應鏈各個環節的攻擊急劇上升，已然成為網絡主要的安全成脅。

想要做好軟件供應鏈安全治理，需要打好“團體賽”，由整個開源生態角色在供應鏈的各個環節，建立一系列的安全準則和最佳實踐，切實保障整個網絡空間的安全。?