最近在看「AI 助手讀專案」這件事，愈看愈覺得：大家想像的是它像同事一樣理解你的 repo；現實更像它會把所有能讀到的東西都當成上下文。

而上下文一旦變多，就不只是生產力來源，也會變成攻擊面。

這則 Threads 提到的例子是 DockerDash：如果 AI 助手會讀 Docker image 的 LABEL、描述、或其他容器中繼資料（metadata），那麼攻擊者其實可以把惡意指令、誤導資訊、或「看起來很合理的規範」塞進 metadata 裡，讓模型在不知情的情況下被帶著走。

為什麼「容器中繼資料」會變成供應鏈風險

容器在 DevOps 流程裡常被視為可重現的交付單位，但它也攜帶了大量描述性資訊，例如：

• LABEL（維護者、版本、用途、文件連結）
• image 描述與註記
• build 時寫入的參數或提示文字

過去這些資訊多用於人類閱讀或自動化流程。

當 AI 助手開始「把它們當作可信上下文」時，攻擊者只要能讓你拉到一個看似正常的 image，就有機會把內容注入到你後續的決策與操作裡。

典型的風險型態（整理）

1. 提示注入（prompt injection）
   在 metadata 中放入要求模型忽略規則、改用替代流程、或執行特定操作的文字。

2. 錯誤但合理的指引
   放入看起來像官方文件的連結、或「推薦做法」，引導開發者採用不安全的設定。

3. 信任鏈錯置
   把「從 registry 下載到的 image」誤當成「可被信任的說明來源」，使模型與使用者把它的描述當作準規格。

對工程團隊的啟示：上下文要分級

如果團隊要把 AI 助手接到 CI、容器、repo、文件、issue 等多來源上下文，實務上可以把「上下文」做出等級與界線：

• 什麼來源可讀、什麼來源只可引用摘要
• 哪些欄位（例如 LABEL）一律視為不可信輸入
• 模型輸出若涉及安全設定，必須回到可驗證來源（文件、程式碼、policy）
• 重要操作要有人工確認與審計軌跡

小結

把 AI 助手當成「會讀專案的同事」沒問題，但前提是你要先回答：它讀到的東西，有哪些可能是別人故意塞給你的？

因為在這個模式裡，上下文越完整，攻擊面也越完整。

原文連結

供應鏈安全 #Docker #AI安全 #PromptInjection #DevSecOps