2026年3月19日，全球下載量超3億次的開源漏洞掃描器Trivy（特里維）遭遇了一場教科書級別的供應鏈攻擊。攻擊者沒有發(fā)布可疑的新版本，而是直接篡改了76個歷史版本標簽——這意味著無數(shù)企業(yè)正在運行的"安全掃描"流程，實際上成了密鑰收割機。

攻擊時間線：從2月泄露到3月爆發(fā)

這場攻擊的起點要追溯到2026年2月底。攻擊者利用Trivy的GitHub Actions環(huán)境配置錯誤，提取了一個高權限訪問令牌。GitHub Actions是開發(fā)者常用的自動化工作流平臺，這個令牌相當于拿到了倉庫的"萬能鑰匙"。

3月1日，Aqua Security（Trivy的母公司）發(fā)現(xiàn)了異常并公開披露，同時執(zhí)行了憑證輪換。但關鍵失誤在于：輪換不徹底，部分憑證仍然有效。這就像換了大門鑰匙，卻忘了換后門鑰匙。

18天的靜默期后，攻擊者在3月19日發(fā)起總攻。他們向aquasecurity/trivy-action倉庫的76個版本標簽強制推送惡意提交，同時污染了aquasecurity/setup-trivy的全部7個標簽。更隱蔽的是，一個被入侵的服務賬戶觸發(fā)了自動發(fā)布流程，將后門程序打包成0.69.4版本正式發(fā)布。

攻擊者的高明之處：不造新版本，只改舊標簽。大多數(shù)企業(yè)為了穩(wěn)定性，會鎖定類似@v0.20.0這樣的版本標簽而非具體提交哈希。攻擊者正是利用這一點，讓惡意代碼神不知鬼不覺地進入正在運行的CI/CD流水線。

惡意載荷的設計堪稱精密。它在合法Trivy掃描邏輯執(zhí)行前先行啟動，因此整個工作流看起來正常完成，日志里沒有任何報錯。但在后臺，它正在瘋狂收集：AWS/GCP/Azure的云憑證、API令牌、SSH密鑰、Kubernetes令牌、Docker配置文件——幾乎所有能拿到的敏感信息，都被傳送到攻擊者控制的服務器。

誰中招了？開源用戶的"便利陷阱"

Aqua Security明確確認：商業(yè)付費產品完全未受影響。其企業(yè)版與開源版在架構上物理隔離，擁有獨立流水線、嚴格訪問控制，且版本發(fā)布滯后于開源版。這形成了一種諷刺的"安全分層"——免費用戶反而暴露在更高風險中。

真正被精準打擊的是一類使用習慣：依賴可變版本標簽（如@latest或@v0.20）而非固定提交哈希（如@abc123def）。前者方便自動更新，后者安全但需要手動維護。攻擊者顯然研究過目標用戶的行為模式。

3月21日至22日的周末，調查出現(xiàn)了更令人不安的發(fā)現(xiàn)：攻擊者正在嘗試重新建立訪問通道。這表明這不是一次性的入侵，而是一場持續(xù)戰(zhàn)役。Aqua Security已聯(lián)合全球應急響應公司Sygnia（西格尼亞）展開全面反擊。

目前的補救措施包括：從GitHub Releases、Docker Hub、Amazon ECR等所有分發(fā)渠道下架惡意版本；全環(huán)境憑證吊銷；廢除長期有效令牌，轉向短期憑證；以及正在部署的不可變發(fā)布驗證機制。

供應鏈攻擊的"新常態(tài)"

Trivy事件并非孤例。2024年的XZ Utils后門、2023年的3CX供應鏈攻擊，都在證明同一個趨勢：攻擊者正在向上游遷移。與其攻破一萬個終端，不如污染一個被廣泛依賴的工具。

CI/CD流水線是現(xiàn)代軟件生產的"高速公路"，而Trivy這類安全掃描器是每條高速必設的"安檢站"。當安檢站本身被植入后門，通過的車輛越多，泄露的貨物越貴重。

Aqua Security建議所有用戶立即檢查：是否使用了2026年3月19日至22日期間下載的Trivy版本？工作流配置中是否使用了版本標簽而非提交哈希？環(huán)境變量和密鑰是否在近期出現(xiàn)異常訪問記錄？

但一個更深層的問題懸而未決：當安全工具本身成為攻擊向量，企業(yè)該如何重新設計信任邊界？