程式碼建議投毒

透過訓練資料投毒與推論期上下文操控來操控 AI 程式設計助理建議的攻擊概覽。

程式碼建議投毒是操控 AI 程式設計助理對開發者建議內容的一類攻擊。不同於引入惡意依賴的傳統供應鏈攻擊，建議投毒透過 AI 模型本身運作——要麼損毀它所訓練的資料，要麼操控它在推論時讀取的上下文。結果是 AI 建議功能上正確但包含安全漏洞的程式碼，而接受建議的開發者成為脆弱程式碼的不知情作者。

兩個投毒向量

訓練期投毒

訓練期投毒鎖定用於訓練或微調程式碼生成模型的資料。透過將脆弱程式碼模式引入受歡迎的儲存庫，攻擊者可影響模型學習的分布，使它優先建議不安全的程式碼模式。這是長期攻擊：被投毒資料必須在訓練期間存在，而影響跨模型所有使用者顯現。

有關詳細技術，請參閱 訓練資料攻擊。

推論期投毒

推論期投毒鎖定模型在產生特定建議時讀取的上下文。透過打造模型納入其上下文視窗的檔案、註解或文件，攻擊者可在不修改模型訓練資料的情況下將建議引導向不安全模式。這是較短期攻擊，可鎖定特定開發者或專案。

有關詳細技術，請參閱 上下文操控。

有效被投毒建議的特徵

並非所有不安全的程式碼建議都構成成功的投毒。有效的被投毒建議有數個特徵：

功能正確性。 建議的程式碼必須在所有正常測試案例中正確運作。引入漏洞的建議會被測試捕捉並拒絕。漏洞必須在標準測試未涵蓋的非功能性屬性（安全性、隱私、時序行為）中。

風格一致性。 建議必須符合周圍程式碼的風格與慣例。看起來格格不入的建議會在程式碼審查期間引發審視。

微妙性。 最有效的被投毒建議包含需要安全專業知識才能識別的漏洞。使用 == 而非 hmac.compare_digest() 進行 token 比較是大多數開發者不會識別的時序漏洞。

可信度。 不安全模式必須是開發者可能合理撰寫的模式。如果建議包含明顯後門（例如，傳送資料到硬編碼外部 URL），它會在審查期間被捕捉。如果它使用時序脆弱的比較或弱雜湊演算法，它看起來是正常的實作選擇。

與傳統供應鏈攻擊的比較

評估框架

評估組織對建議投毒的暴露：

1. 模型來源 — 哪些模型驅動使用中的程式設計助理？它們消費什麼訓練資料？
2. 上下文暴露 — 程式設計助理能讀取什麼檔案與資料以建構其上下文？
3. 接受率 — 不經修改就接受 AI 建議的比例是多少？
4. 審查流程 — AI 生成的建議是否受到安全焦點的程式碼審查？
5. 儲存庫衛生 — 儲存庫中是否有可作為上下文投毒向量的檔案（舊工具檔案、被遺棄的實驗、複製的範例）？

相關主題

• 訓練資料攻擊 — 投毒訓練資料的技術
• 上下文操控 — 操控推論上下文的技術
• GitHub Copilot 攻擊 — 工具特定投毒向量
• 訓練管線攻擊 — 更廣泛的訓練資料完整性顧慮