2026年7月29日、CISAは 「2026年サイバーセキュリティ基準」を公表した。Software Bill of Materials (SBOM)」を公表し、2021年から適用されていたNTIAのベースラインに取って代わった。これは、NSA、FBI、および15の国際的なサイバーセキュリティ機関と共同で作成されたものである。
「2026年版 ソフトウェア構成管理（Software ）の必須要素（Bill of Materials (SBOM) ）」は、SBOMにどのようなデータを含めるべきかについてCISAが更新した仕様であり、最も重要な変更点は数値的なものではなく構造的なものです。2026年版の要素では、ソースマニフェストから生成されたSBOMを禁止してはいませんが、作成者に対して、SBOMの生成方法を宣言すること、実行可能アーティファクトのハッシュ値を算出すること、および入力できなかった各フィールドにラベルを付けることを義務付けています。 マニフェストのみから構成されるSBOMは、現在、その欠落部分を機械可読形式で開示するようになっています。
MetaDefender Software Supply Chain OPSWAT のソフトウェア・サプライチェーン・セキュリティ・プラットフォームであり、アーティファクト、バイナリ、コンテナイメージのレイヤーを分析するように設計されています。これらはまさに、新たに導入されたハッシュ、生成コンテキスト、およびカバレッジに関する要件で求められるデータカテゴリそのものです。
概要
- 17のデータフィールド— SBOMメタデータ 9項目、コンポーネントデータ 8項目
- 6つの実践とプロセス
- 新規フィールド10項目、主要な更新8件、削除1件（「アクセス制御」は「流通・配送」に統合されました）
- 「オープンソースソフトウェア、AIソフトウェア、SaaSを含む」すべてのソフトウェアに適用されます。
- 新たな要件ではなく、組織によるSBOMの作成および要求方法の改良
2026年のSBOM変更点のうち、ソースコードのみのSBOMが対応するのが最も困難な点
1. コンポーネントのハッシュ値には、実行可能アーティファクトが必要です
「コンポーネントのハッシュ値」および「コンポーネントのハッシュアルゴリズム」は、ハッシュの対象を具体的に定めています。それは、「実行可能コンポーネント・アーティファクトに暗号ハッシュアルゴリズムを適用して生成された出力」です。マニフェストのエントリでも、宣言されたバージョン文字列でもありません。
- package-lock.json、pom.xml、または requirements.txt を読み込むパーサーは、実行可能アーティファクトには一切アクセスしないため、両方のハッシュフィールドは「不明」を返します。
- ハッシュが存在する場合、アルゴリズムは以下を使用しなければならない IANAハッシュ関数のテキスト名 を採用し、NISTなどの機関によって承認されているものでなければならない
- ハッシュ値があるからこそ、受取人は、記載されたコンポーネントが出荷されたコンポーネントそのものであることを確認できるのです
2. SBOM生成の背景により、この手法が記録の一部となる
SBOM生成のコンテキストは、最も目立たない追加項目であると同時に、構造的に最も重要な要素です。「SBOM作成者がSBOMを生成した時点で、ソフトウェアライフサイクルのどの段階にあり、どのようなデータが利用可能であったか」を指します。CISAは、「ビルド前」、「ビルド中」、「ビルド後」の3つの値を定義しており、それぞれをSBOMの生成方法と関連付けています。ソースコードから抽出されたSBOMは最も早い段階に分類されるのに対し、バイナリ解析ツールによって生成されたSBOMは最も遅い段階に分類されます。
- 調達チームは、どのライフサイクル段階のSBOMを受け入れるかを指定することができ、ソースレベルのSBOMよりも、コンパイル済みアーティファクトから抽出されたSBOMを優先することができます。
- 脆弱性管理プラットフォームは、指定されたコンテキストに基づいて検出結果を重み付けすることができます
- ソース由来のSBOMは引き続き認められますが、完成したバイナリから生成されたSBOMと同等であるとして提示することはできなくなりました。
3. 網羅性が深さに取って代わり、下限は設けられない
2021年の「深度」要件では、トップレベルの依存関係のみが求められていました。CISAは現在、この定義について、「情報に基づいたセキュリティ上の意思決定を行うために必要な情報の深度ではなく、当時のSBOMツールの機能水準を反映したものだった」と述べています。今回の要件では、対象範囲がより厳格化されており、「ターゲットソフトウェアを構成するすべてのコンポーネント（推移的な依存関係を含む）を対象とする。深度に関する下限は設けられていない」とされています。
このテストは機能的です。受領者は、「SBOMにその脆弱性に関連するコンポーネントが記載されていない場合、新たに報告された脆弱性が自分には影響しないという結論を導き出せるはず」です。記載がないことが証拠となるのは、カバレッジが十分に網羅されている場合にのみ成り立ちます。マニフェストの解析だけでは、以下の点においてその基準を満たすことは難しいと考えられます：
- 静的リンクおよびベンダーコード— マニフェストエントリは生成されない
- CおよびC++プロジェクト— ビルド時に取り込まれるDLLや共有オブジェクトを追跡する汎用的なパッケージマネージャーは存在しない
- コピーされたソースコード— CISAはこれを「実質的には、フォークおよび依存関係として追跡した方が適切な依存関係である」と説明している
- Container イメージレイヤー— マニフェストで宣言されるのではなく、layer コマンドによってインストールされるパッケージ
これまで不明だった情報は、今後申告しなければならない
- 著者は、自身が知らない情報と、意図的に隠された情報とを区別すべきである。
- 著者は、編集処理が施されたセキュリティ関連の内容について、受領者が問い合わせを行える仕組みを維持することが推奨されます。
- 「SBOMの作成者が重要なコンポーネントのデータを開示しない場合、組織は当該SBOMを不完全であるとみなす可能性がある」
- 「誤りの許容」は、「受領者はSBOMデータの正確性を期待できる」という根拠に基づき置き換えられた――「不適切なツールの選択」に起因する誤りは、現在では受領者のリスク評価における正当な考慮事項となっている
CISAが2026年版SBOM要素に加えたその他の変更点
変更 | 概要 | その重要性 |
SBOM作成者の署名（新機能） | SBOMの作成者に紐付けられたデジタル署名 | 受信者が、SBOMが本物であり、署名後に改ざんされていないことを確認できるようにします |
コンポーネントライセンス（新規） | 各コンポーネントのライセンス | 著作権およびコンプライアンス上のリスクを指摘；CISAがSPDXライセンスIDを提示 |
機械処理可能なデータ（旧称：自動化サポート） | SPDX および CycloneDX のみ | SWIDは広く使用されていないため除外され、許容される形式が2つに絞られた |
部品メーカー（旧：サプライヤー名） | コンポーネントごとに1つの組織名を指定 | ソースが不明な場合に、明示的な「出所不明」のフォールバックを追加します |
頻度（更新済み） | 変更されたコンポーネントを取り込んだ、すべてのバージョン、アップデート、およびビルドごとに新しいSBOMが生成される | そのリズムを手作業で維持するのは難しいため、各チームは自動生成へと向かざるを得ない |
ビルド後のギャップを埋める
2026年の更新では、SBOMツールが十分に成熟し、さらなる機能を求める段階に至ったというCISAの評価が反映されており、同機関が現在期待している情報は、ビルドの「その先」にあるものとされています。
MetaDefender™Software Supply Chain は、ビルドされたアーティファクトから直接SBOMデータを生成します：
- 依存関係ファイルだけでなく、アーティファクト、バイナリ、コンテナイメージのレイヤーもスキャンします
- C、C++、およびC#のバイナリを、 ポータブル・エグゼキュータブル（PE）のメタデータおよび署名に基づく識別
- CycloneDXおよびSPDXでSBOMを生成し、また既存のレポートを充実させ、以前のスキャンで見逃されていたコンポーネントやCVEを明らかにします
- GHSA、CVE、EUVDを参照し、基準を満たさないライセンスにフラグを立てる
- CI/CDパイプラインやJFrog Artifactoryなどのアーティファクトレジストリと連携するため、各ビルドに合わせてSBOMを生成できます
MetaDefender 、Software 、Supply Chain が、開発ライフサイクル全体にわたる SBOM 要件をどのようにサポートできるかについては、以下をご覧ください：
よくあるご質問
CISA 2026のSBOM必須要素にはどのような変更があったのでしょうか？
今回の更新では、10個の新しいデータフィールドが追加され、8箇所の大幅な改訂が行われ、1つの要素が削除されました。最も重要な構造上の変更は、「Depth」が「Coverage」に置き換えられたことであり、「コンポーネントハッシュ値」、「SBOM生成コンテキスト」、「SBOM作成者署名」などの新しいフィールドが追加されたことで、SBOMデータの作成および検証方法に対する期待が高まっています。
CISA 2026のSBOMの必須要素は義務付けられているのでしょうか？
いいえ。CISAは、コンプライアンスの期限や執行メカニズムを定めておらず、同文書は「コンプライアンス、規制、または法的目的のための助言を構成するものではない」と明記しています。実質的な拘束力は、調達要件や、EUサイバーレジリエンス法など、SBOMのベースラインを参照する規制によって生じます。
CISA 2026のSBOM必須要素には、バイナリ分析またはビルド後の分析が必要ですか？
明示的にはそうではありません。ただし、「コンポーネントのハッシュ値」には実行可能アーティファクトへのアクセスが必要であり、「SBOM生成コンテキスト」では作成者がライフサイクルフェーズを宣言する必要があり、未入力のフィールドには「不明」とラベル付けしなければなりません。したがって、ソースコードのみのSBOMは、その不備を明記しつつ、フォーマット要件を満たすことになります。
CISA 2026の最低要件は、AIソフトウェアやSaaSにも適用されますか？
はい。適用範囲は、オープンソース、AI、SaaSを含むすべてのソフトウェアを対象としています。CISAは、これらのカテゴリーについては追加の要素が必要となる可能性があることを指摘していますが、ここではそれらを定義しておらず、代わりに2026年5月に公表されたAI向けのSBOMに関するG7共同ガイダンスを参照しています。
CISA 2026の必須要素では、どのようなSBOM形式が受け入れられていますか？
SPDXとCycloneDXは、SBOMの生成および利用に広く使用されている2つのフォーマットとして挙げられています。SWIDタグは、「広く使用されており、複数のツールが存在するSBOMデータフォーマットではない」として除外されました。どのフォーマットであっても、非推奨となったバージョンは新しいソフトウェアには使用すべきではありません。
