在建置過程中記錄的 SBOM 產生
CRACI 是一款 SBOM 產生工具，記錄每次 GitHub Actions 建置實際取用的內容，而不是事後掃描檔案。每份 SBOM 都會標示自身的完整程度。
重點摘要：在 CRACI 執行器上執行您的 GitHub Actions 作業，每個作業都會產生一份 SBOM，列出它取用的套件，包括遞移相依套件與從 CI 快取還原的套件，並可匯出為 CycloneDX 或 SPDX。每份 SBOM 都附有完整性狀態，並在發布後持續監控新漏洞。Syft 與 Trivy 等掃描工具從檔案重建 SBOM；CRACI 則從建置中記錄。為什麼建置時 SBOM 不一樣。
在建置過程中記錄，而非事後掃描
多數 SBOM 產生工具會在建置完成後讀取檔案，再推測並重建當初納入了哪些內容。CRACI 則在自己的 CI 執行器內產生 SBOM。具備套件感知能力的代理伺服器會觀察每個作業連往套件來源的流量，因此 SBOM 列出的是作業實際取用的內容（包含遞移相依套件），而不是 manifest 宣稱所需的內容。不需要鎖定檔（lockfile）、不需要已安裝的相依套件樹，也不需要額外的掃描步驟，就能留下這份記錄。
涵蓋每一層遞移相依套件
建置所取用的內容，大多不是直接相依套件，而是相依套件的相依套件，位於好幾層之下；其中有些甚至從未出現在鎖定檔中：建置腳本下載的預先編譯二進位檔、從快取還原的套件、作業系統套件。CRACI 會記錄作業在每一層取用的每個套件，因此能比對整個相依套件樹的漏洞。在與其他 SBOM 工具的並列比較中，這份更完整的記錄找出了其他工具未回報的漏洞。
從 CI 快取還原的套件仍會留在 SBOM 中
快取往往是建置時記錄中斷的地方：從快取還原的套件不會連線到任何套件庫（registry），因此單靠代理伺服器會漏掉它。CRACI 會讓相依套件的佐證資料隨快取一起傳遞，因此從 CI 快取還原的套件，會留在還原它的那個作業的 SBOM 中。
每個作業都有完整性狀態
漏洞追蹤只能比對 SBOM 中列出的元件。SBOM 遺漏的套件，就是一個沒有人會收到警示的漏洞。因此，CRACI 不會把每份 SBOM 都呈現為完整，而是為每個作業與每個快取標示完整性：Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。您可以清楚知道哪些 SBOM 可以信賴，哪些需要再檢查一次。
支援您出貨所用的生態系與格式
CRACI 會記錄來自 npm、PyPI、RubyGems、Cargo、Go、Nix、OCI、apt、apk 與 Git 來源的套件，以及 Yocto 與 OpenEmbedded 的下載預設組態，並將 JFrog Artifactory 的 npm 與 PyPI 鏡像視為已知來源。Maven 與 Java 支援已列入產品藍圖。SBOM 可匯出為 CycloneDX 與 SPDX 格式，並包含遞移相依套件，可直接與客戶、合作夥伴及稽核人員分享。
每個元件都附有宣告的授權
每個記錄的套件都會將其宣告的授權帶入 SBOM。您可以在出貨前看到哪些相依套件採用商業或其他限制性授權，並在 copyleft 授權進入產品之前就將其找出。
透過 API 取得來源證明
SBOM 只是 CRACI 為每個作業記錄的內容之一。公開的 REST API 會回傳 SBOM、網路追蹤記錄與來源證明（provenance），全部記錄自同一次建置。
發布後持續監控
SBOM 是企業了解其出貨軟體內容的方式，客戶與主管機關也越來越常要求提供：Cyber Resilience Act（CRA）要求製造商為在歐盟銷售的產品製作 SBOM。每當有新漏洞公開，CRACI 都會重新評估受監控的 SBOM，彙整各建置與儲存庫的檢測結果，並支援 VEX。您向自家廠商收集的 SBOM，也會與您的建置一併監控。
記錄的 SBOM 與掃描的 SBOM 對照
對於非您自行建置的軟體，掃描器是合適的工具。對於您自己的版本發布，以下是記錄建置所帶來的差異。掃描器讀取鎖定檔或建置輸出，推算當初納入了哪些內容。CRACI 則看見流入建置的流量，因此安裝掛鉤（install hook）、建置腳本與基礎映像檔所帶入的隱藏相依套件，也會出現在 SBOM 中。
| 功能 | CRACI | 掃描型 SBOM 工具 |
|---|---|---|
| 元件清單的產生方式 | 依據建置本身的套件流量記錄 | 事後從檔案重建 |
| 是否需要鎖定檔或已安裝的相依套件 | 不需要 | 通常需要其中之一 |
| 從 CI 快取還原的套件 | 佐證資料隨快取一起傳遞 | 僅限掃描時檔案仍存在的情況 |
| 每個作業的完整性狀態 | 五種狀態，依作業與快取分別標示 | |
| 從建置產物到建置的簽章連結 | 不提供簽章的來源證明 | 需另外加入簽章步驟 |
| 非您自行建置的軟體 | 改為加入廠商提供的 SBOM | |
| CI 系統 | 目前支援 GitHub Actions，其他 CI 系統已列入產品藍圖 | 可在任何 CI 中執行 |
- 支援
- 部分支援
- 不支援
- 已列入產品藍圖
想比較特定工具嗎？請參閱SBOM 工具比較，涵蓋 Syft、Trivy、cdxgen、Microsoft SBOM Tool、Dependency-Track 等。若想了解更全面的樣貌，請參閱軟體供應鏈安全工具比較。要在多個團隊推行 SBOM 嗎？請參閱跨工程團隊的 SBOM 產生。
SBOM basics: SPDX, CycloneDX and OpenVEX
SBOM 記錄了哪些內容、SPDX 與 CycloneDX 格式在實務上有何不同，以及 OpenVEX 如何補充說明某個漏洞是否真的影響產品。
Petteri Pulkkinen和Erika Marttinen 於 Kubernetes Community Days Helsinki 2026，SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains 的 16:50 至 22:05。
SBOM 產生：常見問題
什麼是 SBOM 產生？
SBOM 產生是指製作軟體物料清單（SBOM）：一份機器可讀、列出某個軟體所含元件與相依套件的清單。它可以從原始碼檔案產生、在建置過程中產生，或透過分析容器映像檔等完成的建置產物來產生。CRACI 在建置過程中，依據建置實際取用的內容產生 SBOM。
CRACI 如何產生 SBOM？
您的 GitHub Actions 作業在 CRACI 執行器上執行。每個作業執行時，具備套件感知能力的代理伺服器會觀察它連往套件來源的流量，並記錄它取用的套件，包括遞移相依套件與從 CI 快取還原的套件。每個作業都會產生各自的 SBOM，並附有完整性狀態。
我需要修改工作流程嗎？
只要將 runs-on 改為 craci。CRACI 取代的是執行器，而不是 GitHub Actions，因此您的工作流程與其執行記錄都會留在 GitHub。
CRACI 會記錄哪些套件生態系？
npm、PyPI、RubyGems、Cargo、Go、Nix、OCI、apt、apk 與 Git 來源，以及 Yocto 與 OpenEmbedded 的下載預設組態。JFrog Artifactory 的 npm 與 PyPI 鏡像會被視為已知來源。Maven 與 Java 支援已列入產品藍圖。
可以匯出哪些 SBOM 格式？
CycloneDX 與 SPDX，並包含遞移相依套件以及每個元件宣告的授權。
完整性狀態代表什麼意思？
Complete 表示 CRACI 觀察到完整的作業佐證資料，且每個還原的快取都是完整的。Complete with connections 表示該作業還使用了值得檢視的自訂網路連線。Incomplete 表示有某種情況可能導致相依套件被遺漏。Unavailable 表示無法評估佐證資料，Not recorded 則表示該作業早於完整性回報功能推出之前執行。請參閱SBOM 完整性。
CRACI 會找出 SBOM 中的漏洞嗎？
會。每當有新漏洞公開，CRACI 都會重新評估受監控的 SBOM，彙整各建置與儲存庫的檢測結果，並支援 VEX。資安團隊研判檢測結果，並轉交給負責修正的團隊。
CRACI 能為非我自行建置的軟體產生 SBOM 嗎？
不能。CRACI 記錄的是在其執行器上執行的建置。對於您採購的軟體，請加入廠商提供的 SBOM，CRACI 會將其與您自己的建置一併監控。對於非您自行建置的第三方映像檔，掃描器是務實的選擇；請參閱SBOM 工具比較。