Trivy 3個(gè)版本被投毒：開源掃描器成了后門通道

0.69.4、0.69.5、0.69.6。三個(gè)連號(hào)版本，72小時(shí)內(nèi)連續(xù)發(fā)布，Docker Hub 上能拉取，GitHub Release 頁面卻查無此人。

這是 Aqua Security 旗下明星開源工具 Trivy 上周的真實(shí)遭遇。作為容器安全掃描領(lǐng)域的頂流項(xiàng)目，Trivy 在 GitHub 坐擁 22k+ Star，被無數(shù) CI/CD 流水線當(dāng)成基礎(chǔ)設(shè)施。但這次，攻擊者沒碰代碼倉庫，而是直接劫持了發(fā)布管道——你信任的掃描器，成了別人埋雷的通道。

投毒手法：GitHub Actions 的權(quán)限縫隙

攻擊者瞄準(zhǔn)的是 GitHub Actions 的 workflow 觸發(fā)機(jī)制。Trivy 的發(fā)布流程依賴自動(dòng)化流水線：代碼打標(biāo)簽 → 觸發(fā)構(gòu)建 → 推送 Docker Hub。問題出在標(biāo)簽權(quán)限的邊界模糊。

GitHub Actions 默認(rèn)允許特定條件下的標(biāo)簽觸發(fā)，而攻擊者找到了一種方式：通過偽造或劫持的提交，讓 workflow 誤以為這是合法發(fā)布。Trivy 維護(hù)團(tuán)隊(duì)在事后復(fù)盤里提到，攻擊者利用了「標(biāo)簽推送即可觸發(fā)發(fā)布」的自動(dòng)化邏輯，沒碰主分支代碼，卻能讓官方賬號(hào)"代發(fā)"惡意鏡像。

更諷刺的是，Trivy 本身就是用來掃漏洞的工具。用戶每天用它檢查鏡像有沒有 CVE，結(jié)果掃描器自己先被塞了信息竊取木馬（infostealer）。這就像你請(qǐng)了個(gè)保鏢，保鏢的制服里藏著監(jiān)聽器。

三個(gè)版本的時(shí)間線：快得像正常迭代

0.69.4 發(fā)布于 4 月 22 日，0.69.5 緊隨其后，0.69.6 又在 24 小時(shí)內(nèi)上線。這種節(jié)奏在開源社區(qū)不算異常——修個(gè)緊急 bug，連發(fā)幾個(gè)補(bǔ)丁，用戶早就習(xí)慣了自動(dòng)拉 latest 標(biāo)簽。

但這次，GitHub Release 頁面是空的。攻擊者只推了 Docker Hub，沒同步發(fā) Release Notes。這個(gè)細(xì)節(jié)成了事后排查的關(guān)鍵線索：正常維護(hù)者不會(huì)這樣操作，但自動(dòng)化流水線被劫持時(shí)，Release 頁面的缺失反而成了"正常"的漏洞。

Aqua Security 的響應(yīng)速度算快的。發(fā)現(xiàn)異常后，團(tuán)隊(duì)在兩小時(shí)內(nèi)下線了問題鏡像，并發(fā)布了 0.69.7 干凈版本。但問題在于，CI/CD 管道的緩存機(jī)制和鏡像層的復(fù)用，讓"下線"不等于"清除"。如果你的流水線在 22-24 日之間拉過 latest，惡意層可能已經(jīng)躺在本地倉庫里了。

IOC 清單：攻擊者留下了什么

被植入的 infostealer 主要針對(duì)云環(huán)境憑證。具體行為包括：遍歷 ~/.aws、~/.azure、~/.config/gcloud 等目錄，收集 access key 和 token；掃描環(huán)境變量中的敏感字符串；嘗試連接外部 C2 服務(wù)器。

這些手法并不新鮮，但載體選擇很刁鉆。Trivy 的運(yùn)行場景通常是 CI 環(huán)境——權(quán)限高、憑證多、且往往有跨云訪問能力。攻擊者相當(dāng)于在 DevOps 的心臟位置插了根管子。

目前公開的 IOC 包括特定路徑下的可疑二進(jìn)制文件，以及幾個(gè)硬編碼的 C2 域名。Aqua 建議用戶檢查 4 月 22-24 日之間的鏡像拉取日志，重點(diǎn)比對(duì)鏡像 digest 而非 tag。tag 可以被復(fù)用指向不同 digest，這是很多人忽略的細(xì)節(jié)。

這不是 Trivy 第一次被針對(duì)

2024 年 3 月，Trivy 就經(jīng)歷過類似的供應(yīng)鏈攻擊。那次是惡意 PR 試圖植入后門，被代碼審查攔下。這次升級(jí)了——不跟你玩代碼博弈，直接劫持發(fā)布管道。

兩次攻擊的共同點(diǎn)：都盯著"自動(dòng)化"的便利性與安全性的 trade-off。GitHub Actions 讓開源維護(hù)者從繁瑣的發(fā)布工作中解脫，但也把攻擊面從"代碼倉庫"擴(kuò)展到了"整個(gè) workflow 生態(tài)"。

維護(hù)者現(xiàn)在的修補(bǔ)方向包括：強(qiáng)制要求發(fā)布前的人工審批、增加多因素驗(yàn)證的簽名步驟、以及分離構(gòu)建與推送的權(quán)限。但這些都會(huì)拖慢發(fā)布節(jié)奏——安全與效率的拉鋸，從來不是靠技術(shù)能單方面解決的。

用戶側(cè)：你該檢查什么

如果你在用 Trivy，先別 panic。確認(rèn)幾件事：你的鏡像拉取策略是 digest 固定還是 tag 浮動(dòng)？CI 環(huán)境里有沒有 4 月 22-24 日的構(gòu)建記錄？本地/私有倉庫是否緩存了問題版本？

對(duì)于使用 latest 標(biāo)簽的團(tuán)隊(duì)，這是第 N 次教訓(xùn)了。latest 在 Docker 生態(tài)里是個(gè)動(dòng)態(tài)指針，今天指向 0.69.7，明天可能被攻擊者指回 0.69.6。固定 digest 麻煩，但麻煩是安全的一部分。

Aqua 提供了腳本用于批量檢測可疑鏡像層。更務(wù)實(shí)的做法是：把這次事件寫進(jìn)你的 incident response playbook，下次換工具時(shí)，先問發(fā)布流程有沒有雙人控制，而不是只看功能對(duì)比表。

0.69.7 的 Release Notes 里，維護(hù)者加了一行小字："We have rotated all release-related credentials." 憑證輪換完成，流水線重啟。但那個(gè)空的 0.69.4-6 Release 頁面，會(huì)一直留在倉庫里，像個(gè)沒填的坑。