GitHub被灌了500條"CI更新"：10%開發(fā)者點(diǎn)了合并

3月11日到4月2日，22天，6個賬號，500多個偽裝成"ci: update build configuration"的拉取請求。這不是正常的開源協(xié)作，是一場針對GitHub Actions的自動化收割。

Wiz Research的追蹤顯示，攻擊者用AI驅(qū)動的工具鏈，把倉庫分叉、分析技術(shù)棧、注入對應(yīng)語言的惡意載荷——Go項目塞測試文件，Python項目塞conftest.py，Node.js項目改package.json腳本。整個過程不需要人工寫代碼，機(jī)器自己完成適配。

這套流程的精妙之處不在技術(shù)深度，而在偽裝精度。開發(fā)者每天處理大量依賴更新，"更新構(gòu)建配置"屬于最不會引起警覺的提交類型。攻擊者賭的就是這個慣性。

pull_request_target：一個被濫用的"便利"設(shè)計

GitHub Actions有兩種處理外部PR的觸發(fā)器。標(biāo)準(zhǔn)的pull_request在分叉?zhèn)}庫的隔離環(huán)境中運(yùn)行，拿不到目標(biāo)倉庫的密鑰。pull_request_target則相反——它直接在基礎(chǔ)倉庫的上下文中執(zhí)行，目的是讓維護(hù)者能安全地處理需要訪問 secrets 的自動化任務(wù)。

這個設(shè)計本意是方便，卻成了攻擊通道。當(dāng)開發(fā)者合并一個看似無害的CI配置更新時，惡意代碼就在目標(biāo)倉庫的完整權(quán)限下運(yùn)行，AWS密鑰、Cloudflare API令牌、Netlify認(rèn)證信息直接外泄。

安全研究員Charlie Eriksen在4月2日公開示警時，攻擊賬號ezmtebo已經(jīng)在26小時內(nèi)扔了475個PR。但Wiz Research的回溯分析發(fā)現(xiàn)，第一波攻擊早在3月11日就開始，由賬號testedbefore發(fā)起，中間換了六次身份。

被確認(rèn)攻陷的兩個npm包——@codfish/eslint-config和@codfish/actions——橫跨106個版本。Sentry、OpenSearch、NixOS這些高知名度項目因為嚴(yán)格執(zhí)行了貢獻(xiàn)者審批控制，擋住了攻擊。

規(guī)模與精準(zhǔn)度的悖論：攻擊者用AI實(shí)現(xiàn)了"大規(guī)模個性化"，但成功率始終卡在10%以下。450多次分析過的利用嘗試中，大多數(shù)得手的是小型業(yè)余項目，泄露的也只是臨時的GitHub工作流令牌。可500多次的基數(shù)擺在那里，10%就是幾十起真實(shí)入侵，而且攻擊者在每一波后都在迭代載荷、改進(jìn)規(guī)避。

AI降低了門檻，也改變了攻擊經(jīng)濟(jì)學(xué)

傳統(tǒng)的供應(yīng)鏈攻擊需要研究者深入理解目標(biāo)項目的構(gòu)建系統(tǒng)、找到特定的注入點(diǎn)、手工構(gòu)造利用代碼。prt-scan campaign展示的新模式是：AI接手了技術(shù)適配環(huán)節(jié)，攻擊者只需要定義目標(biāo)列表和滲出通道。

Wiz Research的Rami McCarthy、Hila Ramati、Scott Piper和Benjamin Read在分析報告中指出，這種"低技能門檻+機(jī)器速度"的組合，讓單一個體就能維持持續(xù)數(shù)周的多波次 campaign。六個賬號輪換不是為了隱蔽——GitHub的檢測機(jī)制會標(biāo)記異常行為——而是純粹的運(yùn)營冗余，確保一條線被切斷時其他線繼續(xù)運(yùn)轉(zhuǎn)。

攻擊工具鏈的具體行為也被還原：分叉目標(biāo)倉庫后，自動識別主語言，選擇對應(yīng)的文件類型注入載荷。Go項目找_test.go文件，Python項目找conftest.py，Node.js項目改package.json里的scripts字段。這種適配不是基于靜態(tài)規(guī)則，而是對倉庫結(jié)構(gòu)的動態(tài)分析。

10%成功率背后的篩選邏輯值得玩味。攻擊者沒有追求更高的轉(zhuǎn)化，而是保持廣撒網(wǎng)策略。小型項目維護(hù)者通常缺乏安全審查資源，對"CI更新"類PR的合并決策更快；大型項目雖然有更嚴(yán)格的流程，但攻擊者并未針對性優(yōu)化——或者說，AI工具鏈的當(dāng)前版本還不足以突破多層審批。

這種"放棄攻堅、專注收割"的策略，本質(zhì)上是對開源生態(tài)分層結(jié)構(gòu)的理性利用。

防御方的斷層：為什么10%依然太高

GitHub官方對pull_request_target的風(fēng)險早有文檔說明，建議配合條件判斷限制執(zhí)行環(huán)境。但文檔意識和實(shí)際配置之間存在巨大落差。Wiz Research分析的450多個利用嘗試中，相當(dāng)一部分目標(biāo)倉庫直接使用了默認(rèn)配置，未對觸發(fā)條件做額外約束。

Sentry、OpenSearch、NixOS的幸存不是偶然。它們的共同點(diǎn)是建立了強(qiáng)制性的貢獻(xiàn)者審批流程：外部PR不會自動觸發(fā)任何工作流，需要維護(hù)者人工審查后才會進(jìn)入執(zhí)行階段。這個設(shè)計把攻擊窗口從"合并瞬間"前移到"PR提交時"，惡意代碼甚至沒有機(jī)會運(yùn)行。

但對于占開源生態(tài)絕大多數(shù)的小型項目，這種流程是奢侈品。單個維護(hù)者、業(yè)余時間的副業(yè)、零安全預(yù)算——這些項目的安全模型建立在"沒人會專門攻擊我"的假設(shè)上。prt-scan campaign的10%成功率，恰恰擊中了這層假設(shè)的脆弱性。

攻擊者在被公開曝光后并未停止。4月2日Charlie Eriksen的示警引發(fā)了社區(qū)討論，但Wiz Research的監(jiān)測顯示，后續(xù)仍有新賬號加入輪換，載荷結(jié)構(gòu)出現(xiàn)微調(diào)。這種"曝光即迭代"的響應(yīng)速度，也是AI驅(qū)動運(yùn)營的特征之一——人工調(diào)整策略的周期被壓縮到小時級別。

供應(yīng)鏈攻擊的"民主化"拐點(diǎn)

prt-scan campaign的規(guī)模在供應(yīng)鏈攻擊史上不算最大，但其方法論標(biāo)志著一個轉(zhuǎn)折點(diǎn)。此前的類似攻擊——如2022年的node-ipc事件、2023年的XZ Utils后門——都依賴特定個體的深度技術(shù)能力和社會工程技巧。這次不同：攻擊者的技術(shù)棧是模塊化的、可復(fù)制的，核心能力從"寫利用代碼"轉(zhuǎn)移到了"運(yùn)營AI工具鏈"。

npm包@codfish/eslint-config和@codfish/actions的淪陷具有示范效應(yīng)。ESLint配置和GitHub Actions封裝是開發(fā)者高頻依賴的基礎(chǔ)設(shè)施類包，它們的用戶群體龐大且分散，單個包的污染可以向下游傳導(dǎo)。106個被污染版本的跨度，說明攻擊者在持續(xù)發(fā)布新版本時保持了注入能力，或者滲透了發(fā)布流程本身。

Wiz Research沒有披露具體的外泄數(shù)據(jù)規(guī)模，但確認(rèn)了AWS密鑰、Cloudflare API令牌、Netlify認(rèn)證令牌的泄露。這三類憑證的共同點(diǎn)是高價值、易利用——直接對應(yīng)可部署的云資源。攻擊者的滲出通道設(shè)計顯然經(jīng)過選擇，不是漫無目的地抓取所有環(huán)境變量。

開源生態(tài)的安全債務(wù)正在以新的利率計息。pull_request_target的設(shè)計初衷是降低維護(hù)者的自動化門檻，這個初衷沒有變，但威脅模型已經(jīng)完全不同。當(dāng)攻擊者可以用AI在幾小時內(nèi)生成針對數(shù)百個倉庫的定制化載荷時，"信任但驗證"的古老原則需要被重新工程化。

GitHub在2024年已經(jīng)推出過針對Actions的安全增強(qiáng)，包括工作流權(quán)限的默認(rèn)只讀設(shè)置、對fork PR的更嚴(yán)格隔離。但prt-scan campaign表明，這些措施對主動利用pull_request_target設(shè)計特性的攻擊效果有限。問題不在于GitHub沒有提供安全選項，而在于這些選項的默認(rèn)狀態(tài)和啟用成本與大多數(shù)項目的實(shí)際能力不匹配。

攻擊者的第六波活動細(xì)節(jié)尚未完全公開，但Wiz Research的追蹤顯示其載荷結(jié)構(gòu)出現(xiàn)了對特定語言運(yùn)行時版本的檢測邏輯。這種精細(xì)化調(diào)整的方向很明確：提高在目標(biāo)環(huán)境中的執(zhí)行成功率，減少因環(huán)境不匹配導(dǎo)致的暴露。

當(dāng)你的下一個"ci: update build configuration" PR彈出時，你會先點(diǎn)開文件diff，還是直接點(diǎn)合并？