Trivy被「借尸還魂」：76個版本標簽同時淪陷

「我們以為修好了，但攻擊者還在里面。」Aqua Security安全團隊在3月22日的更新中寫下這句話時，距離他們第一次宣布「已修復」已經過去了三周。

這場針對開源漏洞掃描工具Trivy的供應鏈攻擊，正在演變成2026年最棘手的安全事件之一。攻擊者沒有粗暴地發布一個帶毒的新版本，而是像篡改檔案館的索引卡片一樣，直接修改了76個歷史版本標簽——讓無數正在運行的CI/CD流水線在「正常掃描」的表象下，默默上交了自己的云憑證。

攻擊者的「時間差」戰術：為什么修復通知反而成了掩護

故事始于2月底的一個配置失誤。Trivy的GitHub Actions環境存在權限配置漏洞，攻擊者借此提取了一枚高權限訪問令牌。3月1日，Aqua Security公開披露事件并執行了憑證輪換，按照常規劇本，這應當是一次標準的安全響應。

但憑證輪換漏掉了一枚。

這枚漏網之魚讓攻擊者在暗處保留了據點。三周后的3月19日，他們發起了第二輪攻勢：向aquasecurity/trivy-action倉庫的76個版本標簽強制推送惡意提交，同時污染了aquasecurity/setup-trivy的全部7個標簽。更隱蔽的是，他們觸發自動化發布流程，將植入后門的Trivy 0.69.4版本推送到各大分發渠道。

這里的手法值得細品。攻擊者沒有創建0.69.5或0.70.0這類容易引起警覺的新版本號，而是選擇篡改現有標簽。這意味著什么？那些依賴@v0.69.4這類浮動版本引用的企業，會在下一次流水線執行時自動獲取被污染的代碼——而他們的日志里只會顯示「Trivy掃描完成，未發現異常」。

惡意代碼的植入位置也經過精心計算：它運行在合法Trivy邏輯之前，完成數據竊取后再把控制權交還給正常程序。整個流程對用戶完全透明，就像酒店清潔人員在客人退房后復制房卡，卻留下房間整潔如常的假象。

被收割的「信任慣性」：為什么你的版本鎖定策略可能是錯的

這次攻擊暴露了一個長期被忽視的盲區：許多團隊對「版本鎖定」的理解停留在表面。

攻擊者明確瞄準了依賴可變版本標簽（mutable version tags）的用戶群體。在GitHub Actions的生態中，@v1、@v0.69.4這類標簽默認可以被維護者重新指向不同的提交。相比之下，固定提交哈希（pinned commit hash）雖然繁瑣，卻能免疫這種「借尸還魂」式的攻擊。

被竊取的數據類型清單讀起來像云原生工程師的噩夢：AWS、GCP、Azure的訪問密鑰，Kubernetes服務賬戶令牌，SSH私鑰，Docker配置文件，各類API令牌。這些憑證從CI/CD環境中被批量抽走，通過加密通道輸送至攻擊者控制的基礎設施。

Aqua Security的商業產品線在此刻顯示出了架構隔離的價值。其付費平臺與開源倉庫物理隔離，采用獨立的發布管道、嚴格的訪問控制，以及故意滯后于開源版本的集成流程。這次事件中，付費用戶確實毫發無損——但這也引出了一個尷尬的對比：開源用戶承擔了更大的攻擊面，卻得不到同等級別的保護。

辯論：開源供應鏈安全，到底該誰買單？

事件發酵后，社區分裂成兩個陣營。

正方觀點：維護者已盡力，用戶需自擔風險

支持者指出，Aqua Security的響應速度在行業內屬于中上水平。從3月1日首次披露到3月19日發現二次入侵，再到3月21-22日周末連續追蹤攻擊者的重新滲透嘗試，安全團隊與全球應急響應公司Sygnia的協作堪稱密集。最終的 remediation 措施也足夠徹底：全面撤銷憑證、棄用長期令牌、推行不可變發布驗證機制。

更深層的辯護來自開源經濟的現實：Trivy作為免費工具，其維護團隊沒有義務為企業的生產環境安全背書。那些將核心基礎設施綁定在浮動版本標簽上的團隊，本質上是在用「方便」交換「風險」——這個等式在出事前從未被認真計算過。

反方觀點：「已修復」的誤導性聲明放大了損害

批評者抓住了3月1日公告的措辭問題。當官方聲稱「已執行憑證輪換」時，任何理性用戶都會理解為威脅已被消除。三周的安全窗口期被浪費，攻擊者得以從容擴大戰果。這種「虛假安全感」比沉默更危險——它讓受害者在不知情的情況下持續暴露。

更尖銳的質疑指向GitHub Actions生態本身。為什么平臺默認允許強制推送覆蓋版本標簽？為什么缺乏對關鍵倉庫的異常操作預警？當攻擊者可以批量篡改76個標簽而不觸發熔斷機制，基礎設施層面的防護缺口同樣難辭其咎。

我的判斷：這是一次「系統性默契」的破裂

雙方都有理，但都回避了真正的問題。開源供應鏈的安全從來不是單點責任，而是一種脆弱的共識：維護者承諾「盡力而為」，用戶承諾「謹慎使用」，平臺承諾「基礎防護」。Trivy事件之所以嚴重，是因為這三層默契在同一時間點失效。

維護者的憑證輪換存在盲區，用戶的版本引用策略存在惰性，平臺的標簽可變性設計存在隱患——任何單獨一環的加固都可能阻斷攻擊，但現實中它們形成了共振。更值得警惕的是攻擊者對「信任修復窗口」的利用：他們似乎精準預判了官方公告與徹底清查之間的時間差，將其轉化為操作空間。

這種對「組織行為節奏」的利用，標志著供應鏈攻擊正在進入更精細化的階段。

未結束的對抗：攻擊者仍在嘗試重新入場

截至3月22日的調查更新，事件遠未落幕。Aqua Security與Sygnia在周末的聯合排查中發現了新的可疑活動，符合攻擊者試圖重建訪問路徑的行為模式。這意味著什么？對方可能還持有未被識別的憑證，或者已經在生態系統的其他位置埋下了新的據點。

目前的 remediation 進展包括：從GitHub Releases、Docker Hub、Amazon ECR等全部分發渠道下架惡意版本；完成全環境憑證撤銷；啟動長期令牌向短期憑證的遷移；以及最關鍵的一項——建立不可變發布驗證機制，確保未來任何版本標簽的變更都能被審計和告警。

但對于已經運行過被污染版本的用戶來說，補救窗口可能已經過去。惡意代碼的靜默執行特性意味著，憑證泄露可能發生在數周之前，而攻擊者的利用行動「正在更廣泛的生態系統中積極進行」——這是官方描述，翻譯過來就是：你的云賬單上可能出現異常資源，或者更糟，你的集群里已經有了看不見的訪客。

如果你在使用Trivy，現在該做的不是檢查當前版本是否「干凈」，而是假設過去三周內任何一次掃描都可能已被污染。輪換所有CI/CD環境中使用的憑證，審查云平臺的訪問日志，考慮將版本引用從標簽遷移到提交哈希——這些動作沒有一個是輕松的，但拖延的成本可能更高。

Aqua Security的最后一次更新以一句罕見的直白收尾：「調查仍在進行，我們將持續分享發現。」對于習慣了「已修復」式公告的讀者，這種不確定性的坦誠本身，或許才是值得注意的信號。