周五凌晨，Aqua Security安全工程師Itay Shakury在GitHub上發(fā)布了一則簡短聲明。他用了最克制的技術語言，卻藏不住事情的嚴重性——Trivy，這個被3.3萬開發(fā)者標星、廣泛嵌入CI/CD（持續(xù)集成/持續(xù)部署，一種自動化軟件發(fā)布流程）管道的漏洞掃描工具，幾乎全軍覆沒。

攻擊者用被盜憑證完成了"強制推送"（force-push，一種覆蓋Git歷史記錄的危險操作）。除了0.35.0版本，所有trivy-action標簽和七個setup-trivy標簽都被替換為攜帶惡意依賴的版本。這意味著什么？全球數(shù)以萬計的軟件構建流水線，可能在不知情的情況下執(zhí)行了攻擊者的代碼。

Shakury的補救建議直截了當："如果你懷疑運行過被篡改的版本，請立即將所有流水線密鑰視為已泄露并輪換。"沒有迂回，沒有安撫。

攻擊者如何藏進你的構建流程

供應鏈攻擊的可怕之處，在于它劫持的是"信任"本身。Trivy不是某個邊緣小工具——它是開發(fā)者用來掃描漏洞、檢測硬編碼密鑰的標準組件。當掃描器本身成為攻擊載體，防御者的第一道防線就變成了最隱蔽的后門。

根據(jù)安全公司Socket和Wiz的分析，這次攻擊的技術設計相當精細。惡意代碼被觸發(fā)后，會并行啟動兩個進程：一個是正常的Trivy服務，維持表面上的功能；另一個是隱蔽的數(shù)據(jù)收集模塊。

這個模塊的狩獵范圍極廣：GitHub令牌、云服務商憑證、SSH密鑰、Kubernetes令牌，以及任何可能散落在開發(fā)環(huán)境中的敏感信息。它還會收集環(huán)境變量、遍歷文件系統(tǒng)、枚舉網(wǎng)絡接口—— essentially，把一臺機器能暴露的攻擊面掃了個遍。

數(shù)據(jù)被壓縮加密后，通過主備雙通道外傳到攻擊者控制的服務器。如果檢測到運行在開發(fā)者本地機器上，它還會寫入一個base64編碼的Python持久化程序，確保即使重啟后仍能維持訪問。

被篡改的版本標簽包括廣泛使用的@0.34.2、@0.33、@0.18.0。這些不是實驗性版本，是生產(chǎn)環(huán)境中的默認選擇。

為什么"強制推送"成了致命漏洞

Git的強制推送機制，本意是給開發(fā)者一個"后悔藥"——當你需要重寫歷史記錄時可以使用。但它也是一把雙刃劍：一旦憑證泄露，攻擊者可以用它徹底覆蓋倉庫的提交歷史，讓惡意代碼看起來像是官方發(fā)布的一部分。

Trivy的維護者在攻擊發(fā)生后刪除了攻擊者發(fā)布的事發(fā)討論帖，但損害已經(jīng)造成。從周四凌晨攻擊開始，到周五確認，窗口期內(nèi)的任何自動拉取都可能中招。

這里暴露的是一個結構性問題：開源生態(tài)的"星標信任"模式。3.3萬GitHub星標意味著廣泛采用，但廣泛采用不等于安全審計的同步跟進。大多數(shù)團隊將Trivy集成到流水線后，很少會驗證每次拉取的哈希值或簽名——他們信任的是"這個工具一直被用，所以應該沒問題"。

攻擊者正是利用了這種慣性。CI/CD環(huán)境的特殊性加劇了風險：這些流水線通常持有高權限憑證，能訪問生產(chǎn)環(huán)境、代碼倉庫、云基礎設施。一旦掃描環(huán)節(jié)被攻破，攻擊者獲得的不是單點突破，而是橫向移動的"萬能鑰匙"。

開發(fā)者的兩難：便利與安全

這次事件拋出了一個殘酷的選擇題。Trivy的價值恰恰在于它的"無摩擦"集成——幾行YAML配置，就能在每次代碼提交時自動掃描漏洞。但這種便利的代價是，你默認將執(zhí)行權限交給了上游倉庫。

更深層的問題在于版本標簽的語義模糊性。@0.34.2看起來是個精確鎖定，但在GitHub Actions的語境下，它仍然指向一個可移動的引用。攻擊者的強制推送讓同一個標簽指向了完全不同的代碼內(nèi)容，而大多數(shù)流水線配置不會察覺這種變化。

一些團隊開始采用"哈希鎖定"作為防御——不引用標簽，而是直接指定提交的SHA-256哈希。這確實能防止類似攻擊，但代價是失去了自動安全更新的便利。每次Trivy發(fā)布合法更新，你都需要手動審查并更新哈希值。對于安全團隊人力有限的中型公司，這幾乎是個不可持續(xù)的負擔。

另一種方案是使用私有鏡像倉庫，將外部依賴緩存到內(nèi)部并經(jīng)過審計后再分發(fā)。但這需要額外的基礎設施投入，而且緩存本身也有滯后性——你如何在攻擊發(fā)生的幾小時內(nèi)識別出惡意版本？

供應鏈攻擊的進化軌跡

回顧近年的類似事件，攻擊者的策略正在從"廣撒網(wǎng)"轉(zhuǎn)向"精準打擊"。2020年的SolarWinds事件針對的是IT管理軟件，2021年的Codecov攻擊瞄準了代碼覆蓋率工具，2023年的3CX事件則波及了通信軟件。Trivy的案例延續(xù)了這一模式：找到開發(fā)者工具鏈中的高信任節(jié)點，然后靜默潛伏。

這些攻擊的共同點在于，它們都利用了"開發(fā)者的開發(fā)者"這一身份。當攻擊代碼出現(xiàn)在你用來檢查安全的工具里，傳統(tǒng)的防御假設——"我的掃描器會告訴我是否安全"——瞬間失效。

Socket和Wiz的聯(lián)合分析揭示了一個細節(jié)：惡意代碼會根據(jù)運行環(huán)境調(diào)整行為。在CI/CD服務器上，它專注于快速竊取密鑰；在開發(fā)者本地機器上，它會額外部署持久化機制。這種環(huán)境感知能力說明攻擊者做過充分的偵察，了解不同場景下的價值密度。

加密外傳的機制也經(jīng)過設計：數(shù)據(jù)被壓縮減少傳輸量，加密規(guī)避網(wǎng)絡層的DLP（數(shù)據(jù)防泄漏）檢測，雙通道確保即使主通道被阻斷仍有備份。這不是腳本小子的即興發(fā)揮，是專業(yè)團隊的系統(tǒng)作業(yè)。

行業(yè)層面的信任重構

Trivy事件可能加速幾個趨勢。首先是"可驗證構建"（Reproducible Builds）的落地——通過密碼學證明，某個二進制確實由公開的源代碼編譯而來，而非被篡改的中間產(chǎn)物。Linux發(fā)行版多年前就開始推行這一實踐，但應用層工具鏈的 adoption 一直緩慢。

其次是簽名基礎設施的升級。GitHub在2023年推出了 artifact attestation（制品證明）功能，允許Action的發(fā)布者用Sigstore進行簽名驗證。但 adoption 率仍然有限，很多主流工具尚未啟用。Trivy攻擊后，"有沒有簽名"可能成為選擇依賴的新標準。

更激進的方案是"供應鏈防火墻"——在組織邊界處攔截所有外部依賴，進行靜態(tài)分析、動態(tài)沙箱測試后再放行。Google的SLSA框架、OpenSSF的Scorecard都在推動這類實踐，但實施成本決定了它目前主要是大型企業(yè)的游戲。

對于中小團隊，更現(xiàn)實的可能是"最小權限流水線"原則：假設任何工具都可能被攻破，因此限制CI/CD環(huán)境的訪問范圍。掃描漏洞不需要訪問生產(chǎn)數(shù)據(jù)庫，部署代碼不需要讀取所有倉庫密鑰。通過權限分割，即使Trivy這類工具被利用，損害也能被控制在局部。

Shakury的聲明最后提到了一個數(shù)字：75個trivy-action標簽被確認攜帶惡意代碼，7個setup-trivy標簽同樣中招。這些數(shù)字背后是具體的團隊、具體的項目、具體的凌晨被警報驚醒的值班工程師。供應鏈攻擊的抽象性常常讓人忽視其個體代價，但每一次"強制推送"覆蓋的，都是某個開發(fā)者對"開源協(xié)作"這一社會契約的信任。