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

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

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

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

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

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

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

這次攻擊精準(zhǔn)打擊了開源生態(tài)的一個普遍陋習(xí)——依賴可變版本標(biāo)簽（如v0.69.4）而非固定提交哈希（commit hash）。Aqua Security確認(rèn)，其商業(yè)產(chǎn)品因架構(gòu)隔離未受影響：專用管道、嚴(yán)格訪問控制、滯后于開源發(fā)布的受控集成流程，構(gòu)成了三道防線。

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

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

正方觀點(diǎn)：Aqua Security的披露和響應(yīng)足夠及時

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

更關(guān)鍵的是，商業(yè)產(chǎn)品與開源項(xiàng)目的架構(gòu)隔離被證明有效——這種"雞蛋不放一個籃子"的設(shè)計(jì)，恰恰是負(fù)責(zé)任的安全實(shí)踐。團(tuán)隊(duì)正在推進(jìn)的不可變發(fā)布驗(yàn)證（immutable release verification）和長期令牌淘汰，屬于結(jié)構(gòu)性改進(jìn)而非臨時補(bǔ)丁。

反方觀點(diǎn)："Incomplete remediation"暴露了流程缺陷

批評者抓住3月1日的修復(fù)失敗不放。18天的窗口期讓攻擊者從容升級戰(zhàn)術(shù)，從"潛伏"轉(zhuǎn)向"大規(guī)模污染"。如果初次響應(yīng)執(zhí)行了更徹底的憑證審計(jì)，76個標(biāo)簽的篡改本可避免。

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

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

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

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

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

截至3月25日，調(diào)查仍在進(jìn)行中。攻擊者仍在嘗試重新進(jìn)入系統(tǒng)，而數(shù)百萬開發(fā)者的CI/CD管道日志里，可能還躺著未被發(fā)現(xiàn)的異常。