コンプライアンスのエビデンスとしてのSBOM：ISO 27001、SOC 2、NIS2

エビデンスはコンプライアンスではない

管理策を満たすのは、機能しているプロセスです。エビデンスは、それが機能していることを示します。SBOMが示すのは、特定のリリースに何が含まれていたかという1点だけです。アクセス制御、インシデント対応、あるいは誰かが検出結果に対処したかどうかについては何も示しません。

しかも、誰も気づかない形で誤っていることがあります。間違ったファイルを読んだジェネレーターは、製品の半分が抜けた有効なSBOMを生成します。そのSBOMの脆弱性スキャンはクリーンで、コンプライアンスプラットフォームはスキャンが実行されたことを確認し、すべてのチェックが緑になります。SOC 2の緑のSBOMチェックが検証しているもので、この失敗を詳しく説明しています。

SBOMによるエビデンスが有効なのは、次の条件を満たす場合です。

1. リリースに結びついている。リポジトリに1つではなく、出荷したバージョンごとに1つのSBOM。
2. 完全であるか、欠落を明記している。欠落を明記したSBOMは、列挙している内容については信頼できます。
3. 監査対象期間にわたって保管されている。昨年3月をサンプリングする監査人には、昨年3月のSBOMが必要です。
4. 新たな脆弱性が現れたときに再確認される。新しいアドバイザリと誰も照合しないリストでは、脆弱性管理の証明にはほとんどなりません。

SBOMに含まれる内容についてはSBOMとはを、産業製品と米国連邦政府向けソフトウェアのセキュアな開発のフレームワークについてはIEC 62443-4-1とNIST SSDFをご覧ください。

ISO/IEC 27001:2022

ISO/IEC 27001は、情報セキュリティマネジメントシステムの認証の基準となる規格です（用語集）。附属書Aには93の管理策があり、組織はリスクアセスメントに基づいて必要なものを選び、適用宣言書（Statement of Applicability）に記録します。実装の手引きは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サプライチェーンに伴うリスクを管理する	方向は2つあります。購入者としては、サプライヤーに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件のアドバイザリについてのエビデンスの連鎖と、それぞれを誰が提供するかを示します。

ステップ	エビデンス	提供元
1. リリースの中身	バージョン4.2のSBOM。それを作成したビルドが記録したもの	ビルドツール
2. アドバイザリとの照合	そのSBOMに含まれるライブラリについて公開された新しいCVE。package URLで照合	脆弱性の監視
3. ばく露期間	脆弱なバージョンを含んでいたすべてのビルドと、最初のビルドの日付	ビルド履歴
4. 判断	誰がいつ評価したか、そして結果：修正、緩和、または影響なし。理由を添えて	自社のプロセスとその記録
5. 修正	バージョン4.2.1。そのSBOMには脆弱なバージョンが含まれていない	ビルドツール

ツールが提供できるのはステップ1、2、3、5です。ステップ4は自社のプロセスであり、監査人が最も注意深く読むステップです。

SOC 2

SOC 2報告書は、統制がAICPAのTrust Services Criteria（2017年、着眼点は2022年に改訂）を満たしているかを述べるものです。規準は成果を記述したもので、SBOMには言及していませんが、そのうち2つでSBOMが役立ちます。

• CC7.1は、事業体が検出と監視の手続きを用いて、(1)新たな脆弱性の混入につながる構成の変更と、(2)新たに発見された脆弱性に対する影響の受けやすさを特定することを求めています（英語原文の訳）。エビデンス：リリースごとのSBOMを新しいアドバイザリに照らして再評価したもの、そして各検出結果をどう処理したかの記録。
• CC8.1は変更管理を対象とし、インフラ、データ、ソフトウェア、手続きへの変更がどのように承認、開発または取得、テスト、承認、実装されるかを扱います。エビデンス：記録されたパイプラインでビルドされたすべてのリリース、ビルドごとに見える依存関係の変化、そして出荷してよいものを管理する統制としてのポリシーゲート。

規準は改訂中です。2026年10月、AICPAは2027年版Trust Services Criteriaの公開草案を発表しました。規準の的を絞った再構成を含み、意見募集の期限は2027年1月15日、提案されている適用開始は2027年12月31日以降に開始する業務です。これは草案であり、規準の番号は変わる可能性があります。新しい番号にエビデンスを対応づける前に、最終版を確認してください。

すでにSOC 2プラットフォームを使っているなら、そのまま使い続けてください。問題は、そのチェックの裏にあるSBOMが何を示しているかです。SOC 2のSBOMチェックの比較をご覧ください。

NIS2

NIS2 Directive (EU) 2022/2555は、指令が列挙するセクターの必須事業体と重要事業体に適用されます。ソフトウェアやデバイスのサプライヤーとしてこれを読んでいるなら、通常は自社自身は対象外です。対象は顧客であり、その義務が質問としてあなたに届きます。第21条はサイバーセキュリティのリスク管理措置を定めており、そうした質問の大半は次の3つの箇所から生じます（英語版からの訳）。

• 第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対象の顧客からの質問票

顧客がこれらの項目から導き出す種類の5つの質問と、サプライヤーが添付できるエビデンスです。ツールが保持する記録から得られる回答もあれば、自社で書くポリシーである回答もあります。

質問	添付するエビデンス	記録かポリシーか
「当社に納品する製品バージョンのソフトウェアコンポーネントを列挙してください。」（6.1.2(c)）	そのバージョンのSBOM。CycloneDXまたはSPDXで、完全性を明記したもの	記録
「脆弱性の処理とそのスケジュールを説明してください。」（5.1.4(f)）	深刻度レベルと目標時間を定めた脆弱性処理の手順	ポリシー
「当社が運用しているバージョンのうち、どれにいつから脆弱なライブラリが含まれていましたか？」（6.10）	そのコンポーネントを含んでいたすべてのビルドを日付とともに示すビルド履歴	記録
「このCVEが当社に影響しないのはなぜですか？」（6.10）	「脆弱なコードが存在しない」などの根拠を添えた「影響なし」の表明	自社の評価に基づく記録
「研究者が製品の脆弱性を報告するにはどうすればよいですか？」（5.1.2(a)）	協調された脆弱性開示のポリシー	ポリシー

区別しておくべき点が1つあります。EUで販売されるデジタル要素を含む製品については、Cyber Resilience Actが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条を満たす助けになります。

すべてを1つにまとめたエビデンスマップ

行はエビデンスの種類です。各セルには、それが裏づける管理策、規準、項目、または「直接にはなし」を示します。

エビデンス	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. ビルドのegressポリシーとネットワークの記録	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、ネットワークトレース、来歴データを返します。egressポリシーは、各ビルドの接続先を記録し、制限します。

CRACIはこれらの管理策のエビデンスを提供します。ISO 27001やSOC 2に準拠させたり、NIS2への対応を完了させたりするものではなく、コンプライアンス自動化プラットフォームでもありません。CRACI自身の認証は別の事実です。CRACI Corporation OyのCRACIプラットフォームの開発と運用に関する情報セキュリティマネジメントシステムは、Into CertificationによりISO/IEC 27001の認証を受けています。対象はCRACIのサービス運営であり、あなたの組織や製品ではありません。CRACIのセキュリティと、プラットフォーム全体についてはCRACIの仕組みをご覧ください。

CRACIが適さない場合

• ビルドがGitHub Actionsで実行されていない。現在CRACIが対応しているCIはGitHub Actionsのみで、ほかの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)はサプライチェーンのセキュリティを、第21条第2項(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のエビデンスとして十分ですか？

いいえ。SBOMが示すのは各リリースの中身です。管理策8.8には、脆弱性の情報を入手し、ばく露を評価し、対処していることのエビデンスも必要です。SBOMに、継続的な再評価、影響を受けたリリースの記録、下した判断を組み合わせてください。

準拠していることとエビデンスがあることの違いは何ですか？

準拠とは、監査人や顧客の判断において、自社のプロセスがフレームワークの要件を満たしていることです。エビデンスは、そのプロセスが機能していることを示すものです。SBOMはいくつかの管理策のエビデンスになりますが、それによってどのフレームワークにも準拠することにはなりません。