近年來，針對軟體供應鍊的安全攻擊事件一直呈快速增長态勢，造成的危害也越來越嚴重，其中，開源軟體的安全問題尤其值得關注。
據Sonatype的第八次年度軟體供應鍊狀況報告顯示，截至今年為止，專家們已經發現了88000個惡意開源包，比2019年的同一數字增加了三位數，表明企業的攻擊面正在快速增長。該報告是根據公共和專有資料分析編制的，包括1310億次Maven Central下載下傳和成千上萬的開源項目。
另外也了解到，超過90%的軟體應用程式使用開源元件，但使用開源軟體在提高開發人員的開發效率的同時，也給軟體應用程式的安全帶來了更多不确定性。而且，在數字化轉型加速的當下，在推動創新的過程中，開源的複雜性和開發速度也限制了軟體供應鍊安全控制的有效性。
據研究預測，到2025年，全球45%的組織将會遭受一次或多次軟體供應鍊攻擊，82%的CIO認為他們将更容易受到攻擊。這些攻擊包括通過廣泛使用的軟體元件（如Log4j）中的漏洞進行的攻擊，對建構管道的攻擊（例如：SolarWinds、Kaseya和Codecov黑客攻擊），或黑客破壞軟體包存儲庫本身。
而正由于軟體供應鍊攻擊變得如此普遍，以至于Gartner将其列為2022年的第二大威脅。
什麼是軟體供應鍊安全？
企業軟體項目越來越趨于依靠第三方和開源元件，該類元件由個人建立和維護，由于其與開發重要軟體的組織無雇傭關系，是以第三方不一定使用與軟體開發組織相同的安全政策。
這點存在着一定的安全風險，因為個人建立的安全政策與組織建立的安全政策二者之間存在着差異或不一緻性，這可能會導緻出現易被忽視的脆弱區域，進而給攻擊者以可乘之機。
第三方軟體元件主要來源于兩個方向：一是直接來自于供應商，一是來自于集中的系統資料庫和存儲庫，上述供應商和存儲庫構成了現代軟體供應鍊。攻擊者可以通過多種方式危害軟體供應鍊安全，包括：利用第三方元件中存在的錯誤或漏洞；破壞第三方開發環境并注入惡意代碼；建立惡意的虛假元件。
而供應鍊安全就在于預防、檢測和緩解該類風險以及來自于組織以外第三方元件的任何其他風險。此外，軟體供應鍊還應該包括各種人員，如外包公司、顧問和承包商。是以，軟體供應鍊安全也可将風險管理和網絡安全原則結合起來。這樣做可以檢測、減輕和最小化與應用程式中這些第三方元件相關的風險。
軟體供應鍊安全風險來自哪裡？
軟體供應鍊風險的存在是因為企業對供應鍊的信任。例如，沒有人覺得微軟會釋出一個安全更新檔，将他們的環境暴露給攻擊者。攻擊者恰恰利用了這種信任，因為他們知道大多數開發人員不會不遺餘力的交叉檢查他們正在使用的軟體。
而且由于企業對供應鍊的信任，開源項目也是軟體供應鍊安全風險之一。例如，對開源項目的送出權限通常授予受信任的貢獻者，若是攻擊者破壞了一個受信任的賬戶，他們可以将惡意代碼插入到存儲庫中，那麼開發人員不知不覺的使用了這些代碼，進而無意中打開了對環境的通路權限，讓企業陷入危險境地。
再者，軟體供應鍊安全風險還來自于外部攻擊。以軟體應用程式為例，軟體應用程式的生命周期包括設計、生産、傳遞、部署、使用及營運、停止等階段，而面向此生命周期所涉及的分工協作、聯合攻關、平台環境等就是軟體供應鍊的主要内容，也是以，軟體供應鍊的主要攻擊類型也與這些環節密切相關。
例如，在生産階段（包括軟體應用程式的開發、內建、建構等），供應鍊攻擊類型主要包括三類：
第一類是針對軟體生産要素的攻擊，即攻擊者利用安全漏洞、後門等修改編碼環境、源碼庫等開發工具或軟體自身，植入惡意代碼，并經網絡、存儲媒體等進行傳播，使用者下載下傳使用後，引入風險；
第二類是開發者對所使用的第三方軟體，特别是開源元件未經安全測試而直接使用，不了解其中的安全漏洞和法律風險；
第三類是軟體産品建構時，在編譯和連結、産品容器化、打包等過程中，使用的工具或産品對象本身被污染或惡意修改而帶來的安全風險，如 Codecov事件。
在傳遞和營運階段（包括軟體應用程式的釋出、傳輸、下載下傳、安裝、更新檔更新等），網際網路或移動傳輸媒體是其重要手段。因而，軟體供應鍊安全風險主要展現在這幾方面：
在釋出和下載下傳方面，釋出管道或商城如對軟體安全性缺乏分析和測試則會存在潛在風險；攻擊者可通過捆綁攻擊，在常用軟體中捆綁額外功能，如果這些功能涉及使用者隐私、資訊的收集，則後患無窮；針對釋出站點的攻擊，如域名劫持（DNS）、内容分發系統（CDN）緩存節點篡改等，會使使用者下載下傳存在惡意代碼或後門的軟體。
在軟體更新和更新方面，攻擊者可能通過中間人攻擊替換更新軟體或更新檔包，或誘導使用者從非官方釋出管道下載下傳，以達到攻擊的目的，也可能使用捆綁攻擊在更新包中增加額外軟體功能。例如，許多公司每個月都會釋出新的安全更新檔，這些更新檔會被成千上萬的開發人員下載下傳，已部署到他們的項目和CI（持續內建）/CD（持續傳遞）管道中。如果攻擊者可以操縱一個更新，那麼他們就可以輕松的通路部署該更新的所有系統。
另外，第三方開發人員也是軟體供應鍊安全風險之一。例如，許多公司現在雇用承包商或自由職業者進行應用程式開發，如果沒有進行适當的背景調查，惡意的外部組織可以輕松的竊取資料或IP，以擷取經濟利益或從事工業間諜活動。
而上述僅是軟體供應鍊安全的部分風險，此外還包括證書被盜、軟體開發工具被破壞、裝置預先安裝了惡意軟體等等安全風險。
如何應對軟體供應鍊安全風險？
為了確定軟體供應鍊的安全性，需要對應用程式的每個部分都有一個清晰的視圖和控制，可以從以下幾點着手：
一，推廣使用軟體物料清單（SBOM）：軟體物料清單（SBOM）是一種正式的、結構化的記錄。它不僅對軟體産品的元件構成進行了詳細的說明，同時還描述了這些元件之間的供應鍊關系。SBOM概述了應用程式中引入的包和庫，以及這些包、庫與其他上遊項目之間的關系。這在重用代碼與引入開源代碼的時候非常有用。
軟體物料清單（SBOM）可以幫助開發人員和使用者了解他們開發和使用的軟體所包含的内容，幫助組織了解依賴關系網絡及其軟體開發過程的攻擊面。因而，一個合适的SBOM，可以幫助組織對自己所部署的包以及這些包的版本有一個确切的了解，進而便于組織根據自己的需要來進行更新，以維護安全。
但需要注意的是，SBOM對于已經擁有軟體元件和API資産管理的組織最為有用；靜态格式的SBOM隻能提供軟體當時的情況相關資訊，而無法時刻更新即時的相關内容；為了使資料更加有意義，SBOM必須具有連續傳遞和通路的能力。
二，找到并快速修複漏洞：軟體供應鍊攻擊的罪魁禍首是未打更新檔的軟體。一旦漏洞公告釋出給公衆，攻擊者就會搜尋未打更新檔的系統并加以利用。是以，公司的IT團隊必須利用SCA工具來發現第三方代碼中的漏洞，并提出更新檔和更新等修複方法。
此外，雖然一些供應鍊攻擊方法利用了未知（零日）漏洞，但還是有很多攻擊利用了已知漏洞。基于此點，企業還可以利用軟體材料清單（SBOM），識别存在已知漏洞的元件，并應用相關更新或更新檔。快速識别和修複第三方元件中的漏洞是預防供應鍊攻擊的主要政策。
三，評估軟體供應鍊：為了讓應用程式的依賴關系具有完全的可見性，需要對一些問題進行評估，例如：開發生命周期的每個步驟涉及到什麼；是否有承包商具有代碼通路權限；誰安裝軟體更新，如何安裝，等等。
企業應稽核其所有應用程式以及授予内部和外部各自的通路權限。理想情況下，這應該有完備的文檔記錄和高度自動化的流程。這樣，當發生一些突發情況時，可以很快找出誰有通路權限。
企業還需要了解其軟體組合中使用的元件，并且充分認識和了解元件、系統和源代碼之間的關系。當發現漏洞時，開發人員需要知道易受攻擊的元件在多個軟體項目中的使用位置，以便能夠進行快速修複或删除。另外，一旦發現問題元件，就應該對之進行标記，進而確定所有開發團隊都清楚該問題元件。
在評估軟體供應鍊時，還要評估任何潛在合作夥伴的可信度、服務曆史、過去的項目和市場聲譽。對于個人來說，要經常進行嚴格的背景審查，以确定諸如犯罪記錄或破産申請之類的危險行為；對供應商和服務提供商進行類似的盡職調查，事實上，一些法規要求某些供應商必須具備ISO 27001這樣的資質。
四，持續監控第三方，持續監控元件：持續監控第三方有助于減輕供應商洩露或攻擊的影響，例如在暗網中暴露出來的證書或者任何過去資料洩露的曆史，企業可以要求并檢查任何供應商的安全文檔，以確定其政策和程式符合行業最佳實踐和相應安全标準。
持續監控元件，即使一個元件已經被确定為安全元件，也不意味着它會保持安全。新的漏洞會不斷出現，元件使用壽命也可能已快要耗盡，或者其開源貢獻者可能會放棄元件并對其停止支援。在所有這些情況下，企業必須能夠檢測到元件風險狀态的變化，确定風險嚴重程度的優先級，并在必要時關閉元件。
最後，值得一提的是，企業需要建立一個事故響應計劃，一個有效的災難恢複計劃應該包括傳統的備份或故障轉移站點，同時經過測試的恢複機制可以防止系統受到勒索軟體的攻擊。