譯者 | 晶顏

審校 | 重樓

網(wǎng)絡(luò)釣魚已經(jīng)演變?yōu)楣?yīng)鏈安全的主要威脅，其攻擊目標直指軟件開發(fā)人員，通過滲透開發(fā)工具與工作流程實施攻擊。

如今，網(wǎng)絡(luò)釣魚不再是局限于收件箱層面的威脅，而是已發(fā)展為全面影響軟件開發(fā)供應(yīng)鏈的風(fēng)險。《2025年威瑞森數(shù)據(jù)泄露調(diào)查報告》顯示，約60%的數(shù)據(jù)泄露事件與“人為因素”相關(guān)，其中網(wǎng)絡(luò)釣魚和憑證濫用占據(jù)主導(dǎo)地位。而據(jù)SlashNext于2024年中期發(fā)布的報告指出，自ChatGPT問世以來，網(wǎng)絡(luò)釣魚總量激增4151%。

從惡意攻擊者的視角來看，軟件開發(fā)人員是極具吸引力的目標群體。因為開發(fā)人員接觸機密信息、CI/CD密鑰以及生產(chǎn)基礎(chǔ)設(shè)施，一旦一名工程師的賬戶被攻破，可能會讓其他所有外圍控制措施形同虛設(shè)。

鑒于此，攻擊者學(xué)會了在開發(fā)工具中直接設(shè)置誘餌，如拉取請求、構(gòu)建警報、聊天機器人、IDE插件等，這些誘餌融入常規(guī)工作場景中，極易掩蓋其危險性。以下六種攻擊路徑均在近期的安全建議或漏洞報告中有所記載，同時也提供了應(yīng)對這些問題的實用技巧。

偽造拉取請求，植入后門

攻擊現(xiàn)象：在章魚掃描器活動中，攻擊者通過在GitHub上插入與每個代碼庫的命名風(fēng)格和測試覆蓋率相匹配的拉取請求（PR），秘密地對26個公共項目植入后門，隨后通過構(gòu)建工件發(fā)布惡意軟件。攻擊者將這一手段與大型語言模型（LLMs）相結(jié)合，這些模型攝取公共提交歷史，推斷文件名約定，并能在幾分鐘內(nèi)生成“看似合理”的代碼更改。忙碌的維護者往往被淹沒在審查隊列中，可能會自動合并這些請求，尤其是當持續(xù)集成檢查通過時。

應(yīng)對策略：對每個外部拉取請求實施雙重人工審查和自動靜態(tài)分析（例如CodeQL、Semgrep）。要求新貢獻者的提交進行加密簽名（可使用Git的--sign或Sigstore的gitsign）。警惕異常的依賴項添加，即使是單行的eval（）、exec（）或不尋常的導(dǎo)入，都應(yīng)觸發(fā)審查標記。

借助GitHub問題與OAuth應(yīng)用的超個性化電子郵件

攻擊現(xiàn)象：2025年3月中旬，威脅行為者在近12000個公共存儲庫中創(chuàng)建虛假的“異常訪問”問題，觸發(fā)來自notifications@github.com的通知電子郵件，促使維護者授權(quán)一個名為gitsecurityapp的惡意OAuth應(yīng)用程序。誘餌中引用了每個代碼庫的確切代碼和最后提交時間，這些細節(jié)由一個名為GoIssue的自動化工具包收集，該工具包被認為是針對開發(fā)人員的更廣泛人工智能網(wǎng)絡(luò)釣魚攻擊的一部分。由于這些消息通過了SPF/DKIM驗證，看起來像官方的GitHub安全警報，且要求的權(quán)限范圍符合常規(guī)工作流程，許多工程師下意識地點擊“授權(quán)”，從而一次性將自己的代碼庫、密鑰和CI訪問權(quán)限和盤托出。

應(yīng)對策略：加強對OAuth的管控，在GitHub Enterprise中啟用“限制第三方應(yīng)用程序訪問”，任何請求代碼庫或工作流權(quán)限范圍的應(yīng)用程序都需獲得管理員批準。對外部郵件進行標記，在所有非公司域名發(fā)送的消息前添加[EXT]標識，即便消息來自GitHub，以此強制接收者進行快速的合法性檢查。開展模擬威脅演練，運行網(wǎng)絡(luò)釣魚模擬，創(chuàng)建測試問題以觸發(fā)真實電子郵件，統(tǒng)計工程師中點擊虛擬OAuth應(yīng)用程序“授權(quán)”按鈕的比例。在GitHub和GitLab上強制執(zhí)行OAuth權(quán)限最小化原則，確保即便個人訪問令牌被盜，攻擊者也無法獲取敏感的組織機密。

偽造CI/CD失敗通知

攻擊現(xiàn)象：Jenkins項目在2025年1月和5月接連發(fā)布了安全建議，著重指出插件漏洞可能導(dǎo)致憑據(jù)枚舉和惡意作業(yè)執(zhí)行。攻擊者可以利用這些漏洞發(fā)送“構(gòu)建失敗 - 重新認證”的電子郵件或Slack警報，將開發(fā)人員重定向至網(wǎng)絡(luò)釣魚門戶網(wǎng)站。Cofense在2025年4月發(fā)布的《精確度驗證網(wǎng)絡(luò)釣魚》報告還顯示，攻擊者會進行實時賬戶檢查，只有有效的開發(fā)用戶才能成功登錄，以此繞過沙箱檢測。

應(yīng)對策略：對每個webhook有效負載使用共享密鑰或Jose令牌進行簽名，并在聊天集成中驗證簽名后再展示鏈接。僅在單點登錄（SSO）保護的CI儀表板中顯示構(gòu)建狀態(tài)鏈接，絕不在電子郵件中嵌入原始URL。設(shè)置“熱修復(fù)模式”防護措施，在變更凍結(jié)期間不提示輸入憑據(jù)，除非使用緊急令牌并經(jīng)過側(cè)通道批準。

惡意“關(guān)鍵”依賴更新

攻擊現(xiàn)象：XZ Utils后門事件（CVE-2024-3094）中，一名威脅行為者偽裝成熱心貢獻者，贏得維護人員信任后，推送了一個惡意的“性能補丁”，該后門險些進入glibc。攻擊者利用社會工程學(xué)壓力、干凈的提交歷史和看似真實的發(fā)布說明實施攻擊，而這些手段如今可借助人工智能大規(guī)模復(fù)制。

應(yīng)對策略：部署自動化依賴掃描工具（如OWASP Dependency-Check、Renovate），阻止未經(jīng)過Sigstore/SLSA來源驗證的依賴升級。要求維護者使用存儲在透明日志中的公鑰對壓縮包和標簽進行簽名，并在持續(xù)集成（CI）環(huán)節(jié)合并前進行驗證。對通過非官方渠道（如Twitter私信或Discord帖子）發(fā)送的“關(guān)鍵補丁”信息保持警惕，在項目官方渠道確認前不予輕信。

Slack或Discord機器人仿冒攻擊

攻擊現(xiàn)象：Slack曾針對其新推出的Slack人工智能助手修復(fù)了一個即時注入漏洞，該漏洞可被內(nèi)部人員利用植入網(wǎng)絡(luò)釣魚鏈接，且大型語言模型（LLMs）能在無需直接訪問權(quán)限的情況下將這些鏈接轉(zhuǎn)發(fā)至私人渠道。2024年迪士尼的數(shù)據(jù)泄露事件便是典型案例，此次事件導(dǎo)致1.1太字節(jié)的知識產(chǎn)權(quán)（IP）泄露，迫使該公司停用Slack，其背后正是攻擊者利用受損令牌及類機器人橫向移動技術(shù)實施的攻擊。當前，攻擊者已具備克隆“部署通知”機器人的能力——不僅使用相同的頭像，還采用一致的Markdown格式——并趁事件響應(yīng)人員專注于處理問題時，將有毒URL植入#dev-alerts等開發(fā)告警頻道。

應(yīng)對策略：嚴格執(zhí)行機器人權(quán)限最小化原則，采用類似AWS的IAM策略對令牌進行定期輪換與權(quán)限限制。對于來自未經(jīng)驗證域名的預(yù)覽鏈接，強制剝離其預(yù)覽功能，要求用戶手動點擊前必須通過懸停操作檢查鏈接真實性。確保機器人身份與管理人員通過相同的身份提供商（IdP）進行認證，從而啟用多因素認證（MFA）、設(shè)備狀態(tài)檢測及異常行為監(jiān)測機制。

惡意鏈接或人工智能助手插件攻擊

攻擊現(xiàn)象：研究人員發(fā)現(xiàn)兩款存在竊取環(huán)境變量風(fēng)險的模糊間諜軟件后，微軟下架了這兩款安裝量約達900萬次的VSCode擴展。自2024年底起，紅隊演練已多次展示，大型語言模型可生成虛假的市場列表，其中包含偽造的GitHub星級、npm下載量徽章及模板化的五星評論——這些虛假的社會證明信息，不斷誘使開發(fā)人員安裝帶有后門的“代碼助手”工具。

應(yīng)對策略：將擴展程序固定到經(jīng)過驗證的發(fā)布者，并在私有注冊表中進行鏡像備份；對于允許列表中校驗和缺失的擴展，堅決阻止安裝。在持續(xù)集成（CI）流程中，使用Trivy或Chainguard的wolfictl工具對VSIX包進行掃描；若二進制文件或網(wǎng)絡(luò)調(diào)用與基準差異超出正常范圍，則終止構(gòu)建流程。將來自Copilot等工具的人工智能生成代碼視為第三方貢獻，要求對每一處差異進行人工審查，禁止自動合并至主分支。

結(jié)語

攻擊者已經(jīng)將開發(fā)人員的工作場景轉(zhuǎn)化為新的攻擊面。他們通過將大型語言模型自動化技術(shù)與社會工程學(xué)手段相結(jié)合，能夠在代碼與各類會話交互的任意環(huán)節(jié)植入惡意工件。

相應(yīng)的防御策略也十分明確：將加密信任信號（如簽名、證明）與行為異常檢測機制直接嵌入開發(fā)人員的工作流程，確保所有檢查都在代碼離開分支或機器人向#alerts等頻道發(fā)布信息前完成。如今在其流程中部署這些控制措施的團隊，未來才能在持續(xù)交付的同時，避免將軟件開發(fā)供應(yīng)鏈變成攻擊者的“游樂場”。

原文標題：6 Ways AI-Enhanced Phishing Can Hijack Developer Workflows (and What to Do About It)，作者：Philip Piletic