您已經在掃描相依套件。以下是掃描器看不到的東西。

您現有工具組的強項

如果您已經設定好 SCA 與 SBOM 產生，代表最困難的組織工作已經完成：相依套件受到追蹤，資安公告會送到開發人員手上，有人詢問時也有檔案可以提供。請保留這些。

• GitHub 的相依關係圖與 Dependabot 對許多團隊來說是預設啟用的。GitHub 將相依關係圖描述為「儲存庫中所存放的 manifest 與 lock 檔案，以及透過 dependency submission API 為該儲存庫提交的任何相依套件的摘要」。Dependabot 警示以它為基礎，在新的資安公告發布或您的相依關係圖變更時通知您。
• 商用 SCA（例如 Snyk）也會產生 SBOM。它的 snyk sbom 指令會讀取 manifest 檔案及其 lockfile，並輸出 CycloneDX 或 SPDX。截至 2026 年 9 月，Snyk 的文件說明此功能「僅提供給 Snyk Enterprise 方案的客戶」。
• 開源產生工具（例如 Syft、Trivy 與 cdxgen）免費、快速，而且很容易加入 CI。Syft 將自己描述為「從容器映像檔與檔案系統產生軟體物料清單（SBOM）」的工具。

這些工具最擅長的是在 pull request 上提供快速回饋、廣泛涵蓋各種生態系，以及開發人員早已熟悉的修補工作流程。CRACI 目前並不取代這些。CRACI 的漏洞追蹤會彙整各個建置與儲存庫的發現項目，並在新漏洞出現時重新評估受監控的 SBOM。資安團隊可以研判發現項目，並將其指派給正確的團隊。政策關卡可以封鎖建置；漏洞 webhook 已列入產品藍圖。

掃描器與記錄器

上述每一款工具都是掃描器。您將它指向原始碼樹、lockfile 或容器映像檔，它就會推論出裡面包含了什麼。當檔案能說明全貌時，這種方式行得通；但當檔案無法說明全貌時，就會變得困難：

• 儲存庫沒有 lockfile，因此版本是在安裝時才決定。
• 建置從 CI 快取還原套件，而沒有任何 manifest 提到這些套件。
• 某個建置步驟直接下載工具、作業系統套件或二進位檔。
• npm 安裝 hook 或 Rust 建置腳本在安裝期間擷取更多程式碼，這正是 Shai-Hulud 蠕蟲所使用的途徑。
• 容器建置會拉取基礎映像檔及其作業系統層，而沒有任何語言的 lockfile 會列出這些內容。
• 您交付的是編譯好的二進位檔，而它旁邊的 manifest 幾乎沒有列出任何東西。

CRACI 是記錄器：它看得到流量，掃描器則看不到。它在自家相容於 GitHub Actions 的執行器上執行建置，並由一個能辨識套件的代理伺服器在作業執行期間觀察連往套件來源的流量，因此這些隱藏的相依套件都會進入 SBOM。從快取還原的套件會延續其佐證資料。CRACI 沒有 craci scan ./dir 指令，因為事後掃描目錄正是 CRACI 存在所要避免的步驟。

掃描結果取決於什麼

掃描器的輸出取決於工具本身，以及它被指向什麼。Syft、Trivy、cdxgen、Microsoft SBOM Tool、GitHub 的相依關係圖匯出與 Socket CLI，各自根據能讀取的內容推算出清單。以下模式來自這些工具文件所記載的運作方式。

沒有任何元件能被每一款工具找到

每個產生工具都自行決定什麼算是元件、要信任哪些檔案，因此同一份 checkout 會讓每個工具得出不同的清單。GitHub 的相依關係圖匯出又是另一種做法：它是根據 GitHub 對該儲存庫的了解建立，而不是根據掃描器讀取的檔案，而且它讀取的是預設分支，而不是固定的 commit。

沒有 lockfile，就沒有相依套件

Express 5.2.1 沒有提交 lockfile。指向一份乾淨的 checkout 時，從 lock 檔案或已安裝檔案樹解析相依套件的產生工具，眼前兩者都沒有，因此 package.json 中宣告的 npm 相依套件全都不會進入文件。這裡沒有任何工具是壞掉的。決定 SBOM 是否包含任何相依套件的變數不是工具，而是有沒有人先執行過安裝。

一個旗標就改變答案

Syft 預設的目錄掃描會回報專案宣告的內容，而不是磁碟上實際安裝的內容。在同一個 express 版本已安裝的 checkout 上，一個 cataloger 旗標就決定了已安裝的 npm 套件是否會出現在清單中。同樣的工具、同樣的版本、同樣的檔案樹。

產品是二進位檔

v2.1.259 版的 anthropics/claude-code 儲存庫沒有任何形式的相依性 manifest 或 lockfile。它發布的 npm 套件宣告零個執行期相依套件，並透過八個平台套件包裝一個預先建置的原生二進位檔。@openai/codex 0.149.1 的結構也一樣。manifest 讀取工具幾乎沒有東西可以描述，而實際執行的程式是編譯好的二進位檔，因此每個工具回傳的結果，反映工具本身的成分多於反映專案。

同一個套件，不同的版本

即使兩個工具找到同一個東西，它們也不一定對它是什麼有共識。一個工具可能將 GitHub Action 固定為 commit SHA，另一個則回報發布標籤。以錯誤版本為鍵的漏洞查詢，會自信滿滿地回傳錯誤的答案。

CRACI 如何與您的 SCA 搭配

請繼續在 pull request 上使用您的 SCA。那是在合併前攔截有漏洞版本的正確位置。當問題與建置而非 diff 有關時，再加入 CRACI：

• 這個版本實際包含了什麼？記錄的 SBOM 涵蓋 npm、PyPI、RubyGems、Composer、Cargo、Go、Nix、OCI、apt、apk 與 Git 來源，以及下載預設集，包括遞移相依套件。npm 與 PyPI 的 JFrog Artifactory 鏡像也能使用。
• 這份清單可信嗎？每個作業與快取都有完整性狀態，因此不完整的紀錄會清楚顯示，而不是在不知不覺中缺漏。
• 新的資安公告會影響我們嗎？受監控的 SBOM 會在新漏洞發布時重新評估，發現項目也會彙整各個建置與儲存庫的結果。

SBOM 可透過公開 REST API 以 CycloneDX 格式下載，同時提供作業的網路追蹤紀錄與來源證明，因此可以提供給任何能讀取 CycloneDX 的工具，包括您已在使用的 SCA。設定只需在工作流程中修改一行：將 runs-on 改為 craci。目前支援的 CI 是 GitHub Actions；GitLab CI、Jenkins 與其他 CI 系統已列入產品藍圖。

部署位置的資產清冊

CRACI 的資產清冊檢視會精確顯示全球各地哪些軟體版本部署到了哪些產品。當新漏洞出現時，您可以直接看到哪些產品執行受影響的版本，而不必再從版本說明與試算表拼湊答案。

進一步了解建置時 SBOM 產生與漏洞追蹤。

關於 CRACI 取代了什麼、沒有取代什麼，請參閱CRACI 取代了什麼。