SBOM
以 SBOM 作為法規遵循佐證資料：ISO 27001、SOC 2 與 NIS2
它們都沒有要求 SBOM。ISO/IEC 27001:2022、SOC 2 Trust Services Criteria 與 NIS2 要求的是資產清冊、供應鏈安全、漏洞管理與安全開發，並將方法交由您決定。當 SBOM 完整且依版本保存時，搭配其背後的建置紀錄，就是這些控制項的有力佐證資料。本指南逐一對照各控制項，並說明它的極限在哪裡。
更新日期
佐證資料不等於合規
控制項是由實際運作的流程來滿足的，佐證資料則用來證明它確實運作。SBOM 只證明一件特定的事：某個版本包含了什麼。它無法證明存取控制、事件應變，或是否有人針對發現結果採取行動。
它也可能以沒有人察覺的方式出錯。讀錯檔案的產生工具會產出一份格式有效、卻遺漏了半個產品的 SBOM。針對這份 SBOM 的漏洞掃描結果乾淨，法規遵循平台看到掃描已執行，每項檢查都顯示綠燈。SOC 2 SBOM 檢查顯示綠燈時驗證了什麼詳細說明了這種失誤。
SBOM 的佐證資料在以下情況才算數：
- 與版本綁定。每個您交付的版本各有一份 SBOM，而不是整個儲存庫一份。
- 完整，或說明遺漏了什麼。能說明自身缺口的 SBOM，其所列內容才值得信任。
- 保存期間涵蓋稽核期間。抽查去年三月的稽核人員，需要的是去年三月的 SBOM。
- 在新漏洞出現時重新檢查。沒有人拿來比對新資安公告的清單，幾乎無法證明漏洞管理的成效。
SBOM 包含哪些內容，請參閱什麼是 SBOM。工業產品與美國聯邦軟體的安全開發框架，請參閱 IEC 62443-4-1 與 NIST SSDF。
ISO/IEC 27001:2022
ISO/IEC 27001 是資訊安全管理系統取得驗證所依據的標準（術語表）。附錄 A 列出 93 項控制項；組織依風險評鑑選出所需的控制項，並記錄在適用性聲明書中。ISO/IEC 27002:2022 提供實作指引。兩者都沒有提到 SBOM。下表僅引用控制項標題，並簡述各控制項的重點。
| 控制項 | 重點 | SBOM 或建置紀錄如何作為佐證資料 | 未涵蓋的範圍 |
|---|---|---|---|
| 5.9「Inventory of information and other associated assets」 | 掌握您擁有哪些資產，以及資產的負責人 | 您交付與運作的軟體就是資產。每個版本的元件清單，就是其內容的資產清冊。 | 硬體、資料、人員與服務 |
| 5.19「Information security in supplier relationships」、5.20「Addressing information security within supplier agreements」、5.21「Managing information security in the ICT supply chain」、5.22「Monitoring, review and change management of supplier services」 | 管理供應商與 ICT 供應鏈帶來的風險 | 有兩個方向。身為買方，您可以要求供應商提供 SBOM 並加以監控。身為供應商，您的 SBOM 正是已取得驗證之客戶在供應鏈流程中向您索取的資料。開源元件屬於 ICT 供應鏈的一部分，卻沒有任何供應商協議，這正是為它們建立資產清冊之所以重要的原因。 | 合約、供應商評估與審查 |
| 8.8「Management of technical vulnerabilities」 | 取得漏洞資訊、評估暴露程度並採取行動 | 一份與資安公告比對、並在新公告出現時重新評估的最新元件清單，加上哪些版本自何時起包含有漏洞版本的紀錄 | 修補您的基礎架構、掃描主機，以及決策本身 |
| 8.25「Secure development life cycle」 | 安全開發軟體與系統的規則 | 有紀錄、可重複的發布流程：每個版本都在同一條管線中建置，並附有 SBOM | 此控制項的大部分內容：訓練、環境、設計與審查 |
| 8.26「Application security requirements」、8.27「Secure system architecture and engineering principles」、8.28「Secure coding」 | 需求、設計與程式碼 | 無直接關聯。這些控制項關注的是您撰寫的內容，而不是您引入的內容。 | 全部：此處的佐證資料是程式碼審查、SAST 與設計紀錄 |
| 8.29「Security testing in development and acceptance」 | 在發布前測試安全性 | 依據漏洞發現封鎖建置的政策關卡，就是一項有結果紀錄的測試 | 功能性安全測試、滲透測試 |
| 8.30「Outsourced development」 | 指導並監控委外開發 | 在您的管線中建置的委外程式碼，會獲得與您自有程式碼相同的 SBOM 與檢查 | 合約，以及供應商本身的實務做法 |
對 8.25 到 8.30 請誠實以對：這些控制項要求的大部分內容都在 SBOM 範圍之外。宣稱超出實際的範圍，是讓稽核人員不再信任其餘內容的最快方式。
實例：稽核人員詢問 8.8
「當新漏洞影響到您已交付的產品時，您如何得知？」以下是針對一則資安公告的佐證資料鏈，以及每個環節由誰提供。
| 步驟 | 佐證資料 | 來源 |
|---|---|---|
| 1. 版本的內容 | 4.2 版的 SBOM，由產生該版本的建置所記錄 | 您的建置工具 |
| 2. 資安公告比對 | 該 SBOM 中某個函式庫有新公布的 CVE，以其套件 URL 比對 | 您的漏洞監控 |
| 3. 暴露期間 | 所有包含該有漏洞版本的建置，以及第一次出現的日期 | 您的建置歷史 |
| 4. 決策 | 由誰、在何時評估，以及結果：修正、緩解或未受影響，並附上理由 | 您的流程及其紀錄 |
| 5. 修正 | 4.2.1 版，其 SBOM 已不再包含有漏洞的版本 | 您的建置工具 |
工具可以提供步驟 1、2、3 與 5。步驟 4 是您的流程，也是稽核人員看得最仔細的步驟。
SOC 2
SOC 2 報告說明控制措施是否符合 AICPA 的 Trust Services Criteria（2017 年版，重點項目於 2022 年修訂）。這些準則是結果導向的陳述，沒有提到 SBOM，而其中兩項是 SBOM 能派上用場之處。
- CC7.1 要求組織「運用偵測與監控程序，識別 (1) 導致新漏洞產生的設定變更，以及 (2) 對新發現漏洞的易受影響性」（譯自英文原文）。佐證資料：每個版本的 SBOM，並依據新資安公告重新評估，以及每項發現如何處理的紀錄。
- CC8.1 涵蓋變更管理：基礎架構、資料、軟體與程序的變更如何經過授權、開發或取得、測試、核准與實施。佐證資料：每個版本都在有紀錄的管線中建置、從一次建置到下一次建置的相依套件變化清楚可見，以及作為「可交付內容」控制手段的政策關卡。
這些準則正在修訂中。AICPA 於 2026 年 10 月發布 2027 年版 Trust Services Criteria 的徵詢草案，對準則進行針對性的重新架構，意見徵詢截止日為 2027 年 1 月 15 日，擬議生效日為 2027 年 12 月 31 日當日或之後開始的查核案件。它仍是草案，準則編號可能變動：將佐證資料對應到新編號之前，請先確認最終版本。
如果您已經在使用 SOC 2 平台，請繼續使用。問題在於其檢查背後的 SBOM 顯示了什麼： SOC 2 SBOM 檢查比較。
NIS2
NIS2 Directive (EU) 2022/2555 適用於其所列產業中的基要實體與重要實體。如果您是以軟體或裝置供應商的身分閱讀本文，您本身通常不在適用範圍內。適用的是您的客戶，而其義務會以問題的形式傳到您手上。第 21 條規定了資安風險管理措施，其中三段文字引發了大部分的問題（譯自英文版本）：
- 第 21 條第 2 項 (d) 款：「供應鏈安全，包含各實體與其直接供應商或服務提供者之間關係的安全相關面向」。
- 第 21 條第 2 項 (e) 款：「網路與資訊系統取得、開發與維護的安全，包含漏洞處理與揭露」。
- 第 21 條第 3 項：實體必須考量「各直接供應商與服務提供者特有的漏洞，以及其供應商與服務提供者的產品與資安實務的整體品質，包含其安全開發程序」。正是這句話，變成了您桌上的問卷。
Implementing Regulation (EU) 2024/2690
2024 年 10 月 17 日的 Commission Implementing Regulation (EU) 2024/2690，針對 DNS 服務提供者、TLD 名稱註冊管理機構、雲端運算服務提供者、資料中心服務提供者、內容傳遞網路提供者、代管服務提供者、代管資安服務提供者、線上市集、線上搜尋引擎、社群網路平台與信任服務提供者，規定了第 21 條第 2 項各項措施的技術與方法要求。它不拘束其他 NIS2 產業，但它是「供應鏈安全」意涵最詳盡的公開說明，其他買方也會借用其內容。與供應商相關的項目如下（譯自英文版本）：
| 附件中的項目 | 內容 | 供應商會被問到什麼 |
|---|---|---|
| 5.1.2(a) | 選擇供應商時須考量「供應商與服務提供者的資安實務，包含其安全開發程序」 | 您如何進行安全開發？又如何知道產品中包含了什麼？ |
| 5.1.4(e) 與 (f) | 合約在適當情況下應明定稽核或取得稽核報告的權利，以及「供應商與服務提供者處理對實體構成風險之漏洞的義務」 | 您會處理所交付內容中的漏洞嗎？我們能看到佐證資料嗎？ |
| 5.2 | 直接供應商登記冊，並附上各供應商所提供的「ICT 產品、ICT 服務與 ICT 流程清單」 | 您提供給我們哪些產品與版本？ |
| 6.1.2(c) | 取得 ICT 服務或 ICT 產品時：「描述 ICT 服務或 ICT 產品中所使用之硬體與軟體元件的資訊」 | 您的產品包含哪些硬體與軟體元件？這是本頁所有條文中最接近 SBOM 的一項，但仍未提到 SBOM。 |
| 6.10 | 漏洞處理：透過 CSIRT 公告或「供應商或服務提供者提供的資訊」等管道監控漏洞資訊（6.10.2(a)），而當漏洞不需修補時，應「記錄並證明其理由」（6.10.3） | 您會如何告知我們漏洞資訊？為什麼這個漏洞不構成問題？ |
最後一項描述的是附帶理由的未受影響聲明。這正是 VEX 文件所承載的內容，儘管該法規並未指定格式。
實例：來自 NIS2 客戶的問卷
以下是客戶依據上述項目所衍生的五個典型問題，以及供應商可以附上的佐證資料。有些答案來自工具保存的紀錄，有些則是您撰寫的政策。
| 問題 | 應附上的佐證資料 | 紀錄或政策 |
|---|---|---|
| 「請列出您交付給我們之產品版本中的軟體元件。」（6.1.2(c)） | 該版本的 SBOM，格式為 CycloneDX 或 SPDX，並標示其完整性 | 紀錄 |
| 「請說明您的漏洞處理方式及其時程。」（5.1.4(f)） | 您的漏洞處理程序，包含嚴重性等級與目標時間 | 政策 |
| 「我們執行的版本中，哪些包含有漏洞的函式庫？又是從何時開始？」（6.10） | 顯示所有包含該元件之建置及其日期的建置歷史 | 紀錄 |
| 「為什麼這個 CVE 不會影響我們？」（6.10） | 附上理由的未受影響聲明，例如「有漏洞的程式碼不存在」 | 紀錄，依據您的評估 |
| 「研究人員要如何通報您產品中的漏洞？」（5.1.2(a)） | 您的協同漏洞揭露政策 | 政策 |
有一項區別要記住：對於在歐盟銷售的具數位元素產品， Cyber Resilience Act（CRA）確實要求 SBOM。NIS2 則沒有。
DORA：若您的客戶是金融機構
Digital Operational Resilience Act， Regulation (EU) 2022/2554 適用於金融機構，而不直接適用於其供應商。金融機構必須識別並記錄其 ICT 資產及其相互依存關係，並保存資產清冊（第 8 條第 1 項、第 4 項與第 6 項），將 ICT 第三方風險納入其 ICT 風險管理（第 28 條第 1 項），保存所有 ICT 服務合約的資訊登記冊（第 28 條第 3 項），並在這些合約中納入最低規定（第 30 條）。 DORA 沒有提到 SBOM。對於提供軟體給銀行的供應商而言，每個版本的元件清單有助於客戶符合第 8 條的要求。
涵蓋所有框架的單一佐證資料對照表
每一列是一項佐證資料；每個儲存格列出它所支援的控制項、準則或項目，或標示「無直接關聯」。
| 佐證資料 | ISO/IEC 27001:2022 | SOC 2 | NIS2 與 2024/2690 | DORA |
|---|---|---|---|---|
| 1. 每個版本的 SBOM，並標示其完整性 | 5.9、5.21、8.8 | CC7.1 | 第 21 條第 2 項 (d) 款；6.1.2(c) | 第 8 條（客戶的資產清冊） |
| 2. 依據新資安公告持續重新評估 | 8.8 | CC7.1 | 第 21 條第 2 項 (e) 款；6.10 | 無直接關聯 |
| 3. 建置歷史：哪些版本自何時起包含某個元件 | 8.8 | CC7.1、CC8.1 | 6.10 | 無直接關聯 |
| 4. 分級研判與分派紀錄 | 8.8 | CC7.1 | 第 21 條第 2 項 (e) 款；6.10 | 無直接關聯 |
| 5. 附理由的未受影響聲明 | 8.8 | CC7.1 | 6.10 | 無直接關聯 |
| 6. 封鎖建置的政策關卡 | 8.25、8.29 | CC8.1 | 第 21 條第 2 項 (e) 款 | 無直接關聯 |
| 7. 與自有 SBOM 一起監控的供應商 SBOM | 5.19、5.21、5.22 | CC7.1 | 第 21 條第 2 項 (d) 款、第 21 條第 3 項；5.2、6.10 | 第 28 條第 1 項 |
| 8. 建置的對外連線政策與網路紀錄 | 8.25 | CC8.1 | 第 21 條第 2 項 (d) 款 | 無直接關聯 |
SBOM 無法證明的事項
- 您的存取控制、事件應變、營運持續、人力資源安全、密碼學或實體安全。
- 有人修正了任何問題。那是您的流程及其紀錄。
- 您自己的程式碼沒有缺陷。這方面的佐證資料是程式碼審查、SAST 與測試。
- 您收到的、沒有附 SBOM 之二進位檔的內部內容。
- 您已取得驗證。SBOM 不是證書，而工具廠商持有的證書，驗證的是該廠商自己的管理系統，而不是您。
CRACI 的定位
CRACI 取代您的 GitHub 託管執行器，並記錄每次建置引入的內容，因此 SBOM 直接來自版本發布的建置本身，並為每個作業標示完整性狀態。
- 受監控的 SBOM 會在新漏洞公布時持續重新評估 （漏洞追蹤）。
- 建置歷史會在您的保存期間內，顯示哪些建置包含有漏洞的相依套件，進而顯示您暴露於風險的期間。如果您的稽核涵蓋更長的期間，請匯出每個版本的 SBOM，並與該版本一起保存。
- 資安團隊分級研判所發現的漏洞，並將其送交負責修正的團隊；CRACI 也支援 VEX，用於記錄漏洞未影響哪些產品。
- 政策關卡可以依據發現結果封鎖建置，包含含有特定 CVE 的建置。
- 可以加入第三方 SBOM，讓外購元件與您自己的建置一起受到監控。
- SBOM 可匯出為 CycloneDX 或 SPDX，API 則提供 SBOM、網路追蹤紀錄與來源證明資料。對外連線政策會記錄並限制每次建置可連線的對象。
CRACI 為這些控制項提供佐證資料。它不會讓您符合 ISO 27001 或 SOC 2，也不會讓您做好 NIS2 的準備，而且它不是法規遵循自動化平台。CRACI 自身的證書是另一回事：CRACI Corporation Oy 針對 CRACI 平台開發與營運的資訊安全管理系統，已取得 ISO/IEC 27001 驗證，由 Into Certification 核發。它涵蓋的是 CRACI 如何營運其服務，而不是您的組織或產品。請參閱 CRACI 的資安，並透過CRACI 的運作方式了解整個平台。
何時 CRACI 不是答案
- 您的建置不是在 GitHub Actions 上執行。這是 CRACI 目前唯一支援的 CI；其他 CI 系統已列入產品藍圖。
- 您需要用於政策、存取審查與稽核流程的法規遵循自動化平台。請保留或購買一套；請參閱 SOC 2 SBOM 檢查比較。
- 您的佐證資料缺口主要在組織面：政策、訓練、事件應變。
- 您主要的供應商風險是收到沒有附 SBOM 的二進位檔。這要靠二進位分析來解決。
正在回應某位客戶的要求嗎？請參閱如何回應客戶的 SBOM 要求、 元件供應商指南，以及 您的客戶會使用的檢查清單。
以 SBOM 作為法規遵循佐證資料：常見問題
ISO 27001 要求 SBOM 嗎？
不要求。ISO/IEC 27001:2022 沒有提到 SBOM。附錄 A 的控制項 5.9（資產清冊）、5.21（ICT 供應鏈）與 8.8（技術漏洞）要求的成果都能由 SBOM 支援，而佐證資料是否足夠，由組織及其稽核人員決定。
SOC 2 要求 SBOM 嗎？
不要求。Trust Services Criteria 是結果導向的陳述，沒有提到 SBOM。每個版本的 SBOM 依據新資安公告重新評估，就是 CC7.1 的佐證資料，而有紀錄的建置管線則支援關於變更管理的 CC8.1。
NIS2 要求 SBOM 嗎？
不要求。第 21 條第 2 項 (d) 款要求供應鏈安全，(e) 款要求漏洞處理，但都沒有提到 SBOM。適用於特定數位服務提供者的 Implementing Regulation (EU) 2024/2690，在 6.1.2(c) 項中要求提供 ICT 產品之硬體與軟體元件的資訊，但仍未使用 SBOM 一詞。
SBOM 支援哪些 ISO 27001 附錄 A 控制項？
主要是 5.9（資訊及其他相關資產的清冊）、5.19 到 5.22（供應商與 ICT 供應鏈）以及 8.8（技術漏洞管理）。建置紀錄則部分涉及 8.25、8.29 與 8.30。8.26 到 8.28 關注需求、設計與程式碼，不在 SBOM 範圍內。
NIS2 客戶會向軟體供應商要求什麼？
通常包括安全開發的說明、所交付版本中的元件、處理漏洞的承諾、接收漏洞資訊的管道，以及漏洞不適用時的理由。這些問題來自第 21 條第 3 項，對某些產業而言，也來自 Implementing Regulation 2024/2690 中與供應商相關的項目。
SBOM 足以作為 ISO 27001 控制項 8.8 的佐證資料嗎？
不足以。它顯示每個版本包含什麼。控制項 8.8 還需要證明您取得漏洞資訊、評估暴露程度並採取行動。請將 SBOM 搭配持續重新評估、受影響版本的紀錄，以及您所做的決策。
合規與擁有佐證資料有什麼不同？
合規是指您的流程符合框架要求，由稽核人員或客戶判定。佐證資料則用來證明這些流程確實運作。SBOM 是少數幾項控制項的佐證資料，它不會讓您符合任何框架。