AI 產生的 SBOM 是對您建置的猜測。主管機關要的是記錄。

團隊為什麼會嘗試

它的吸引力是真實的。您將儲存庫或 lockfile 貼進程式設計助理，要求產出 CycloneDX，幾秒內就會得到一份格式完整的文件。它甚至能填入掃描工具通常留白的欄位。供應商（supplier）欄位就是常見的例子：大多數產生工具沒有這項資訊的來源，因此會留白。被要求產出完整文件的模型，則能在每個欄位都寫進些什麼。

最後這一點，正是問題的縮影。不知道供應商的掃描工具會讓欄位留白；不知道供應商的模型，仍可能給出一個看似合理的答案。文件看起來更完整，可靠性卻更低。

模型實際看到的是什麼

產生 SBOM 的模型依據眼前的文字運作：manifest、lockfile，或許還有 Dockerfile。它並不觀察建置。因此它看不到：

• 當儲存庫沒有提交 lockfile 時，套件管理工具解析出的版本；
• 從 CI 快取還原的套件；
• 建置步驟直接下載的工具、作業系統套件與執行檔；
• 與幾乎空白的 manifest 一起交付的已編譯執行檔裡包含什麼。

有兩個儲存庫可以說明這些檔案的資訊有多單薄。expressjs/express 5.2.1 沒有提交 lockfile，因此其 package.json 以版本範圍列出相依套件，實際版本要到安裝時才決定。v2.1.259 版的 anthropics/claude-code 儲存庫完全沒有任何相依套件 manifest 或 lockfile，其發布的 npm 套件宣告了零個執行階段相依套件，同時包裝了一個預先建置的原生執行檔。指向該儲存庫的確定性掃描工具，沒有任何可讀取的內容能描述這個執行檔。拿到相同檔案的模型同樣缺乏資訊，卻有更大的空間去填補這個缺口。

幻覺是有文獻記載的失效模式

語言模型會說出不存在的套件名稱。量測最完整的案例是程式碼產生，而非 SBOM 撰寫，但它所顯示的失效模式同樣適用於元件清單。一項 USENIX Security 2025 研究使用 16 個模型產生了 576,000 個程式碼樣本，發現商業模型的平均幻覺套件比率至少為 5.2%，開源模型則為 21.7%，共出現 205,474 個不重複的幻覺套件名稱。GitHub 自己的 Copilot Autofix 文件也警告，它「可能建議以統計上可能的名稱發布的捏造相依套件」。

模型也不會每次都給出相同答案。Anthropic 的文件指出：「即使將 temperature 設為 0，結果也不會完全確定，相同的輸入在不同的 API 呼叫間可能產生不同的輸出。」從同一個 commit 產生的兩份 SBOM 可能不同，而兩者都不會告訴您哪一份才正確。

在 SBOM 中，幻覺產生的項目並不是無害的錯字。一個不存在的套件，或真實套件的錯誤版本，會讓漏洞查詢找錯地方，而得到的結果既篤定又錯誤。

標準期望 SBOM 包含哪些內容

NTIA 最低要素（2021 年）

NTIA 基準定義了七個資料欄位：供應商名稱、元件名稱、元件版本、其他唯一識別碼、相依關係、SBOM 資料作者，以及時間戳記。這些欄位搭配自動化支援，以及一套實務與流程。每個欄位描述的都是關於軟體的事實，而不是對軟體的看法。

CISA 2026 年最低要素

2026 年 7 月 29 日，CISA、NSA、FBI 與國際夥伴發布了更新版的最低要素，取代 2021 年的基準。其中幾項新增內容，若不觀察建置過程就很難滿足：

• SBOM Generation Context：「SBOM 作者產生 SBOM 當下所處的相對軟體生命週期階段與可用資料」，並以「before build」、「build」與「after build」為例。讀取儲存庫的模型，最多只處於 before build。
• Component Hash Value：「對可執行元件產物套用密碼學雜湊演算法所產生的輸出。」若作者沒有該產物，「SBOM 作者應標示該值為未知」。從未接觸產物的模型無法產生雜湊值，只能產生看起來像雜湊值的文字。
• SBOM Tool Name and Version：必須列出用來產生 SBOM 的工具名稱。
• Coverage：「SBOM 應包含構成目標軟體之所有元件的資訊，包括遞移相依套件。沒有最低深度。」
• 明確標示未知資訊：作者「應明確說明該資訊是否為未知」。捏造的值正好與此相反。

歐盟 Cyber Resilience Act

CRA 將 SBOM 訂為具數位元素產品製造商的法定義務。附件 I 第 II 部分要求製造商「識別並記錄具數位元素產品所含的漏洞與元件，包括以常用且機器可讀的格式製作軟體物料清單，且至少涵蓋產品的頂層相依套件」。附件 VII 將 SBOM 列入技術文件，市場監督機關可要求提供，以查核是否符合基本要求。

這些文本都沒有禁止 AI 工具。它們要求的是描述實際產品的資料，以及對未知事項的誠實說明。依推論寫出的 SBOM，在這兩方面都很難做到。

CRACI 如何產生 SBOM

CRACI 在自己的執行器上執行您的 GitHub Actions 作業。您只要將 runs-on 改為 craci，執行記錄仍會顯示在 GitHub 中。作業執行期間，一個能辨識套件的代理伺服器會觀察前往套件來源的流量，因此 SBOM 記錄的是建置實際拉取的內容，包括遞移相依套件。相依套件的佐證資料會隨 CI 快取一併保留，因此從快取還原的套件也會留在記錄中。

• 生態系：npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk 與 Git 來源，以及下載預設集。
• 完整性：每個作業與快取都會標示為 Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded，因此未知之處會明確說明，而不是被填補。
• 格式：CycloneDX 與 SPDX，匯出內容包含宣告的授權中繼資料。
• 來源證明：API 會回傳 SBOM、網路追蹤記錄與來源證明。

CRACI 能自動化更廣泛的 CRA 法規遵循流程所需的相當大一部分供應鏈可見度與佐證資料，但它本身並不會讓產品符合法規。詳情請參閱建置時 SBOM 產生，時程則請參閱我們的 CRA 概覽。

AI 在 SBOM 上真正能幫上忙的地方

一旦有了記錄下來的 SBOM，模型就很擅長處理它：摘要哪些元件帶有風險、以白話解釋資安公告，或草擬相關文件供人員審閱。原則很簡單：讓建置產生記錄，讓模型閱讀記錄。