SBOM 是什麼？SCA、CycloneDX、SPDX 與軟體供應鏈安全完整指南

先講結論：SBOM 不是弱點掃描報告，也不是 package.json 的複製品

Software Bill of Materials 是一份可由機器處理、針對明確軟體產品與版本的階層式元件清冊。它至少要能辨識元件、版本、Producer、唯一識別、Hash、License、相依關係、產生者與時間，並說明涵蓋範圍與未知部分。它描述 Composition 與 Relationship，本身不證明元件沒有漏洞、沒有惡意程式或一定能在 Runtime 被利用。

Manifest 表示開發者宣告想使用什麼；Lockfile 表示 Package Manager 解析出什麼；Build-time SBOM 應描述這次建置實際使用與打包什麼；Deployed Inventory 則回答目前環境運行哪一個 Digest。四者若沒有連結，安全團隊可能對 Repository 中不存在於 Production 的套件開 Ticket，或漏掉 Multi-stage Build、OS Package 與 Binary 中真正存在的元件。

高品質 SBOM 的目標不是檔案數量，而是讓新漏洞出現時能快速回答：哪些 Release 與環境包含精確元件？是否真的受影響？由哪個團隊負責？可用哪個修復版本？如何重建、重新部署並確認舊 Artifact 消失？

• 一個 Release／Artifact Digest 對應一份可驗證、可版本化的 SBOM
• 涵蓋直接與遞迴相依、第一方與第三方、應用與 OS／Container 元件
• 未知、無法解析與刻意遮蔽的範圍必須明確標示，不能默認完整
• SBOM 進入持續監控、修復與採購流程，而不是發布後封存

SBOM、SCA、Dependency Graph、VEX 與 Provenance 各自回答什麼？

SCA（Software Composition Analysis）是辨識元件、建立相依圖、匹配已知漏洞與 License、套用政策並追蹤修復的分析流程；SBOM 是可交換的組成資料；Dependency Graph 表示誰依賴誰；VEX 表示特定產品對特定漏洞的受影響狀態與理由；Provenance 則提供建置者、來源、流程與輸入的可驗證證據。

Artifact Signature 只能證明簽章者對某個位元內容背書，不能單獨證明來源或建置流程正確；Provenance 若由可被 Build Script 任意偽造的環境自述，也沒有強可信度；SBOM 若未綁定 Digest，則可能被拿去對錯誤版本進行分析。這些證據要以相同 Subject Digest 串接。

供應鏈威脅模型：風險不只來自『有 CVE 的套件』

依賴風險包含已知漏洞、惡意套件、Typosquatting、Dependency Confusion、Maintainer Account Takeover、撤回或遭替換的 Release、安裝腳本任意執行與棄置元件；來源端可能出現惡意 Commit、Branch Protection 繞過與被盜簽章金鑰；建置端則可能遭 Runner、Cache、Plugin、Build Image 或發布 Token 入侵。

部署端仍可能下載錯誤 Registry、以 Mutable Tag 取代 Digest、跳過 Admission Gate，或讓已撤銷 Artifact 繼續運行。SBOM 主要提供可見性；要抵抗完整性攻擊，仍需不可變依賴、隔離建置、工作負載身分、最小 CI 權限、簽章、Provenance 與部署前驗證。

CISA／NSA 2026 Minimum Elements：最低可交換基線

2026 年 7 月發布的聯合指引延續 NTIA 2021 基礎，並新增 SBOM Author Signature、SBOM Version 與 Component Hash Value 等元素，同時強化 SBOM Author、Component Identifier、Coverage、Timestamp、Dependency Relationship、Distribution 與 Delivery 的期望。這是最低透明度基線，不是組織可以停止改善的上限。

實作上，SBOM Document Metadata 與 Component Metadata 要分清楚。文件需要 Author、Signature、Version、Format／Spec、Generation Tool、Timestamp 與 Generation Context；每個元件則需要 Producer、Name、Version、Identifier、Hash、License 與 Relationship。若工具無法識別某個欄位，應以標準允許的 Unknown／No Assertion 表示，而不是捏造。

CycloneDX 與 SPDX 怎麼選？先看使用情境與工具鏈

CycloneDX 1.7 的 Object Model 可描述元件、服務、直接與遞迴相依、Composition Completeness、漏洞、VEX、Formulation、Annotation、Declaration 與 Citation，並提供 JSON、XML、Protobuf 等機器可讀格式。它以供應鏈風險與多種 BOM 能力為核心，適合安全、自動化與服務關係場景。

SPDX 3.0.1 從 Software Package Data Exchange 擴展為 System Package Data Exchange，以 Core 搭配 Software、Security、Licensing、Build、AI、Dataset 等 Profile，能表達 Package、File、Snippet、License、Vulnerability、Provenance 與完整關係。許多既有生態仍廣泛使用 SPDX 2.3，導入前應確認上下游工具真正支援的版本與 Serialization。

沒有一個格式在所有組織都必然較好。應以採購要求、Registry／Scanner／Artifact Store 支援、License 流程、VEX／Service／Build Metadata 需求與驗證工具成熟度決定；選定 Profile、Spec Version 與必填欄位後，透過 Schema Validation 與 Golden Sample 驗收。

元件識別是 SCA 精準度的核心：Name + Version 常常不夠

同名套件可能來自不同 Ecosystem、Namespace、Supplier 或 Fork；相同 Version String 也可能因 Distribution、Architecture、Build Metadata 或 Backport 而包含不同程式碼。SBOM 應優先使用 Package URL（purl）、CPE、SWID、SWHID、VCS Commit、Container Digest 與 Component Hash 等可機器處理識別，並保留 Namespace、Qualifier 與 Subpath。

purl 適合描述 Package Ecosystem 與封裝座標；CPE 常用於對照 NVD 產品，但映射品質不一；Hash 能辨識精確內容，卻不能自己說明元件語意。實務上應保存多種 Identifier 並記錄 Mapping Confidence，SCA 不應只以模糊名稱自動建立高嚴重度 Finding。

在哪裡產生 SBOM？Build-time 通常是最可行的主版本

Design／Source SBOM 能早期呈現宣告依賴；Build SBOM 能取得解析後版本、Build Tool 與實際輸入；Post-build Binary Analysis 能發現打包進成品但 Manifest 不知道的元件；Runtime Observation 則補充 Plugin、動態下載與外部服務。不同階段觀察到的事實不同，不能混成一份卻不標示 Generation Context。

主要 Release SBOM 應在受控 CI Builder 內，依 Lockfile 與實際輸入產生，再以 Binary／Container Scan 補充，最後和 Artifact Digest、Source Revision、Builder Identity 與 Provenance 一起發布。不要由開發者在筆電事後對 Repository 跑一次工具，便宣稱代表 Production。

Dependency Graph 要保留直接、遞迴、Scope 與實際包含關係

只列平面套件清單會失去修復路徑：安全團隊知道某個遞迴元件有問題，卻不知道是哪個 Direct Dependency 帶入。Graph 應表達 Root Component、Direct／Transitive Relationship、Runtime／Development／Optional／Peer Scope、Included／Derived-from、Container Parent 與 Service Relationship。

Development Dependency 不應一律從 SBOM 排除。若它能在 Build 時執行、修改 Artifact、上傳 Release 或取得 Secret，就屬供應鏈攻擊面；但在 Production Vulnerability Queue 中，可依『未打包且 Runtime 不存在』降低適用性。資料應保存，判讀在下游完成。

• 從 Root 到每個元件都有可追溯 Path，不產生孤兒節點
• 同元件不同版本或不同 Metadata Instance 分開表示
• Fork、Backport、Vendored Copy 與靜態連結保留 Pedigree
• Composition Completeness 明確，不以空清單代表沒有依賴

鎖版本還不夠：Lockfile、Hash、Registry 與安裝腳本一起治理

Lockfile 可固定解析結果，但 Pipeline 必須使用會嚴格遵守 Lockfile 的安裝模式，並在 Manifest 與 Lockfile 不一致時失敗。Package Manager 應只從受控 Registry／Mirror 解析，內部 Package 使用 Namespace／Scope，避免 Public Registry 以更高版本劫持名稱。

下載內容要驗證 Integrity Hash、Signature 或 Provenance；Artifact Repository 採不可變、保留與權限政策。安裝 Lifecycle Script 具有執行任意程式碼能力，應預設停用或 Allowlist，尤其不能讓未審查依賴在持有 Production Secret 的 CI Job 先執行。

SLSA Provenance：證明成品從預期來源與流程產生

SLSA 1.2 以 Track 與遞增 Level 描述供應鏈安全保證。Build Provenance 連結 Artifact Subject Digest、Builder、Build Type、External Parameters、Resolved Dependencies 與 Source；由建置平台自動產生並簽署，比 User-controlled Build Script 自述更可信。

Level 不是徽章，而是可驗證的保證。組織應定義可接受 Builder、Source Repository、Workflow／Build Type、Branch／Tag、Parameters 與依賴來源，部署前對 Provenance 驗證。即使簽章有效，只要 Builder 不在 Allowlist、來源不是正式 Repository、Build Parameter 開啟 Debug 後門，仍應拒絕。

把 Artifact、SBOM 與 Provenance 綁在同一個 Digest 上

檔名、Version Label 與 Container Tag 都可重複或被移動，只有 Content Digest 能指向不可變內容。SBOM 的 Subject、Provenance 的 Subject、Artifact Signature 與部署 Manifest 應引用相同 Digest；SBOM 與 Attestation 本身也要簽署或放在具完整性與不可變保護的 Artifact Store。

驗證順序是：取得 Artifact Digest、驗簽章與 Trust Identity、解析 Provenance、確認 Builder／Source／Parameters，再驗證 SBOM Schema、Author Signature、Subject Digest、必要欄位與 Coverage，最後套用 Vulnerability、License、Policy 與 Deployment Gate。不要先相信 SBOM 內容，再拿它推導 Artifact 是否可信。

SCA 如何把 SBOM 對照漏洞？先處理匹配品質

SCA 會把 purl、CPE、Version、Hash 與 Ecosystem Metadata 對照 OSV、NVD、Vendor Advisory、GitHub Advisory、Linux Distribution Security Tracker 等來源。不同資料庫的 Identifier、Affected Range、Backport 與發布時間不同，不能把單一 Feed 視為真相。

False Positive 常來自名稱相似、CPE 過寬、版本解析錯誤、Distribution Backport、只在 Source 出現未打包、或 CVE 影響的是未啟用功能；False Negative 則可能來自 SBOM 不完整、Vendored Code、靜態連結、改名 Fork、無版本元件或資料庫尚未收錄。Finding 應保留 Matching Evidence、Confidence 與 Source。

CVE 命中不是風險結論：結合 VEX、可達性與環境情境

VEX 讓 Supplier 或其他評估者以機器可讀方式表達特定 Product／Component 對特定 Vulnerability 的狀態，例如 Affected、Not affected、Fixed 或 Under investigation，並提供 Justification、Impact Statement 與 Action。它能降低大規模 CVE 對照後的噪音，但 VEX 是可追溯的安全聲明，不是『供應商說沒事』就永久忽略。

Not affected 必須綁定精確產品版本、元件、漏洞與理由，例如 Component Not Present、Vulnerable Code Not Present、Vulnerable Code Not in Execute Path 或 Inline Mitigation；同時記錄 Issuer、Timestamp、版本、簽章與有效期。當成品、設定、Feature Flag、部署架構或漏洞情報改變時，VEX 必須重新評估。

優先排序還要加入 Internet Exposure、Privilege、Data Sensitivity、Runtime Reachability、Exploit Maturity、EPSS、CISA KEV、業務關鍵度與補償性控制。CVSS 不應直接等於修復 SLA。

License 與維護風險也屬 SCA：不要只看 CVE

元件可能沒有已知漏洞，卻採用與產品散布模式衝突的 License、含未知 License、已停止維護、只有單一 Maintainer、發布流程薄弱或無法取得安全更新。SCA Policy 應分開治理 Security、License、Operational Health 與 Supplier Trust，避免把不同決策全部塞進一個風險分數。

License 要保存 Declared 與 Concluded 結果、SPDX License Expression、Copyright／Notice 與例外；安全團隊不應自行提供法律結論，但要把未知、衝突或政策禁止項目交由法務／開源辦公室處理。安全修補不能因 License Review 流程過慢而無限等待，需有緊急例外與後補證據。

• 新元件導入前檢查 License、維護活性、發布簽章、回報管道與歷史事件
• 高權限、解析不可信輸入、密碼學與更新元件採更高 Supplier Assurance
• 未知 License、無 Owner、EOL、無修復版本與不可重建元件分別建政策
• 例外有 Owner、原因、範圍、補償性控制、到期與重新審查

容器、OS Package、靜態連結與 SaaS 的範圍怎麼處理？

Container SBOM 應涵蓋 Base Image、OS Package、Language Package、應用 Binary 與 Layer 來源，並以 Image Digest 識別。Multi-stage Build 的建置工具若未進入最終映像，仍屬 Build Supply Chain Inventory；Production Vulnerability Queue 則應以最後 Runtime Artifact 為主。

Go、Rust、C／C++ 靜態連結、Vendored JavaScript、Fat JAR、Native Extension 與 Firmware 可能無法只靠 Package Manager Manifest 辨識，需要 Binary Scanner、Compiler Metadata 與 Build Integration。SaaS 沒有傳統可下載 Release 時，可用 Release／Deployment Identity、服務與外部依賴透明度、變更頻率與供應商介面建立持續 SBOM，但不能把一份過期清單代表持續變動服務。

CI/CD Gate：避免『所有 CVE 一律擋』造成安全流程被繞過

Pull Request Gate 適合檢查新依賴、Lockfile 漂移、來源、License 與已知高風險；Release Gate 檢查 Artifact、SBOM、Provenance、Signature 與不可接受 Finding；Deployment Gate 再驗 Digest、環境政策與批准例外。既有風險與新引入風險應分開，避免歷史債務讓每次 Build 永遠失敗。

政策應依 Exploit、Reachability、KEV、曝露、修復可得性與業務情境決定，並提供可審查的 Exception-as-code。Scanner Feed 暫時不可用時，組織需明確決定 Fail-closed、使用最近成功快照，或只允許非 Production；不能讓 Pipeline 自動跳過卻沒有證據。

修復不是只升級 Version：沿 Dependency Path 找到可交付解法

直接相依可升級、替換或移除；遞迴相依則先辨識引入它的 Parent，評估升級 Parent、使用 Resolution／Override、回補 Patch 或移除功能。Override 可能破壞相容性，必須跑完整測試；無修復版本時，可停用功能、限制曝露、WAF／Sandbox、最小權限或隔離，但補償性控制有期限。

修復完成後應重新解析、重新建置、產生新 SBOM 與 Provenance、簽署、部署新 Digest，確認功能與安全測試通過，並查詢所有環境、節點與 Registry，證明舊 Vulnerable Digest 不再運行。只把 Ticket 改成 Fixed，沒有成品與部署證據，不能關閉風險。

漏洞事件應變：新 Advisory 出現時如何用 SBOM 加速

重大新漏洞出現時，先將 Advisory Identifier、Affected Range、Hash／Commit 與 Ecosystem 正規化，對所有 Release SBOM 與 Deployed Digest 查詢；再沿 Dependency Path 找 Owner 與 Parent，確認 Presence、Reachability、VEX、曝露與可利用性，建立分級處置清單。

同時檢查 Build Tool、CI Plugin、Registry 與受影響元件是否曾在建置階段執行，因為『未進入 Production Binary』不代表沒有供應鏈妥協。若懷疑惡意套件或發布帳號被接管，需撤銷 Token、隔離 Builder、清除 Cache、從可信 Source 重新建置，並輪替可能接觸的 Secret。

• 以 Deployed Digest 查詢，不只搜尋 Repository Manifest
• 保存 Matching Evidence、Dependency Path、Owner、Environment 與 VEX 狀態
• 同時評估 Runtime Vulnerability 與 Build-time Compromise
• 修復後確認舊 Artifact、Image、Cache、Package 與 Credential 全部處置

品質指標：SBOM 檔案存在率不是成功標準

治理指標應測量可用性與決策速度：Release 與 Digest 綁定比例、Schema／Signature／Provenance 驗證率、Identifier 完整度、相依 Graph 可達率、Known Unknown、部署覆蓋、新 Advisory 到定位時間、Finding 到修復部署時間，以及舊 Digest 清除時間。

元件數越多不必然代表較完整，工具可能重複列出、把開發 Cache 當 Production 或產生孤兒節點；漏洞數下降也可能只是 Feed、匹配或 Coverage 退化。每個指標都要搭配抽樣與 Golden Artifact，比對 SBOM、Binary、Lockfile 與 Runtime。

分階段導入：先建立可重現的 Release Inventory，再加高階判讀

第一階段從關鍵服務建立 Lockfile、受控 Registry、Build-time SBOM、Artifact Digest 與 Owner；第二階段將 SBOM 自動驗證、簽署並與 Provenance 發布；第三階段接入 SCA、VEX、License、部署 Inventory 與 Ticket Workflow；第四階段才導入 Reachability、Admission、SLSA 強化、供應商交換與跨組織政策。

供應商採購時，不只要求『提供 SBOM』，還要定義支援格式／版本、最低欄位、Coverage、Known Unknown、交付方式、更新頻率、錯誤修正、VEX、漏洞通知與終止支援。收到檔案後要實際 Ingest 與驗證，不能把 PDF 或欄位殘缺 JSON 當合格。

常見迷思：有 SBOM 不等於供應鏈安全

『產生 SBOM 就合規也安全』忽略內容品質與消費流程；『沒有 CVE 就能用』忽略惡意套件、來源與維護風險；『Scanner 說有 CVE 就一定能攻擊』忽略匹配、版本、部署與可達性；『Signature 有效就可信』忽略錯誤 Signer 與遭入侵 Builder；『每季產一次』也無法代表每日變動的 SaaS 與 Release。

另一個迷思是 SBOM 會洩漏太多所以完全不分享。SBOM 確實可能揭露架構資訊，需要依 Audience 與契約控制 Distribution，但不應因此阻止內部 Vulnerability Management 或可信客戶取得必要資料。可以用存取控制、分層視圖、可撤銷 URL 與審計，而不是把 Transparency 歸零。

上線前檢查清單

下列項目應落實為 CI／CD Gate、Artifact Policy、Dashboard 與事件演練。SBOM 若不能被機器驗證、對到精確 Artifact、持續更新並驅動修復，就仍只是靜態文件。

• 每個 Release／Container Digest 有唯一 SBOM，格式、Spec Version、Author、Version、Timestamp 與 Generation Context 明確
• 元件具 Producer、Name、Version、purl／CPE 等 Identifier、Hash、License 與 Dependency Relationship
• 直接與遞迴相依、第一方與第三方、Runtime 與 Build-time 攻擊面皆有適當清冊
• Coverage、Known Unknown、Redaction 與工具限制明確，不以空白代表沒有風險
• Manifest、Lockfile、Registry、Hash、安裝 Script 與 Dependency Diff 都有 Gate
• SBOM、Artifact Signature、SLSA Provenance 與部署 Manifest 綁定相同 Digest
• SCA 保存匹配證據與 Confidence，結合 VEX、Reachability、KEV、EPSS、曝露與業務情境排序
• Exception 有 Owner、理由、補償控制、到期與重新審查，不可永久 Suppress
• 修復重新建置並產生新 SBOM，確認舊 Artifact 不在任何環境運行
• 重大 Advisory、惡意套件、Builder 妥協與供應商中斷皆有演練過的 Playbook

Redmark 在軟體供應鏈安全中的角色

SBOM、SCA 與 Provenance 聚焦元件、來源與交付完整性；Redmark 的網站弱點掃描則從正在運行的 Web Application 與 API 攻擊面，持續檢查輸入處理、授權、設定與公開曝露。SCA 找到一個脆弱 Library，不代表該路徑一定可從網站利用；網站掃描沒有找到問題，也不代表相依套件、Builder 或發布流程可信。

成熟流程會把兩種證據整合：SCA／SBOM 提供受影響元件與 Dependency Path，Redmark 提供外部曝露與可觀察網站風險，資產系統補上 Owner 與業務情境。團隊完成依賴升級與重新部署後，再以新 SBOM 驗證元件已移除，並用網站弱點掃描複驗對外攻擊面，形成可關閉的完整證據鏈。