SBOM、CBOM 進化至 AIBOM：企業資安與 AI 透明化之關鍵

在當前軟體供應鏈日益複雜的環境下，企業必須能迅速掌握其應用程式與底層元件的完整組成，才能有效評估安全風險與合規性。Software Bill of Materials（SBOM）為此提供了結構化的清單，將開源、商業及內部開發元件以可追蹤的方式呈現。隨著雲端與容器化部署的普及，Component Bill of Materials（CBOM）進一步聚焦於容器內部的組件關係與相依性。當 AI 模型與推論服務成為核心產能時，AIBOM（AI Bill of Materials）則以模型檔、訓練資料、推論演算法等為主，協助組織掌握 AI 產品的完整生命週期。

技術背景

SBOM 最早由 NIST 推薦，並被多家政府機構列為安全最佳實踐。CBOM 的概念則源於容器化運作的需求，透過工具如 Syft 與 Grype 能自動掃描映像並產出元件清單。AIBOM 則受 AI 透明化與責任追蹤的推動，尤其在 AIoT 與智慧製造場景（如漢翔工業實現永續及智慧製造轉型的關鍵）中，模型與資料的可追蹤性成為合規與可靠性的關鍵。

攻擊與問題細節

缺乏完整的 SBOM 會讓漏洞掃描工具難以準確判斷影響範圍。以 GitLab 在 2025 年底發布的兩項高風險漏洞為例（GitLab修補兩高風險漏洞），漏洞涉及 CI/CD 快取憑證外洩與 DoS 弱點，若開發者無法即時取得元件清單，修補流程將被延遲。CBOM 能在容器化環境中快速定位受影響層，協助減少停機時間。AIBOM 的缺失則會導致 AI 模型訓練資料的來源與版本無法被驗證，進而影響模型可信度與合規性。

影響與風險

補丁延遲：無法即時識別受影響元件，導致安全補丁部署失敗或錯過。
合規風險：許多產業法規（如 PCI‑DSS、ISO 27001）要求完整的元件追蹤，缺失 SBOM/CBOM 可能導致合規不符。
AI 可信度：若 AIBOM 缺失，AI 系統的決策過程將缺乏透明度，難以滿足監管與客戶期望。

防護與建議

建立自動化 SBOM 生成流程：在 CI/CD pipeline 中加入 Syft、Trivy 等工具，確保每次建置都產出最新 SBOM。
推行 CBOM 規範於容器化環境：使用 Clair 或 Grype 進行容器映像掃描，並將 CBOM 版本控制於 Git。
實作 AIBOM 標準：在 AI 研發流程中加入模型訓練、資料集、推論 pipeline 的版本資訊，並以 JSON/YAML 形式存儲。
整合供應鏈管理平台：如 IBM Resilient、Red Hat Advanced Cluster Management，可集中管理 SBOM/CBOM/AIBOM，並自動匹配 CVE 資訊。
定期審核與更新：每個季度至少一次完整審查，確保所有元件均在安全範圍內且版本已更新。