CISAのサイバーセキュリティ指針、SBOMの基準を引き上げるも、より良いインベントリだけではセキュリティギャップは残る

CISAのサイバーセキュリティ指針は、組織がSBOMを効果的に活用できるかどうかへの根強い疑念があるなかで、ソフトウェア部品表に関する5年前の連邦基準を置き換えた。

Cybersecurity and Infrastructure Security Agencyは、National Security Agency、Federal Bureau of Investigation、および国際パートナーとともに、「2026 Minimum Elements for a Software Bill of Materials」を公表した。この指針は、2021年にNational Telecommunications and Information Administrationが公表したフレームワークを更新するものだ。

SBOM（software bill of materials）は、ソフトウェア製品に含まれるコンポーネントとその関係を機械可読形式で一覧化したものだ。新たに公表された脆弱性が、自社のアプリケーションやインフラのどこかに存在するかどうかを組織が把握するのに役立つ。

この置き換えが重要なのは、2021年のフレームワークが、SBOMツールの主な関心がインベントリ生成にあった時期に策定されたためだ。現在のシステムは、開発パイプラインや顧客環境をまたいで、これらのインベントリを交換、統合、検証、分析している。

この変化は、新指針の根底にある中心的な緊張関係を生み出す。CISAは機械処理可能な、より豊富で一貫性のあるデータを求めているが、フィールドを追加しても、出来上がるインベントリが完全かつ実用的になるとは限らない。

当初のNTIA基準は、共通の語彙を確立する助けとなった。新たなCISAのサイバーセキュリティフレームワークは、ソフトウェアの生産者と利用者に対し、SBOMを静的なコンプライアンス文書ではなく、運用上のセキュリティデータとして扱うよう求めている。

CISAのサイバーセキュリティ指針、2021年のSBOM基準を置き換え

最も重要な変化は制度面と運用面にある。CISAが、日常的なソフトウェアリスク管理を目的とする、より包括的な基準を担うことになった。

NTIAはExecutive Order 14028を受け、2021年7月12日に当初の最小要件を公表した。そのフレームワークは、許容されるSBOMを、データフィールド、自動化のサポート、慣行とプロセスという3つのカテゴリに分類していた。

当初の7つのデータフィールドは、供給者名、コンポーネント名、バージョン、一意の識別子、依存関係、SBOM作成者、タイムスタンプを対象としていた。自動化要件は機械可読形式を推奨し、運用上の慣行は生成頻度、配布、アクセス、深さ、既知のギャップを扱っていた。

これらの要素は意図的に控えめなものだった。多くの供給者がSBOMを一度も生成したことのない時代に、最小限で有用なインベントリを定義したのである。

2026年のリリースは、このフレームワークを更新・置換するものだ。CISAが2025年8月に開始し、2025年10月3日に締め切ったパブリックコンサルテーションを踏まえている。

パブリックコメントの告知では、SBOMツールが生成を超え、共有、分析、管理へと拡大したと述べられている。また、オープンソースコミュニティ、政府機関、追加の業界からの参加拡大も指摘した。

CISAは、この指針によって拘束力のある連邦調達規則を新設したわけではない。最小要件は、実用的なSBOMを生成・要求するための基準であり、新たな法令や普遍的な義務ではない。

この区別はベンダーにとって重要だ。顧客は契約や調達プロセスでこのフレームワークを採用できるが、公開文書だけで、すべてのソフトウェア企業がSBOMの作成を強制されるわけではない。

ただし、想定される適用範囲は広い。このフレームワークは、オープンソースコンポーネント、software as a service、人工知能を含むソフトウェアを含め、政府機関が取得または開発するソフトウェアに適用できる。

CISAも、複雑なサービスでは一般的な最小要件を超える情報が必要となり得ることを認めている。SaaSプラットフォームは継続的に変化し、AIシステムは従来のパッケージとは異なるモデル、データセット、フレームワーク、外部サービスに依存する場合がある。

2026年に公表されたAI特化の別途指針は、こうした相違の一部に対応している。これらの専門的なインベントリの基盤としては、一般的なSBOM最小要件が引き続き出発点となる。

したがって各機関は、あり得るすべてのソフトウェアサプライチェーンを記述するのではなく、共通の最低ラインを定めている。組織には依然として、自らのアーキテクチャ、リスク、規制上の義務に合ったポリシーが必要だ。

これは、フィールドのリストが長くなったこと以上に重大な転換である。SBOMに関する議論を、文書の定義から、ソフトウェア構成に関する共有証拠の継続的な維持へと移すものだ。

新たな最小要件は、より多くの文脈を求める

セキュリティチームがパッケージを見分け、アーティファクトを検証し、ツール間で検出結果を結び付けなければならない状況では、コンポーネント名とバージョンだけでは足りない。

2026年の基準は、NTIAが確立した3部構成を維持している。引き続き、データフィールド、機械処理可能な形式、SBOMの作成・更新・交換に用いる慣行を対象とする。

ただし更新モデルでは、ソフトウェア自体とインベントリそのものの双方について、より豊かな文脈が求められる。策定プロセスでは、コンポーネントハッシュ、ライセンス情報、ツール識別、生成コンテキストという4つの追加が強調された。

コンポーネントハッシュは、ソフトウェアの内容から計算される暗号学的な値だ。名前とバージョンが同じでも、バイト列が異なるアーティファクトを利用者が区別する助けになる。

この区別は、ベンダーがパッケージを再ビルドしたり、非公開のパッチを適用したり、プラットフォーム固有のバイナリを配布したりする場合に重要になる。実際のアーティファクトが異なっていても、バージョン文字列は変わらないことがある。

ただしハッシュは、普遍的な識別システムではない。結果は、どのオブジェクトをハッシュ化するか、そのオブジェクトが圧縮されているか、ビルドプロセスがファイルをどのようにパッケージ化するかに左右される。

Business Software Allianceは、コンサルテーションの際にこの問題を提起した。同団体の業界回答は、ハッシュが有用な検証を提供し得る一方、アーカイブ、展開済みファイル、ファームウェア、その他のソフトウェア形態について、より明確な定義が必要だと主張している。

ライセンス情報は別の側面を加える。オープンソースおよびプロプライエタリな依存関係を含め、コンポーネントに関連する条件を組織が特定するのに役立つ。

ライセンスデータは法務レビューとコンポーネントガバナンスを支えるが、基本的な識別も改善する。名前が似た2つのパッケージでも、所有権や配布条件が異なる場合がある。

ツール名は、SBOMを生成したシステムを記録する。このフィールドにより、利用者は結果の不一致を調査し、2つのスキャナーが同じアーティファクトを異なる形で記述する理由を理解できる。

生成コンテキストは、インベントリがどのように作成されたかを説明する。ソースコードから作成されたSBOMは、コンテナイメージ、インストール済みシステム、最終バイナリから作成されたものとは異なるコンポーネントを捉え得る。

この来歴は、欠落データからセキュリティチームが何を推論すべきかに影響する。ソーススキャンでは、本番ビルドに入らない宣言済み依存関係を特定する可能性がある。バイナリスキャンでは、パッケージマニフェストに記載されていないバンドル済みコードを見つける場合がある。

更新されたフレームワークは、既存のフィールドも明確化している。自動化された脆弱性システムでは、自由記述のパッケージ名をセキュリティ記録と確実に関連付けられないため、一意の識別子が重要となる。

Package URLs、Common Platform Enumeration識別子、SWIDタグは、ソフトウェアを構造化して識別する手段を提供する。単一のスキームですべてのコンポーネントを網羅できるわけではないため、生産者は利用可能なエコシステムに適した識別子を選択しなければならない。

依存関係は引き続き中心的な要素だ。インベントリは、すべての項目を無関係な行として提示するのではなく、あるコンポーネントが別のコンポーネントをどのように含むか、または依存するかを示すことで、より有用になる。

2021年の最小要件でもすでに依存関係情報は必須だった。現在の指針がこの要件により大きな運用上の重みを与えているのは、脆弱性トリアージが依存関係グラフへの依存を強めているためだ。

更新された慣行は、「既知の未知」という概念も維持している。生産者は、利用可能なツールでは追加の依存関係の有無を判断できない領域を示すべきだ。

この表現は危険な思い込みを防ぐ。関係性が記録されていないことは、依存関係が存在しないことを意味する場合もあれば、生成ツールがそれを検出できなかったことを意味する場合もある。

この違いはインシデント対応において決定的に重要だ。セキュリティチームは、否定的な検索結果が不存在の証拠なのか、単に可視性が不完全なのかを知る必要がある。

CISAは実質的に、生産者に対して、インベントリに信頼度と文脈を付与するよう求めている。SBOMは整然さを失うかもしれないが、その分データはより正直になる。

ソフトウェア供給者に求められる証拠の水準が上がる

新たな基準は、供給者に再現可能なセキュリティ証拠の提示を促す一方、購入者にはそれを解釈できるシステムの構築を求める。

ソフトウェア生産者にとって、SBOMは販売レビューの前に一度だけ生成するファイルとして扱うことができなくなる。リリース、再ビルド、依存関係の変更、脆弱性の開示にわたり、製品に追随しなければならない。

そのためには、開発・デリバリーシステムとの統合が必要となる。生産者は、顧客が実際に受け取るアーティファクトを記述できるほどビルドプロセスに近い場所で、インベントリを生成する必要がある。

チームには安定したコンポーネント識別子も必要だ。同じ依存関係に対して連続するビルドごとに異なる識別子が付与されると、自動比較や脆弱性情報の交換は信頼できなくなる。

ツールの開示と生成コンテキストは、関連する期待を生む。生産者は、スキャナーがどのように動作するか、どのソースを調査するか、可視性がどこまで及ぶかを理解しなければならない。

これは不都合なギャップを露呈させる可能性がある。ある企業は、ビルドスキャナーがパッケージマニフェストを取得する一方で、動的にロードされるプラグイン、組み込みファームウェア、コピーされたソースファイル、プロプライエタリなバイナリを見落としていることに気付くかもしれない。

その後、エンジニアリングチームは実務的な選択を迫られる。パイプラインを改善する、未知の領域を文書化する、または上流の供給者からより良い構成データを取得する、という選択だ。

この作業はセキュリティ専門家だけにとどまらない。調達チームにはSBOM受領のための契約文言が必要であり、法務チームには配布ルールが必要であり、プロダクトチームには顧客への更新プロセスが必要となる。

多数のアプリケーションを扱う組織には、検索可能なストレージも必要だ。コンポーネントのインデックスを作成せずに何千ものJSON文書を受け取っても、運用上の可視性ではなく書類作業が増えるだけである。

したがって、この負担は販売者だけでなく購入者にも及ぶ。購入者は異なるファイルを正規化し、潜在的に機微なデータを保護し、新たな脆弱性を監視し、どの検出結果に対応すべきかを判断しなければならない。

生のコンポーネント一致だけでは、直ちに影響を受けていることを示すわけではない。脆弱なコードがビルドから除外されている、設定によって無効化されている、あるいは通常の運用では到達不能である可能性がある。

Vulnerability Exploitability eXchange（VEX）は、製品が脆弱性の影響を受けるかどうかについて、機械可読の表明を提供できる。これらの表明は、VEXレコードを正しいSBOMコンポーネントに結び付ける安定した識別子に依存している。

この関係は、識別子の品質がより重要になった理由を説明する。曖昧なコンポーネント記録は、悪用可能性や修復を記述しようとするその後のあらゆる試みを弱める。

また、CISAの最小要件だけでは機能しない理由も示している。組織には、インベントリを取り巻く脆弱性データベース、VEXデータ、資産の所有情報、ランタイムコンテキスト、対応ワークフローが必要だ。

連邦政府の請負業者は、政府機関がこのベースラインを調達要件に組み込めるため、最初に圧力を感じることになるでしょう。エンタープライズ顧客も、ベンダー評価で同じ質問を採用する可能性があります。

国際的な整合性は、その影響を増幅させます。複数の市場を支援するサプライヤーは、国ごとに別バージョンを維持するよりも、相互運用可能な単一のインベントリを作成する方が有利です。

しかし、標準化が負担を軽減するのは、顧客がベースラインを一貫して解釈する場合に限られます。契約固有の追加フィールド、形式、提供ルールは、最小要素が防ぐことを意図した分断を再び生み出しかねません。

したがって、ソフトウェアチームはこのガイダンスをデータ契約として扱うべきです。作成者は定義された可視性の水準を提供することを約束し、利用者はそのデータを責任を持って扱うことを約束します。

エンジニアリング・ナレッジベースは、チームがSBOMに関する判断をビルド記録、ベンダー文書、修正対応のメモと結び付けるのに役立ちます。これはコンポーネント分析プラットフォームの代替にはなりませんが、各回答を取り巻く判断根拠を保持できます。

より高い証拠負担は、本質的に悪いものではありません。広く使われる依存関係に脆弱性が見つかった際、再現可能なインベントリは影響を受ける製品の探索を短縮できます。

この利点が現れるのは、組織が生成を責任者とアクションに結び付けた後です。そうでなければ、改善されたSBOMも、監査が始まるまで誰も確認しない添付ファイルの一つになります。

より良いSBOMデータでも、より高いセキュリティは保証できない

CISAのより充実したベースラインは脆弱性管理への入力を改善しますが、不完全な依存関係グラフは依然として危険なほど確信に満ちた結論を生みかねません。

2026年7月のプレプリントは、公開データセットに含まれる78,612件のSBOMファイルを調査し、そのうち77,092件は解析可能でした。研究者らは、コンポーネントのフィールドが存在するかを確認するだけでなく、依存関係のエッジに焦点を当てました。

この依存関係グラフの研究では、解析可能なSBOMの52.9%が依存関係エッジを一切宣言していないことが示されました。これらのファイルでは、すべてのコンポーネントが孤立しているように見えました。

さらに8.8%は依存関係ブロックを含んでいたものの、大半のコンポーネントが切り離されていました。このグループの大規模なインベントリでは、孤立コンポーネントの割合の中央値は93%でした。

全体のうち、十分に接続されたグラフを形成していたのは38.3%にすぎませんでした。この研究では、比較可能なソフトウェアを調べる場合でも、グラフ品質は生成ツールによって大きく異なることもわかりました。

これらの知見はプレプリントに基づくものであり、民間企業のインベントリ全般を測定したものとして扱うべきではありません。それでも、CISAが依存関係と既知の未知事項を重視する背景にある実装上の問題を示しています。

フラットなインベントリは、あるパッケージ名がどこかに存在するかどうかには答えられます。しかし、それがどのアプリケーションに含まれるか、何がそれに依存しているか、または脆弱なコードに到達するパスがあるかを、信頼性高く説明することはできません。

この制約は優先順位付けに影響します。一部のセキュリティシステムは、SBOMが製品から影響を受けるコンポーネントへのパスを示さない場合、検出結果を抑制します。

グラフが不完全なら、「パスがない」は「到達不能」を意味しません。それは、ノード間を結び付ける証拠がインベントリに欠けていることを意味します。

この研究では、疑わしい否定的結果を明示的な未知状態に変換するアプローチを検証しました。制御された再スコアリング実験では、CISAのKnown Exploited Vulnerabilitiesカタログに対する再現率が0.600から0.950へ上昇しました。

これらの数値は研究者らのシステムを示すものであり、すべての組織に対する保証結果ではありません。根本的な教訓はより広範です。不確実性は分析プロセス全体で可視化されたままでなければなりません。

ここで、最低限のコンプライアンスと運用上のセキュリティが乖離する可能性があります。ファイルには指定されたすべてのフィールドが含まれていても、浅い検出や壊れた関係性によって製品を誤って表現していることがあります。

コンポーネントハッシュにも限界があります。ハッシュは二つのオブジェクトが同一であることを検証できますが、そのオブジェクトに脆弱なコードが含まれるか、安全でない入力を受け取るかは説明しません。

ライセンスフィールドもセキュリティを確立するものではありません。コンポーネントのガバナンスは改善しますが、ライセンスを正確に特定しても、悪用可能性については何も語りません。

ツール名と生成コンテキストは、利用者が証拠の品質を判断する助けになりますが、それは利用者がツールを理解している場合に限られます。「ソーススキャン」を記録することは、受信側システムがそれをビルド後の成果物スキャンと異なるものとして扱うなら有用です。

SBOMは機微な情報を明らかにすることもあります。詳細なコンポーネントインベントリは、アーキテクチャ上の選択、古い依存関係、または攻撃者が調査できる標的を露出させる可能性があります。

組織には、アクセスとリスクのバランスを取る配布ポリシーが必要です。公開オープンソースプロジェクト、規制対象の医療機器、アクセスが制限された政府システムでは、同一の共有モデルは必要ありません。

データの鮮度も別の課題です。正確なインベントリであっても、ソフトウェアの変更後に作成者が再生成せず、利用者が正しいリリースに関連付けなければ、誤解を招くものになります。

クラウドサービスは、顧客が新しいパッケージをダウンロードしなくてもデプロイ済みコンポーネントが変化するため、この関連付けを複雑にします。継続的なサービスには、静的な製品インベントリでは提供されない更新および通知の運用が必要です。

AIシステムは、さらに曖昧さをもたらします。モデル、データセット、アダプター、リモートAPI、オーケストレーションフレームワーク、従来型ライブラリはいずれも挙動に影響し得ますが、すべての要素が従来のコンポーネントフィールドに収まるわけではありません。

新しいベースラインは、特化したシステムには追加情報が必要であることを認識しています。ただし、変化するモデルパイプラインや外部ホスト型依存関係をどのようにインベントリ化するかについて、あらゆる疑問を解決するものではありません。

これらの制約がSBOMを無意味にするわけではありません。可視性と保証の境界を定義するものです。

原材料リストはリコール対象の食材を特定する助けになりますが、厨房が安全な手順に従ったことを証明することはできません。セキュア開発、テスト、パッチ適用、監視、インシデント対応は、引き続き必要です。

したがって、このガイダンスを最も適切に読むなら、「フィールドが多いほど安全なソフトウェアになる」ではありません。「組織がそのコンテキストと不確実性を保つとき、より良い証拠がより良い意思決定を支える」です。

国際的な整合性が重要性を高める

共同での支持により、CISAの更新は、米国連邦政府をはるかに超えてソフトウェア調達に影響し得る参照点となります。

ソフトウェアのサプライチェーンは国境をまたぎます。ある国で設計された製品には、複数の国で保守されるオープンソースパッケージが含まれ、別の場所で運用されるインフラ上で稼働することがあります。

SBOMの定義が異なれば、そのチェーン全体に摩擦が生まれます。作成者はフィールドを変換し、ファイルを再生成し、ある顧客が要求するデータが別の形式には存在しない理由を説明しなければなりません。

国際的なパートナーは、SBOMが果たすべき役割について共有された見方を築くために取り組んできました。2026年のガイダンスへの参加は、共通の最小データと機械可読な交換を求める根拠を強めています。

この整合性は、単一の世界的な法律を生み出すものではありません。各政府は、独自の調達規則、規制権限、執行スケジュールを維持します。

それでも、契約や技術的な期待を形作ることはできます。政府ガイダンスの文言は、ベンダー評価時に防御可能なベースラインを提供するため、買い手によってしばしば採用されます。

欧州連合のCyber Resilience Actは、デジタル要素を含む製品を販売するメーカーにとって緊急性を加えます。その要件は別個の法的枠組みを作りますが、ソフトウェアインベントリと脆弱性対応は類似した運用領域に位置します。

医療機器メーカーも、すでに確立されたユースケースに直面しています。米国法は、特定のサイバー機器のメーカーに対して、SBOMおよび市販後の脆弱性に対処するプロセスの提供を求めています。

重要インフラの運営者も、共通ライブラリまたは組み込みコンポーネントが標的になった際には迅速な回答を必要とします。その課題は、多くの場合、一つの依存関係を特定することではなく、複数のベンダーから提供される長寿命システム全体でそれを見つけ出すことです。

共有ベースラインが役立つのは、上流のサプライヤーも参加する場合に限られます。完成したアプリケーションの作成者は、別企業から受け取ったクローズドなバイナリの内容を常に特定できるとは限りません。

契約要件は、その要求をサプライチェーンのさらに深い層へ押し進めることができます。一方で、専任のコンプライアンスおよびセキュリティエンジニアリングチームを持たない小規模サプライヤーには不利に働く可能性もあります。

CISAが自動化を重視するのは、その負担を軽減するためです。最新の開発ツールはビルド中にインベントリを生成でき、共通形式を使えば下流システムは手作業で転記せずに処理できます。

自動化はエラーも拡大させます。スキャナーが依存関係を体系的に見逃す場合、生成されるすべてのSBOMが、驚くほど一貫して同じ盲点を繰り返す可能性があります。

したがって、相互運用性テストは形式の選択と同じくらい重要です。作成者は出力を比較し、関係性グラフを検証し、下流ツールが識別子を正しく保持することを確認すべきです。

利用者側にも相応の規律が必要です。SBOMデータを大規模に要求する前に、それが購買、監視、修正対応、ベンダーとのコミュニケーションにどのように影響するかを定義すべきです。

Business Software Allianceは、2025年の協議において調和された期待を支持しました。同時に、受領者に情報を取り込み、行動に移す能力がない場合の調達要件には警告を発しました。

この立場は、主要な政策上のトレードオフを捉えています。証拠を求めることはより良いエンジニアリングを促せますが、利用できない証拠を収集することは資源を浪費し、誤った統制感を生み出します。

国際的な整合性は、良い実践と同じくらい容易に弱い実践も広がり得るため、重要性を高めます。世界的に認められたベースラインは、世界的に一貫した書類作業ではなく、一貫して有用なインベントリを促すべきです。

2026年ベースラインが機能しているかを示す三つのシグナル

このガイダンスが成功するのは、依存関係の品質が改善し、買い手がデータを運用に組み込み、特化したSBOMの実践が相互運用可能であり続ける場合に限られます。

第一のシグナルは、依存関係グラフにおける測定可能な改善です。今後の研究では、フラットなインベントリや切断されたコンポーネントが減少し、明示的な完全性指標の使用が増えていることが示されるべきです。

その結果は、より明確な最小要素が機械支援による脆弱性判断を改善できるというCISAの前提を補強するでしょう。グラフの不備が続けば、定義だけでは生成ツールの挙動を修正できないことが示されます。

第二のシグナルは、連邦政府機関とエンタープライズの買い手が調達をどのように変えるかです。有用な導入では、SBOMの提供を検証、資産所有者、VEXの取り扱い、対応に関する期待と結び付けます。

質問票にアップロード欄を追加するだけの要求は、この主張を弱めます。セキュリティ判断の速度や品質を向上させずに、サプライヤーの作業を増やすためです。

第三のシグナルは、従来型、クラウド、AIのインベントリにまたがる相互運用性です。特化したガイダンスは、識別子、関係性、タイムスタンプについて互換性のない定義を作ることなく、共通ベースラインを拡張すべきです。

整合性が成功すれば、組織は脆弱な従来型パッケージをクラウドサービスやAIアプリケーションを通じて追跡できるようになります。分断されたスキーマは、2026年の更新が解消しようとしている可視性のギャップを再び生み出します。

ソフトウェア作成者は、こうした結果を待つ必要はありません。現在のインベントリを調べ、それぞれがどのように生成されたかを特定し、顧客向けシステムへの取り込み後も関係性が維持されるかを検証できます。

買い手も反対側から同じ演習を行えます。新たに開示された脆弱性を、コンポーネントの記録から影響を受ける製品、責任者、判断、修正状況まで追跡できるかを問いかけてください。

そのワークフローこそが、CISAのサイバーセキュリティガイダンスに対する真の試験です。今日、組織が正確なSBOMを受け取ったとしたら、その証拠をタイムリーなセキュリティ判断へと変換できるでしょうか。

1つの重要な製品から始め、ビルドからレスポンスまでデータを追ってください。欠けているリンクが、SBOMプログラムが運用上の統制なのか、それとも単なるインベントリアーカイブにすぎないのかを明らかにします。