Trivy被「借尸還魂」：76個版本標(biāo)簽同時淪陷

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

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

攻擊者的「時間差」戰(zhàn)術(shù)：為什么修復(fù)通知反而成了掩護(hù)

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

但憑證輪換漏掉了一枚。

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

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

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

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

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

攻擊者明確瞄準(zhǔn)了依賴可變版本標(biāo)簽（mutable version tags）的用戶群體。在GitHub Actions的生態(tài)中，@v1、@v0.69.4這類標(biāo)簽?zāi)J(rèn)可以被維護(hù)者重新指向不同的提交。相比之下，固定提交哈希（pinned commit hash）雖然繁瑣，卻能免疫這種「借尸還魂」式的攻擊。

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

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

辯論：開源供應(yīng)鏈安全，到底該誰買單？

事件發(fā)酵后，社區(qū)分裂成兩個陣營。

正方觀點(diǎn)：維護(hù)者已盡力，用戶需自擔(dān)風(fēng)險

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

更深層的辯護(hù)來自開源經(jīng)濟(jì)的現(xiàn)實：Trivy作為免費(fèi)工具，其維護(hù)團(tuán)隊沒有義務(wù)為企業(yè)的生產(chǎn)環(huán)境安全背書。那些將核心基礎(chǔ)設(shè)施綁定在浮動版本標(biāo)簽上的團(tuán)隊，本質(zhì)上是在用「方便」交換「風(fēng)險」——這個等式在出事前從未被認(rèn)真計算過。

反方觀點(diǎn)：「已修復(fù)」的誤導(dǎo)性聲明放大了損害

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

更尖銳的質(zhì)疑指向GitHub Actions生態(tài)本身。為什么平臺默認(rèn)允許強(qiáng)制推送覆蓋版本標(biāo)簽？為什么缺乏對關(guān)鍵倉庫的異常操作預(yù)警？當(dāng)攻擊者可以批量篡改76個標(biāo)簽而不觸發(fā)熔斷機(jī)制，基礎(chǔ)設(shè)施層面的防護(hù)缺口同樣難辭其咎。

我的判斷：這是一次「系統(tǒng)性默契」的破裂

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

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

這種對「組織行為節(jié)奏」的利用，標(biāo)志著供應(yīng)鏈攻擊正在進(jìn)入更精細(xì)化的階段。

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

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

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

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

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

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