SBOM 完整性

當 SBOM 在相依關係樹的每個層級，列出所描述軟體中的每個元件，包括任何鎖定檔（lockfile）或 manifest 都未列出的元件時，這份 SBOM 就是完整的。SBOM 完整性指的就是這項特性。CISA 的 2026 Minimum Elements 要求 SBOM 作者在資訊不明時明確說明，並指出若關鍵的元件資料遭隱瞞，接收方可能會認定該 SBOM 不完整。

完整性、有效性與品質是不同的事

問題	代表的意義	由什麼檢查	它無法告訴您的事
有效	檔案符合 CycloneDX 或 SPDX 的 schema	schema 驗證工具	是否有元件遺漏
欄位品質	每個元件都有名稱、版本、供應商、識別碼、授權與雜湊值	品質評分工具	是否有元件遺漏
完整	進入軟體的任何東西都沒有遺漏	與建置實際取用內容的比對	比對時沒看到的輸入

第二列的識別碼通常是 package URL 或 CPE。一個檔案可以完美通過前兩項檢查，卻仍然漏掉一半的軟體。

為何完整性難以事後衡量

掃描工具依據鎖定檔、manifest 或最終產出運作。它無從得知安裝後腳本下載的套件、編譯進二進位檔的 crate，或從未提供給它的基礎映像檔層。這些都是隱藏相依套件。

以一個鎖定檔列出 400 個套件的 Node.js 服務為例。其中一個套件有 postinstall 腳本，會在 npm ci 執行期間下載預先建置好的二進位檔。由 package-lock.json 產生的 SBOM 是有效的，每個元件都有版本與 package URL，但那個二進位檔並不在其中。任何品質分數都不會標示出這一點，因為檔案中沒有任何內容指向遺漏的東西。

事後重新建置也無法解決這個問題：除非該建置是可重現建置，否則第二次建置取用的內容可能與第一次不同。

如何誠實呈報完整性

• 說明產生情境： SBOM 是在建置前從原始碼產生、在建置期間記錄，還是在建置後分析產出而得。
• 列出已知缺口： 工具無法看到的軟體部分，例如內嵌（vendored）的程式碼、預先建置的二進位檔，或在套件管理工具之外安裝的元件。
• 優先使用附帶原因的狀態，而非分數。 完整性百分比需要一個總數，而這個總數正是沒有人知道的。像「不完整：作業允許了未受監控的流量」這樣的陳述，才能據以行動。

SBOM 最佳實務涵蓋了說明 SBOM 未能看到哪些內容的更廣泛做法。

CRACI 中的完整性狀態

CRACI 會為每個作業的 SBOM 給定完整性狀態，快取也有各自的狀態。CRACI 的文件對這些狀態的定義如下：

• Complete：「CRACI 觀察到完整的作業佐證資料，且每個還原的快取都是完整的。」
• Complete with connections：「已通過各項要求，但作業使用了一個或多個自訂網路連線。」
• Incomplete：「CRACI 發現了可能導致相依套件未列入 SBOM 的狀況。」
• Unavailable：「CRACI 無法完成佐證資料的評估。」
• Not recorded：「該作業早於完整性呈報功能推出之前。」

CRACI 之所以能做出這樣的說明，是因為它能看到每個作業連往套件來源的流量，因此知道何時可能有東西繞過了它：它未監控的流量，或自身 SBOM 不完整的還原快取。當作業不完整時，作業會顯示原因，例如「Unmonitored traffic was allowed」。請參閱 SBOM 產生。

這些狀態適用於在 CRACI 執行器上執行的建置。對於來自供應商的 SBOM，或來自不在 CRACI 上執行之管線的 SBOM，請使用上述的比對方式與呈報原則。