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代理安全需要組合感知分析，而不僅僅是包掃描。包從來不是單元，代理才是。