Trivy掃描器遭供應鏈攻擊：76個版本標簽被篡改

GitHub Actions的一個配置失誤，讓全球最流行的開源漏洞掃描器變成了攻擊者的后門。攻擊者沒有新建惡意版本，而是直接修改了76個已有版本標簽——這意味著那些沒鎖定代碼哈希的企業，已經在不知情的情況下運行了數周惡意代碼。

攻擊時間線：一次" Incomplete "的修復如何釀成大禍

事件始于2025年2月底。攻擊者利用Trivy的GitHub Actions環境配置錯誤，竊取了一個高權限訪問令牌。3月1日，Aqua Security團隊披露事件并執行了憑證輪換，但關鍵漏洞被遺漏——部分憑證仍然有效，攻擊者并未被真正驅逐。

18天的靜默期后，3月19日，攻擊者發起第二階段行動。他們向aquasecurity/trivy-action倉庫的76個版本標簽強制推送惡意提交，同時污染了aquasecurity/setup-trivy的全部7個標簽。更隱蔽的是，一個被入侵的服務賬戶觸發了自動化發布流程，將植入后門的Trivy二進制文件標記為0.69.4版本正式發布。

攻擊者的核心策略是"寄生"而非"新建"——篡改現有標簽比發布可疑的新版本更難被發現。惡意代碼被設計成在合法Trivy掃描邏輯之前執行，CI/CD工作流看似正常運行，實則已在后臺完成數據竊取。

竊密范圍：CI/CD管道成了"憑證收割機"

惡意載荷在靜默執行期間，系統性地收集CI/CD環境中的敏感信息。目標清單包括：API令牌、AWS/GCP/Azure三大云平臺的憑證、SSH密鑰、Kubernetes令牌以及Docker配置文件。竊取的數據被實時外傳到攻擊者控制的基礎設施。

這次攻擊精準打擊了開源生態的一個普遍陋習——依賴可變版本標簽（如v0.69.4）而非固定提交哈希（commit hash）。Aqua Security確認，其商業產品因架構隔離未受影響：專用管道、嚴格訪問控制、滯后于開源發布的受控集成流程，構成了三道防線。

3月21日至22日的周末，調查發現了更多可疑活動。攻擊者仍在嘗試重新建立訪問，表明這是一場持續進行的戰役，而非一次性入侵。Aqua Security已與全球事件響應公司Sygnia合作，從初步遏制轉向主動修復。

辯論：開源安全工具的信任危機，誰該背鍋？

正方觀點：Aqua Security的披露和響應足夠及時

支持者認為，在復雜的供應鏈攻擊中，3月1日的初步響應符合行業標準。憑證輪換是標準操作，殘留訪問的發現往往需要時間驗證。Aqua Security在確認二次入侵后48小時內就完成了惡意版本的全面下架，覆蓋GitHub Releases、Docker Hub和Amazon ECR三大分發渠道。

更關鍵的是，商業產品與開源項目的架構隔離被證明有效——這種"雞蛋不放一個籃子"的設計，恰恰是負責任的安全實踐。團隊正在推進的不可變發布驗證（immutable release verification）和長期令牌淘汰，屬于結構性改進而非臨時補丁。

反方觀點："Incomplete remediation"暴露了流程缺陷

批評者抓住3月1日的修復失敗不放。18天的窗口期讓攻擊者從容升級戰術，從"潛伏"轉向"大規模污染"。如果初次響應執行了更徹底的憑證審計，76個標簽的篡改本可避免。

更深層的質疑指向開源項目的安全投入。Trivy作為被數百萬CI/CD管道依賴的基礎設施，其GitHub Actions環境的配置審核顯然不足。攻擊者利用的是基礎性的配置錯誤，而非什么高級零日漏洞——這種"低級錯誤"在關鍵安全工具中出現，本身就值得反思。

我的判斷：這是一次"典型"的供應鏈攻擊，典型到令人不安

雙方都有理，但也都回避了真正棘手的問題。正方夸大了架構隔離的普適性——大多數使用Trivy的企業沒有商業版作為備份；反方則低估了供應鏈攻擊的固有難度，殘留訪問的排查在大型代碼庫中從來不是 trivial 的事（瑣碎的事）。

真正值得關注的，是攻擊者選擇的戰術模式。他們不搞花哨的零日漏洞，而是精準利用開源生態的"默認不安全"：可變標簽的便利性、CI/CD環境的憑證密集性、安全工具本身的信任溢價。這種"低成本、高杠桿"的攻擊思路，正在被更多威脅行為者復制。

Aqua Security的修復清單包括全面憑證吊銷、淘汰長期令牌、實施不可變發布驗證。但這些措施解決的是"這次怎么被打的"，而非"下次怎么防別的"。當安全工具本身成為攻擊面，整個行業需要重新思考開源基礎設施的信任模型——不是要不要用，而是如何在不信任的前提下安全地使用。

截至3月25日，調查仍在進行中。攻擊者仍在嘗試重新進入系統，而數百萬開發者的CI/CD管道日志里，可能還躺著未被發現的異常。