軟件供應鏈風險趨勢
了解易受攻擊的風險點位置，對于保障軟件供應鏈安全非常重要。但是，利用單點解決方案來逐一應對的做法，就如同打地鼠游戲，被擊碎的威脅可能在未注意的其他地方再次出現。
為全面保護供應鏈免受威脅，要從頭到尾始終保持警惕，甚至在開發者調用外部軟件包之前就要開始注意。不論是在專有代碼開發、代碼編譯和臨時構建環節，還是在整體運算流水線中進行發布和分發，直到生產，乃至部署后，都要事無巨細地關注。除了揭示漏洞和其他安全問題，還需要知道具體場景，以便判斷出真正的風險。
軟件供應鏈威脅兩大主要途徑
第一種是利用供應鏈的“開放性”來獲取攻擊者計劃攻擊的軟件信息。一個常見的例子是，攻擊者試圖遠程映射一個網絡服務，或者釋放一個面向物聯網設備的軟件，從而熟悉其使用的開源包。然后，他們就能輕松地找到與這些軟件包相關的通用漏洞披露(CVE)信息，了解軟件包的安全配置，甚至嘗試尋找未知的漏洞(又稱零日漏洞)。當充分掌握有關漏洞利用路徑的信息后，攻擊者就可以進入第二階段了。
第二種是攻擊者會利用供應鏈，將惡意軟件包和惡意代碼注入公共或私人資源庫，或改變現有的代碼并將惡意部分納入其中。
四大突出風險威脅軟件供應鏈安全
1. 已知漏洞
第三方組件(如開源和商業軟件)可能帶有非故意性質的漏洞，其中許多是已知的，并已在NVD和VulnDB的漏洞數據庫中被公開追蹤。
可以通過軟件組件分析(SCA)解決方案來揭露這種風險，該解決方案可以識別特定代碼或制品的軟件物料清單(SBOM)，并將其與已知的CVE聯系起來，主要是將已識別的軟件元數據與公共CVE數據庫進行交叉引用。
但是，還需要獲得足夠多的信息以便制定基于風險的決策，并使之自動化。一個可擴展的數據庫是必須的，不僅可以追蹤更多風險，還包括進行深入地安全研究，有助于了解能夠降低這些風險的所有方式，從而選擇最實用且最具成本效益的方法。
同樣重要的還有場景分析，以此確定漏洞被利用的可能性。例如，組件中易受攻擊的功能可能不會被應用程序使用，或者易受攻擊的程序從未在生產版本中運行，或者特定的配置會導致給定的CVE失效。
也可以從看似安全的組件中識別出可能的運行風險。例如，一個很久沒有維護的開源包可能未針對安全問題進行充分監控。在此情況下，漏洞是不確定的，但潛在的威脅是可預見的。
這些已知的和可預期的風險能夠而且應該在以下幾個方面發現：
· 源代碼：將安全警惕性左移到代碼創建之時，可以節省后期修復的成本。安全團隊可以構建一個獲批第三方組件的內部資源庫，開發人員可以通過對其集成開發環境(IDE)的擴展來獲得對薄弱依賴項的警報。雖然本質上是不完整的，但這種方法有助于避免已知的風險。需注意的是，它不可能是詳盡的，因為左移的安全工具通常會讓開發者承擔成百上千的工作任務，而這些工作任務從安全的角度來看不一定有影響，因為它們會忽略漏洞或安全問題的完整場景。
· 二進制文件：對關鍵二進制存儲庫(包括第一和第三方組件)中的所有軟件包、構建和圖像進行自動軟件成分分析(SCA)掃描，確保整個軟件供應鏈受到保護，免受已知漏洞和運營風險的影響。作為應用程序生產階段狀態的最準確的代表，二進制文件能夠對風險進行最高質量的真實分析，并提供更準確的場景。借助二進制文件，還能分析對左移工具和生產中安全解決方案來說是“盲點”的問題。
2. 未知漏洞(零日漏洞)
編碼中的錯誤很常見。邏輯缺陷、不良加密和潛在的內存損壞都會無意中導致應用程序易受惡意攻擊，如遠程代碼執行(RCE)和拒絕服務(DoS)。這些錯誤可能潛伏在第一和第三方代碼中而不被發現，甚至在被識別前已潛伏數年。
這些問題被稱為“零日”問題，部分原因在于其存在時間長，但也因其緊迫性，而意味著團隊能夠在已部署軟件中對其進行修復的時間為零。
為捕捉和防止潛在的零日問題，必須將不同二進制文件、進程和服務之間的流通性納入考量，對每個組件與應用程序進行測試。靜態代碼分析(審查代碼源)和動態代碼審查(測試運行中的代碼)工具通常各自能夠識別約85%的缺陷，但他們通常會在每個版本中產生成千上萬的條目，并且需要專業知識來闡釋結果并確定優先次序。不過，一個可能存在的漏洞，但并不意味著它一定可以會被攻擊。
更先進的技術結合了符號執行、數據流分析和自動模糊測試，可以顯著降低誤報率，并識別典型 SAST/DAST 無法發現的漏洞。結合對源代碼和二進制文件的分析，也可以產出更完善的結果，并幫助開發者、安全團隊和生產經理專注于修復重要問題。
縱然竭盡所能，但還是可能會發現新的漏洞并影響到已部署的軟件。持續的SCA掃描有助于確保迅速獲得任何會影響生產階段軟件的最新CVE通知。豐富的SBOM元數據有助于迅速了解漏洞對機構的全部影響，并在整體應用程序庫存中應對或補救。將代碼和制品庫適當進行整合，可以在整個機構內迅速采取行動，應對已發現的威脅。
3. 非代碼問題
并非所有的漏洞都存在于代碼之中，還可能存在于二進制文件(如EPMs)、jar文件容器、固件以及支持性制品(如配置文件或IaC文件)中。錯誤配置、不良加密、秘鑰和私鑰的暴露，或操作系統問題都會導致受攻擊面出現。
這些人為錯誤的副作用通常是由于缺乏關注而造成，并不是惡意為之，而且通常是在主要開發的熱點之外引入的。用于測試的配置可能被不經意地推廣到生產階段。這些風險通常易于解決，但難于被發現，也更難于恢復。
即使是良好的意圖也可能導致惡意的后果，例如，在公共服務器上暴露密碼，就可能招致惡意代碼注入，從而暴露敏感數據。類似名稱的軟件包之間的依賴項混淆也可能在非30惡意的情況下發生，特別是當軟件包庫解析配置不良的情況下。
在這些問題發展到生產階段之前，及早發現是至關重要的。需要像對待代碼中的漏洞一樣認真對待這些潛在風險，并將這種警惕性納入流水線端到端安全態勢中。
4. 惡意代碼
故意的威脅(無論是來自外部注入攻擊還是惡意的內部人員)往往是最難發現的，因其經常被掩蓋，而顯示為已經驗證的組件。特洛伊木馬、機器人程序、勒索軟件、加密軟件和間諜軟件的傳播通常是以較為良性的漏洞類型作為有效載體。利用有害的軟件包來植入常用存儲庫，入侵維護員賬戶以改變現有軟件包，或將代碼注入被破壞的源存儲庫，都是后門訪問攻擊的常用方法。
在部署后發現上述攻擊，通常為時已晚，損害已經造成，而且可能代價非常高昂。這就是為什么應該在整體流水線中對其進行保護：
· 訪問控制：內部軟件包庫必須通過整個機構內始終一致的權限和安全認證(包括多因素認證)，將寫入權限限制為關鍵角色和團隊成員。
· 代理存儲庫：緩存外部存儲庫(如Maven Central和npm)可提供不可篡改的第三方資源快照，因此任何后續的惡意覆蓋都會立即顯現出來。
· 測試和分析：先進的靜態和動態分析工具可以檢測和標記惡意代碼和有問題的軟件包。JFrog安全研究團隊已經通過自身開發的工具，在公共軟件包庫中發現并披露了1300多個惡意軟件包。
軟件供應鏈風險管理的端到端警惕性
雖然這些風險趨勢中的一些問題能夠一次性解決，但單點解決方案只能作為警報系統，而且只在需要之處才能起到幫助。
鑒于同樣的原因，單獨的安全解決方案能夠起到的幫助也是有限的，因其能力范圍有限，因此無法幫助分析和判斷整個軟件供應鏈中風險的完整場景。當與存儲庫和軟件管理解決方案脫節時，即使安全單點解決方案非常準確，也很難針對所發現的問題采取有效的行動來進行補救和應對。
全面的安全態勢不能只關注流水線中孤立的各個點，必須能夠將不同問題和安全方面的發現這些眾多點聯系起來，而這是單獨的小眾解決方案所無法做到的。
為維護軟件安全，就需要做到端到端的警惕，從開發者的IDE一直到生產階段，在開發和生產環境中執行一致的風險監督并落實應對措施。安全解決方案必須應用于整個軟件供應鏈，并能夠大規模采取行動。為確保整個機構內的一致性，其運營必須圍繞所有二進制文件的單一可信來源，并與開發運維工具深度集成。
京公網安備 11010502049343號