軟體供應鏈攻擊正變得越來越普遍,破壞性也越來越大。例如, Gartner公司 預測顯示,到2025年,45%的企業將遭遇資料外洩。此外, 網絡安全風險投資 這凸顯了這項威脅的嚴重性,預計到2031年,每年的損失將高達138億美元。總而言之,這些預測顯示各組織迫切需要優先考慮以下事項: software supply chain security 並實施強有力的措施來保護敏感資料、營運和聲譽。
因為現代 pipeline軟體嚴重依賴外部元件、第三方函式庫的興起、更快的軟體開發週期、複雜的供應鏈、缺乏可見性、新的攻擊技術、SaaS 的採用以及有限的資源,所有這些因素都在推動軟體的激增。 軟件供應鏈攻擊因此,各組織必須採取全面積極的方式來應對這些挑戰,並保護其軟體供應鏈。
什麼是軟體供應鏈攻擊?
ENISA 定義一個 軟體供應鏈攻擊 as “對特定資產(例如軟體提供者的基礎設施和商業軟體)的損害,以間接損害某個或多個目標(例如軟體提供者的客戶)。” 換句話說,軟體供應鏈攻擊是一種針對軟體供應鏈的惡意活動,旨在破壞軟體的開發和分發流程,並在其中植入漏洞或惡意軟體。因此,這類攻擊會利用軟體建置和交付過程中涉及的相互關聯且通常十分複雜的流程、工具和實體網路。
軟體供應鏈攻擊的關鍵組成部分和概念
網路威脅情報和資訊安全文獻經常出現漏洞 軟件供應鏈攻擊 為了更好地進行分析和辯護,我們將這些概念歸納為不同的類別。因此,本節將介紹以下五個關鍵概念: MITRE攻擊模式目錄本目錄對供應鏈攻擊模式進行結構化,以便利用各種來源(包括 NIST 收集的對抗性威脅)進行分析。
攻擊法案:究竟是什麼
攻擊行為是指向系統傳遞惡意負載或意圖的具體操作,因此會造成直接損害。
- 範例 1:在建置過程中將惡意軟體插入系統軟體。
- 範例 2:系統需求或設計文件被惡意竄改。
攻擊向量:如何
攻擊向量是指攻擊者利用漏洞或流程弱點的方法。因此,它展現了攻擊者如何存取和濫用攻擊面。
- 範例 1:攻擊者修改了被入侵程式碼庫中的原始程式碼。
- 範例 2:攻擊者未經授權存取內部技術文件。
在我們的網站上進一步探索 攻擊向量術語表 以獲得更多見解。
攻擊起源:誰人樂隊
攻擊源標識了攻擊的來源。因此,它可以明確攻擊者的角色、身分或與系統的關係。
- 範例 1:具有建置伺服器特權存取權限的內部人員修改了腳本。
- 範例 2:外部威脅行為者將木馬程式包上傳到公共註冊表。
進攻目標:原因
該目標解釋了攻擊背後的原因。最重要的是,它突顯了對手想要達成的目標。
- 中斷:停止服務或建設。
- 腐敗:透過更改工件或原始碼來降低信任度。
- 洩密:洩漏敏感機密或智慧財產權。
攻擊影響:後果
最後,影響部分描述了攻擊的結果,顯示了對軟體提供者和客戶的影響。
- 例 1:任何使用劣質程序的項目,日後都會出現問題。
- 例 2:人們在不知情的情況下將惡意軟體安裝到工作系統中。
最常見的軟體供應鏈攻擊
多種類型的 軟件供應鏈攻擊 這些威脅確實存在,組織必須了解生命週期每個階段中存在的各種威脅載體。基於 SLSA框架, 美國國家研究所 Standards 和技術(NIST)以及 網路安全和基礎設施安全局(CISA)這些威脅可分為四類:原始碼風險、建置風險、軟體包風險和依賴項風險。
軟體供應鏈源階段攻擊
- 提交錯誤代碼 → 看詳情 Flask request.get 的誤用 or 不安全的反序列化缺陷 建立直接攻擊面。
- 洩漏原始碼庫
- 從修改後的源代碼構建
- 編寫不安全的程式碼
- 篡改關鍵文件 → 如前所述 chmod 777 後門分析.
建構階段的軟體供應鏈攻擊
在 建構階段開發人員將程式碼編譯並整合到可運行版本中。 因為 這一階段至關重要,風險包括跳過安全檢查。 CI/CD pipeline在版本控制之後更改程式碼,或破壞建置過程。 所以惡意程式碼可以悄無聲息地潛入工件中。
- 繞行 CI/CD → 連結到 GitHub 預先建置惡意軟體.
- 在原始碼控制之後修改程式碼
- 妥協建造過程 → 透過以下方式緩解 DevSecOps早期預警偵測.
- 破壞工件庫
軟體包階段的軟體供應鏈攻擊
这 包裝階段 這就是我們將所有程式碼整合在一起,產生最終產品的過程。這一步驟風險很高,因為有人可能會使用惡意軟體包,或更改我們獲取軟體包的線上來源。攻擊者甚至可以將常用軟體包的惡意版本上傳到這些網站。
- 使用被入侵的軟體包 → 涵蓋 惡意軟體掃描器評估.
- 妥協軟體包註冊表
- 上傳修改後的軟體包 → 已分析 Namso-gen 偽造生成器惡意軟體.
依賴階段的軟體供應鏈攻擊
在 依賴階段我們會在軟體中新增第三方函式庫和軟體包。這個階段風險很高,因為這些部分出現的任何問題都可能輕易且悄無聲息地蔓延到專案的其他部分。
- 使用妥協依賴 → 解釋如下 混淆依賴關係中的拒絕服務風險.
- 過時或易受攻擊的依賴項
- 傳遞依賴風險
- 惡意軟體包註冊表 → 已透過以下方式緩解 DevOps 安全工具 以及 第三方風險管理.
供應鏈各階段的常見風險 SDLC
| 階段 | 典型威脅 | 例 |
|---|---|---|
| 來源 | • 提交惡意或不安全的程式碼 • 篡改關鍵文件 • 破壞原始碼庫 | XcodeGhost(2015): 惡意程式碼被注入到蘋果公司的 Xcode 編譯器中,並在 iOS 應用程式中傳播。 |
| 建構 | • 繞過 CI/CD 安全檢查 • 在原始碼控制之後修改程式碼 • 破壞製品庫 | SolarWinds Orion(2020): 攻擊者滲透到了建築物中 pipeline在已簽署的軟體更新中插入後門。 |
| 小包裝 | • 上傳修改後的軟體包 • 中毒包裹登記處 • 分發受損物品 | EventStream NPM(2018): 攻擊者在一個下載量達數千次的熱門 NPM 包中植入了後門。 |
| 依賴 | • 使用過時或存在漏洞的依賴項 • 利用傳遞依賴關係 • 發布惡意仿冒軟體包 | XZ Utils 後門(2024): 一個被植入木馬的壓縮庫差點被打包到 Linux 發行版中。 |
常見的軟體供應鏈攻擊技術
根據 CIS根據美國國家標準與技術研究院 (NIST) 的報告,軟體供應鏈攻擊通常分為三大類。
然而,最近發生的事件表明,開發人員必須了解其他一些因素。
以下我們將結合實際例子,詳細介紹最相關的技術。
劫持更新
攻擊者利用合法的更新機制傳播惡意軟體。
例如,2017 年的 NotPetya 攻擊濫用了烏克蘭 MEDoc 稅務軟體更新伺服器,導致大量資料外洩。
破壞性擦除惡意軟體偽裝成修補程式。為了防範這種風險,團隊應應用以下措施: DevOps 的威脅偵測與回應 標記更新流程中異常行為的實務。
破壞程式碼簽名
這種技術涉及濫用或竊取有效的簽名證書,使惡意程式碼看起來像是合法的。
一個值得注意的案例是 2017 年的 CCleaner 漏洞,攻擊者分發了帶有有效憑證簽署的木馬軟體。
因此,組織需要統一的完整性控制措施,例如下文所述的那些措施。 網路安全平台策略
損害開源程式碼
攻擊者在流行的開源軟體包中植入後門,這些後門隨後被引入到數千個專案中。
EventStream NPM 事件和 XZ Utils 後門(2024 年)說明了這一途徑的重要性。
開發人員應該查看類似這樣的資源。 NPM 安全常見問題解答 以及 拼字錯誤包裹事件 學習如何避免依賴中毒。
依賴性混淆
該攻擊最早由 Alex Birsan 於 2021 年描述,它利用內部和公共軟體包註冊表之間的命名衝突,誘使構建系統拉取惡意版本而不是受信任的內部軟體包。
域名搶注和惡意包裹
攻擊者發布名稱與流行庫相似的惡意軟體包(例如,「requests」而不是「requests」)。
開發人員可能會不小心安裝這些程序,從而將惡意軟體引入到他們的專案中。
本文分析了一個真實案例。 Namso-gen惡意軟體 並且在我們的名單中 開源惡意軟體掃描器。
建構 Pipeline 篡改
從 SolarWinds Orion 漏洞事件中可以看出,攻擊者可以滲透建置伺服器,在編譯過程中註入惡意程式碼。
這使得整個簽章工件鏈都不可信。預防技術包括監控。 CI/CD 誠信 預警偵測 並分析
GitHub 預先建置惡意軟體攻擊活動。
軟體供應鏈攻擊的典型案例:SolarWinds 案例
最重要的是,SolarWinds Orion攻擊是軟體供應鏈漏洞最廣為人知的案例。它揭示了攻擊者如何一步步滲透到建置過程中,最終將有害程式碼傳播給成千上萬的用戶。
首先,攻擊者入侵了 SolarWinds 的建置伺服器。
之後,他們悄悄地在Orion更新中加入了惡意程式碼。
由於這些更新程式經過簽名並作為可信任軟體發布,許多公司在不知情的情況下安裝了它們。
總計超過 18,000 個組織受到影響,攻擊者獲得了對非常敏感系統的存取權限。
從開發者的角度來看,這次攻擊為我們帶來了三個簡單的教訓:
- 外線防守還不夠。攻擊者更改了構建 pipeline 本身。
- 持續檢查至關重要: 安全的 build attestations完整性檢查和異常檢測有助於阻止篡改。
- 一個中毒的流派就能席捲全球。單一 pipeline 妥協可能引發全球安全危機。
Xygeni:終極一體化應用安全平台
因為軟體供應鏈攻擊可以發生在每一個環節… SDLC,
一體化應用安全平台 XygeniXygeni 可保護原始碼、建置、打包和相依性階段。它為開發人員和安全團隊提供了一個平台,讓他們能夠以簡單的方式預防、偵測和修復風險。因此,您不再需要管理多個工具,Xygeni 可涵蓋整個生命週期。
源級保護
在源頭階段,風險包括不安全因素。 commits、被污染的儲存庫或被竄改的檔案。 Xygeni即時掃描代碼 深 SAST 以及秘密檢測。
它還能阻擋有害物質 commit通過 CI/CD guardrails.
這樣一來,問題就能在離開程式碼庫之前就被阻止。
建置階段保護
在建置階段,攻擊者可能會嘗試繞過 pipeline或改變人工製品。
Xygeni 確保建置流程的安全。 它具備符合 SLSA 標準的檢查、完整性驗證和無金鑰簽章功能,也會監控內部異常行為。 CI/CD 因此,篡改過的版本會立即被標記出來,並在發布前被封鎖。
包裝階段保護
在軟體包階段,被竄改的登錄或被修改的程式庫通常會引入惡意軟體。 Xygeni 的惡意軟體偵測和許可證掃描 檢查每件物品,同時 自動修復建議安全的升級路徑 透過補救風險分析。只有經過驗證且符合規定的方案才能進入下一階段。 pipeline.
依賴階段保護
第三方程式碼是最大的攻擊面。 Xygeni 的軟體成分分析(SCA) 它不僅列出 CVE,還會檢查風險代碼是否真的可被利用。它還會標記隱藏的惡意軟體和有風險的傳遞依賴項。最重要的是,這確保了開發人員只發布安全的依賴項。
機密資訊和基礎設施安全
除了程式碼和軟體包之外,攻擊還經常利用洩漏的密鑰或薄弱的基礎設施。 Xygeni 會掃描暴露的金鑰、令牌和憑證。 在程式碼、配置和 Docker 層中。它還可以驗證並自動撤銷洩漏的金鑰。 自動修復。 與此同時, IaC 掃描 防止攻擊者日後可能濫用的錯誤配置。
更聰明的檢測與修復
大多數工具僅止於發出警報。 Xygeni更進一步。 它的自動修復引擎會產生安全補丁, pull requests根據具體問題,它會提供逐步指導。其「修復風險」視圖還會顯示哪個修補程式版本最安全,以便團隊在修復問題的同時避免引入新問題。
一個統一的平台
因為 Xygeni 結合 SAST, SCA惡意軟體檢測、金鑰管理 IaC 在一個應用安全平台中整合掃描、異常檢測和安全建構控制功能
它提供了全面的覆蓋範圍 SDLC開發人員和安全團隊都能獲得一個統一的資訊來源,清晰的可見性、實用的修復方案以及針對供應鏈攻擊的強大保護。
所有的情況都被考慮到了, Xygeni,終極一體化應用安全平台它幫助團隊快速建置並確保安全。透過保護原始碼、建置、打包和相依性階段,並在每個步驟中添加自動化修復,它確保軟體供應鏈攻擊在到達生產環境之前就被阻止。




