AI代理安全需要組合圖，而非僅SBOM

近年來，隨著AI代理的廣泛應用，其安全性問題日益凸顯。傳統軟體組合分析（SCA）僅關注包級別依賴中的已知漏洞，但AI代理的真正風險往往來自元件之間的組合方式。以Claude官方外掛市場為例，文章深入探討了為何我們需要從包依賴轉向組合圖分析。

外掛“imessage”是Claude Code中一個可一鍵安裝的外掛，允許AI代理讀取和傳送iMessages。其底層架構包含三個主要部分：一個本地MCP伺服器，用於讀取使用者完整的訊息歷史（需要完全磁碟訪問許可權），並透過AppleScript代表使用者傳送訊息；一對技能“configure”和“access”，持有讀寫及受限的Bash許可權，並將訪問控制狀態寫入配置檔案；以及91個npm包作為支撐。每個元件單獨來看都是安全的：MCP伺服器按設計工作，技能行為正常，包也僅是常見的Web伺服器依賴。如果對倉庫執行SCA掃描，只會得到一份乾淨的鎖檔案報告，指示少數幾個包如hono和path-to-regexp存在中危漏洞。修補這些包後報告變為綠色，但使用者對實際風險幾乎一無所知。

因為風險從未存在於任何單個包中，而是存在於組合之中：一個連線了不受信任輸入的代理（每個入站文本都會落入它讀取的訊息儲存中），能夠讀取私人訊息歷史、代表使用者傳送訊息，並且由可以重寫誰被允許控制它的技能所管理。所有這些都在同一個上下文中，由各部分單獨審查後組裝而成。這並非假設。研究者實際掃描了官方Claude外掛市場——62個清單、530個元件：38個外掛、27個技能、26個命令、21個代理、16個MCP伺服器、8個鉤子，以及其下的394個包。掃描結果發現了124個已知漏洞通告。有趣的是，所有這些通告都恰好來自四個外掛：discord、telegram、fakechat和imessage，即四個訊息通道外掛。這些漏洞集中在處理不受信任外部訊息並能傳送本地檔案的外掛中。易受攻擊的程式碼和敏感能力位於同一元件，這正是逐包掃描無法表達的相關性，因為它從未知道這些包屬於一個讀取訊息的代理。

SCA只能回答依賴樹是否包含已知漏洞版本，但無法告知包在代理中的實際上下文。執行時監控雖然能捕獲執行中的不良行為，但不能在安裝前揭示組合風險。因此，我們需要第三個視角：代理組合圖。代理堆疊並非扁平的依賴列表，而是一個圖。外掛包含技能、MCP伺服器和鉤子，這些元件宣告能力並引入包。許可權和安裝路徑也參與其中。安全分析需要關注節點間的邊，而不僅僅是節點本身。一個扁平的SBOM列出了所有盒子，但無法告訴你紅色盒子與不受信任輸入源、私人資料讀取器和出站接收器位於同一上下文中。圖則可以做到這一點。

開源專案OpenACA正致力於構建這一層。目前，OpenACA可以盤點整個代理堆疊，將每個包通告歸因於引入它的代理元件（這正是我們得知所有124個通告存在於四個外掛中的方法），標記可變動安裝和執行技能能力等姿態問題，並以CycloneDX格式輸出代理BOM——可匯出的組合圖。下一步是圖匯出的暴露分析，即僅因組合而觸發的規則，例如“此上下文結合了不受信任輸入、私人資料讀取和出站接收器；需審查”，並基於是否存在可行的影響路徑對發現進行優先順序排序。OpenACA目前尚未計算這些暴露路徑，但盤點、歸因和圖是使其成為可能的基礎。

作者提供了一個簡單的練習：對代理外掛倉庫執行SCA掃描，然後問自己——能否找出哪個漏洞可透過Claude技能、生命週期鉤子或能傳送本地檔案的MCP伺服器被利用？如果不能，說明你看到的只是鎖檔案，而非代理本身。透過執行uvx --from openaca openaca scan repo --target . --include-posture，可以檢視任何包含外掛、技能或MCP伺服器的倉庫的組合情況：安裝了哪些元件，它們如何連線，以及哪些通告和姿態發現屬於哪個代理元件。

總之，AI代理安全需要組合感知分析，而不僅僅是包掃描。包從來不是單元，代理才是。