您的 SOC 2 平台證明控制措施有在運作，CRACI 則記錄建置實際包含了什麼。

本頁討論的做法

許多 SaaS 團隊最後都採用相同的配置：由 Syft 或 Trivy 等產生工具在 CI 中產出 SBOM，漏洞掃描器監看各個儲存庫， 再由法規遵循自動化平台串接 GitHub 與雲端帳戶，為 SOC 2 收集佐證資料。這套做法行得通，稽核人員接受， 也沒有人需要在稽核前一週忙著截圖。

這些平台很擅長這件事。Vanta 表示它「以唯讀方式串接您的雲端、身分、程式碼與裝置工具」， 並「自動擷取佐證資料、將其對應至控制措施」，每小時執行超過 1,200 項自動化測試。Drata 則串接「雲端基礎架構、身分提供者、人資系統、程式碼儲存庫、工單工具等」，收集佐證資料並對應至 SOC 2 控制措施。 如果目標是一份乾淨的 SOC 2 報告，它們就是合適的工具。

本頁探討的是一個更聚焦的問題：這些佐證資料對 SBOM 本身說明了什麼。

SOC 2 檢查實際在問什麼

SOC 2 查核是依據 AICPA 信任服務準則（Trust Services Criteria）提出報告。與 SBOM 最相關的準則是 CC7.1：

「為達成其目標，該組織使用偵測與監控程序，以辨識（1）導致新漏洞產生的組態變更，以及（2） 對新發現漏洞的易受影響性。」

AICPA, 2017 Trust Services Criteria, CC7.1

這項準則描述的是結果，至於方法以及背後元件清單的深度，則交由您與稽核人員決定。因此自動化測試通常只問控制措施是否到位且在運作： 掃描器是否已串接、是否已執行、發現的問題是否依您的政策處理。這是合理的問題，也就是那個勾選框。

這項檢查沒有問的是：掃描所依據的 SBOM 是否列出了版本中包含的所有內容。位於 SBOM 從未列出之元件中的漏洞， 無法與任何項目比對，於是掃描結果是乾淨的，控制措施依然顯示為綠燈。

綠燈與完整 SBOM 分道揚鑣之處

SBOM 產生工具依據眼前的檔案運作，而它們自己的文件也顯示了這會在哪裡留下缺口：

• 以未提交 lockfile 的 expressjs/express 5.2.1 為例，從 lockfile 解析相依套件的產生工具 沒有東西可解析。它仍可能回傳一份文件，列出它能辨識的其他項目，例如 GitHub Actions 與工作流程檔案， 卻不含 package.json 中宣告的任何 npm 相依套件。
• 不同的產生工具對同一份程式碼會回傳不同的清單，因為各自決定什麼算是元件。GitHub 的相依關係圖匯出 差距更大：它依據 GitHub 對儲存庫的了解建立，讀取的是預設分支，而非固定的 commit。
• 大多數文件中的 NTIA 供應商欄位都是空白，因為大多數產生工具沒有這項資訊的來源。

這些工具都沒有壞。每一個都讀取了它被指定的檔案，也都依排程產出符合標準格式的有效文件。 就法規遵循測試而言，控制措施有在運作。但 SBOM 仍然沒有描述出這套軟體。

CRACI 為佐證資料補上什麼

CRACI 取代 GitHub Actions 執行器。您只需將 runs-on 改為 craci，執行紀錄仍會 顯示在 GitHub 介面中。SBOM 在建置進行時於該執行器內產生：具套件感知能力的代理伺服器會觀察前往套件來源的流量， 因此紀錄反映的是作業實際拉取的內容，而不是檔案上說應該拉取的內容。

完整性是明確標示，而非假設

每個作業與每個快取都會獲得五種完整性狀態之一：Complete、Complete with connections、Incomplete、 Unavailable 或 Not recorded。相依套件的佐證資料會隨快取一起傳遞，因此從暖快取還原的套件會被延續記錄，不會悄悄消失。 紀錄不完整時，它會明確說明。

這與標準的發展方向一致。CISA 與其合作夥伴發布的 2026 年 SBOM 最低要素，要求 SBOM 作者 「明確說明該資訊是否為 SBOM 作者所未知」，而不是讓欄位悄悄留白。

以稽核人員接受的格式提供佐證資料

SBOM 可匯出為 CycloneDX 或 SPDX，並包含在其元件中發現的漏洞。公開 REST API 會回傳 SBOM、 作業的網路追蹤與來源證明資料，因此同一批紀錄可以送到您存放稽核佐證資料的任何地方。

部署於何處的資產清冊

CRACI 的資產清冊檢視畫面會顯示在全球範圍內，哪些軟體版本確切部署到哪些產品中。當新漏洞出現時， 您可以看到哪些產品執行受影響的版本，而不必從版本說明與試算表中拼湊答案。

保留 SOC 2 平台

CRACI 並非法規遵循自動化平台，也不會取代這類平台。它不管理政策、存取審查、裝置檢查或廠商問卷。 兩者回答的是不同的問題。您的法規遵循平台證明控制措施存在且在運作；CRACI 則記錄建置拉進了什麼，以及該紀錄是否完整。

一旦您將軟體銷往歐盟，這項差異就會擴大。Cyber Resilience Act（CRA）要求製造商識別並記錄元件， 方式是「以常用且機器可讀的格式編製軟體物料清單，至少涵蓋產品的頂層相依套件」（附件 I 第 II 部分）。 附件 VII 將 SBOM 列入技術文件，並允許市場監督機關要求提供。SOC 2 報告證明的是您的組織如何執行其控制措施， CRA SBOM 描述的則是特定產品。我們的 CRA 概覽說明了時程，而 CRA 法規遵循頁面則說明 CRACI 能自動化哪些工作。CRACI 能自動化 更廣泛的 CRA 法規遵循流程中所需的相當大一部分供應鏈可視性與佐證資料，但它本身並不會讓您達到合規。

同樣的佐證資料也適用於 ISO 27001 與 NIS2。逐項控制措施的對應，請參閱 以 SBOM 作為 ISO 27001、SOC 2 與 NIS2 的佐證資料。

如何在不影響稽核的情況下試用

1. 挑選一個其 SBOM 已納入您 SOC 2 佐證資料的儲存庫。
2. 將 runs-on 改為 craci，讓其版本發布工作流程改在 CRACI 上執行。
3. 將記錄下來的 SBOM 與您目前產生的 SBOM 逐一元件比較，並檢查該作業的完整性狀態。
4. 判斷這項差異是否應納入您的佐證資料。

您可以進一步了解 建置時 SBOM 產生與 CRA 佐證資料，或在我們的 資安頁面上了解我們如何記錄自身的控制措施。