Trivy Docker 映像遭供應鏈攻擊

Trivy 這次真的不是小事。Trivy 的 Docker image tag 0.69.5 和 0.69.6 也被污染。研究團隊 Socket 追到的結果很直接：0.69.6 在回報時，還指向惡意映像檔。

這代表問題不只是一個版本壞掉。它已經碰到 Docker Hub、GitHub Actions，還碰到很多團隊每天都在跑的 CI/CD 流程。講白了，掃描器自己如果被動手腳，開發者最信的那層保護就先破了。

更麻煩的是，這種工具常常有高權限。它能讀原始碼、讀環境變數、看 build log，甚至碰到雲端憑證。你以為它在幫你掃漏洞，結果它可能也在幫攻擊者收資料。

第一波事件後，問題還沒結束

這起事件最早從 2026 年 3 月 19 日開始。當時攻擊者先入侵 Trivy 0.69.4，並把竊取憑證的惡意程式塞進正式釋出和 GitHub Actions。

到了 3 月 22 日，研究人員又找到兩個新的惡意 Docker tag，分別是 0.69.5 和 0.69.6。更怪的是，這兩個 tag 沒有對應的 GitHub release。這種對不上流程的狀況，對做 CI 的人來說很刺眼。

正常 release 會有一條完整軌跡。原始碼 tag、build、artifact、映像檔，都應該能對起來。這次卻是 image tag 先冒出來，像是有人直接插隊發貨。對供應鏈攻擊來說，這就是很典型的破口。

• 0.69.3 是目前已知最後乾淨版本
• 0.69.4 是第一個被污染的版本
• 0.69.5 和 0.69.6 也被發現有問題
• 0.69.6 在回報時仍指向惡意映像檔
• 分析中看到 TeamPCP 相關的竊資特徵

我覺得這裡最值得警惕的，不是版本號本身，而是流程斷點。只要 release、registry、GitHub Actions 三邊有一邊沒對齊，攻擊者就有機會把假貨塞進去。

為什麼 CI/CD 是攻擊重點

很多團隊把掃描器當成「安全工具」，所以會直接放進 pipeline。問題就在這裡。工具一旦被污染，它就能在最敏感的時候接觸到最多資料。

Trivy 常被拿來掃 container、code、dependency。它跑在 CI/CD 時，通常會碰到 repo token、registry token、雲端金鑰，還有各種 build 參數。攻擊者只要拿到其中一部分，後面就很好玩了，對他們來說啦。

Aqua Security 的分析指出，這次行為和先前觀察到的攻擊模式一致。意思很明白：這不是隨機亂打，而是同一套手法從 GitHub Actions 轉到 Docker 發佈，再往內部資源延伸。

“Based on our current understanding, this activity is consistent with the attacker’s previously observed behavior,” Aqua Security said in its March 23 update.

這句話很重要。它不是在講單點事故，而是在講一條攻擊鏈。先拿到入口，再用自動化把影響擴散。對防守方來說，這種節奏通常比單次入侵更麻煩。

還有一個老問題。很多人只看 tag，不看 digest。像 trivy:latest 這種寫法最方便，也最危險。Docker tag 可以被重指向，tag 不是證明，digest 才比較像證明。

GitHub 暴露讓範圍更大

這次攻擊不只碰到 Docker image。研究人員也發現，和 Aqua Security 有關的內部 GitHub organization 曾短暫暴露。當時有數十個 repository 被改名，還被設成公開。

時間也很有意思。這些變動據稱只花了大約兩分鐘，而且看起來像腳本在跑，不像人手動一個一個點。這種 burst 式操作通常代表攻擊者早就拿到 token，而且權限不低。

這裡還牽到 TeamPCP。研究團隊把這個群組和竊資、worm 傳播、ransomware、挖礦，還有針對 Kubernetes 的破壞行為連在一起。老實說，這種角色切換很像現在常見的犯罪團隊打法，先偷，再賣，再擴散。

• 數十個 repository 曾被改名並公開
• 暴露時間約 2 分鐘
• 可能是 service account token 被濫用
• 影響範圍橫跨多個 GitHub organization

如果你的組織也有自動化帳號，這一段很值得對照。很多公司會把 token 發給 bot、release job、掃描 job。問題是，一個 token 壞掉，常常不是壞一個 repo，而是壞一串流程。

跟其他供應鏈事件比，差在哪

這類事件其實有固定套路。先拿下一個入口，再把惡意內容丟進 registry、build system、開發者工具。Trivy 這次的特別之處在於，它本身就是安全掃描工具。也就是說，攻擊者不是只想混進你的環境，而是想混進你判斷風險的那一層。

如果拿其他案例來比，2019 年 Docker Hub 外洩事件影響了約 19 萬名使用者。那次很大，但重點偏向帳號外洩。這次 Trivy 事件的重點不一樣，它碰到的是 CI/CD 裡最敏感的安全檢查。

所以比較方式也要換。不是只看有多少帳號受影響，而是看 attack surface 有沒有踩進 release gate。當掃描器本身不可信，後面所有 scan result 都要重新驗。

• Docker tag 可被改寫
• GitHub Actions 可被拿來塞惡意輸出
• 掃描器進 CI/CD 後，權限通常很高
• 用 digest pinning 比只看版本號更穩
• 自動化流程越多，供應鏈風險面越大

還有一點不能漏。Aqua Security 表示，自家商業產品沒有看到受影響，包含 Aqua Platform 內提供的 Trivy。這句話只能縮小已知範圍，不能幫你省掉檢查。如果你是直接拉開源 image，還是得自己查清楚。

這次事件也在提醒產業一件事

開源工具被打，不是新聞第一次出現。只是這次打到的是大家很常用的安全工具，所以感覺特別刺。很多團隊平常會很認真管應用程式，卻把掃描器、build helper、CI action 當成理所當然。

問題就在這裡。開發流程越自動化，攻擊者越愛找能重複利用的點。包管理器、CI helper、掃描器，都是高價值目標。因為它們一旦中招，影響的不是一台主機，而是一整串 pipeline。

這也解釋了為什麼現在越來越多團隊開始看 SBOM、digest、簽章驗證，還有 artifact provenance。不是因為文件漂亮，而是因為 tag 太容易被動手腳。你如果只看版本號，等於只看門牌，不看裡面住的是誰。

我會建議台灣團隊先做三件事。第一，檢查最近有沒有拉到 0.69.4、0.69.5、0.69.6。第二，把 Trivy image 改成 digest pinning。第三，回頭看 GitHub Actions 權限，尤其是 service account token。

再多做一步也不難。把掃描 job 的 outbound traffic、環境變數讀取、異常 repository 變更都記錄下來。這些東西平常看起來很煩，但出事時會救命。

接下來該怎麼看

這次 Trivy 事件給我的結論很直接：供應鏈攻擊會越來越愛打工具層。因為那裡權限高、被信任、又常常沒人細查。說白了，攻擊者不一定要打你的 app，先打你的 scanner 就夠痛了。

如果你的 CI/CD 還在用 mutable tag，我會說現在就該改。不是等下一次事故來了才補洞。你可以先從 digest pinning、token 盤點、GitHub Actions 權限收斂開始。這些都是實作成本不高，但能少掉很多麻煩的動作。

我自己的判斷是，接下來 12 個月，更多攻擊會盯上 package manager、scanner、CI helper 這類工具。下一次不一定會像這次一樣吵，但它可能更安靜，也更難抓。你現在要做的，不是等它來，而是先把流程改到不怕它來。