ソフトウェア調達でSBOM（Software Bill of Materials）を受け取っても、共有フォルダーへ保存したままでは、脆弱性が公表されたときの判断は速くなりません。 対象製品とバージョンを特定できない、部品名と脆弱性情報の識別子が結び付かない、更新版が届かない、担当部署が分からない。この状態では、SBOMは透明性を高める材料ではあっても、事業を守る運用にはなっていません。

NISTはSBOMを、ソフトウェアの構成要素とサプライチェーン上の関係を記録する正式な情報と定義しています。CISAが2025年に公表した最小要素では、作成者、製造者、部品名、バージョン、識別子、ハッシュ、ライセンス、依存関係、生成ツール、タイムスタンプ、生成時点の文脈などが整理されました。 ただし、項目がそろうことと、影響を判断して対応できることは別です。

2025年には、日本を含む15か国の当局がSBOMの国際共同ガイダンスに署名し、脆弱性管理へ活用する共通認識を示しました。経済産業省の導入手引ver.2.0も、作成だけでなく、脆弱性管理プロセス、導入範囲、取引者間の役割を扱っています。 本記事では、経営者、IT責任者、調達、開発、運用、セキュリティ担当がSBOMを一つの判断プロセスへつなぐ5ステップを整理します。

課題：SBOMが「受領」で止まる理由

SBOM活用が止まりやすい第一の理由は、目的より先に「全製品から集める」が始まることです。対象が広すぎると、形式や粒度の違うデータが大量に集まり、どの業務を優先して改善するのかが見えなくなります。 第二の理由は、調達部門が受領し、セキュリティ部門が脆弱性情報を監視し、運用部門が製品構成を管理するという分断です。製品責任者、利用業務、設置場所、供給者への連絡経路が結び付かなければ、該当部品を見つけても対応判断へ進めません。

第三の理由は、SBOMを静的な納品物と考えることです。ソフトウェアは更新され、依存部品も変わります。作成日時と対象バージョンが不明確なSBOMや、アップデート後に更新されないSBOMは、現行環境を表さなくなります。 また、部品が含まれるだけでは脆弱性の影響を受けるとは限りません。到達可能性、設定、利用機能、供給者のVEX（Vulnerability Exploitability eXchange）情報、実際の攻撃状況などを合わせて判断する必要があります。

考え方：部品表ではなく「判断の連鎖」を設計する

SBOMの価値は、部品名を一覧化することではなく、「どの製品が、どの業務で使われ、どの部品を含み、誰が判断し、いつまでに何をするか」を追跡できることにあります。 そのためには、資産・サービス台帳、調達条件、SBOM保管、脆弱性情報、供給者通知、変更管理、インシデント対応を一つの流れとして設計します。

NIST SSDFは、組織の準備、ソフトウェアの保護、安全なソフトウェアの生成、脆弱性への対応という四つのグループで実践を整理し、構成要素の来歴情報を収集・共有するタスクも含めています。 NIST NCCoEが2026年に公開した継続更新型のDevSecOps実装資料は、SSDFの実践をパイプラインへ組み込み、自動化と標準化によって一貫した適用を目指しています。SBOMも単独のファイルではなく、この開発・調達・運用の流れへ接続して初めて継続的に使えます。

実践手順：調達から対応までをつなぐ5ステップ

1．重要業務と利用目的から対象を絞る

最初から全製品を対象にせず、停止時の事業影響が大きいサービス、外部接続が多い製品、更新頻度の高いアプリケーションなどから始めます。 「新たな重大脆弱性への影響確認を速める」「調達時に構成の透明性を確認する」「サポート終了部品を把握する」といった利用目的を一つか二つに絞り、製品責任者、判断者、供給者への連絡担当を決めます。

2．受領条件と更新ルールを具体化する

対象製品のバージョン、SBOM形式、必要項目、依存関係の深さ、提供方法、更新契機、提供期限、問い合わせ窓口を整理します。CISAの最小要素は共通の出発点になりますが、自社の利用目的に不要な項目を増やすのではなく、識別と更新に必要な品質を優先します。 契約や調達仕様へ反映する場合は、責任分担、共有範囲、機密性、費用、再配布の可否を調達・法務・セキュリティの関係者で確認します。

3．取り込み時に品質を検査し、資産へ結び付ける

受領時に、対象製品とバージョンの一致、作成日時、識別子、重複、依存関係、形式の妥当性を自動または半自動で確認します。検査結果は合否だけで終わらせず、欠落項目と問い合わせ状況を記録します。 次に、SBOMをサービス・製品・環境の台帳へ関連付けます。「この部品がある」から「この業務の本番環境で使うこの製品にある」までたどれることが重要です。

4．脆弱性情報を照合し、事業影響で優先順位を付ける

CVEなどの脆弱性情報とSBOMの識別子を照合し、候補を抽出します。その後、供給者の見解、VEX、利用機能、設定、外部公開、攻撃の観測、代替策、停止時の影響を確認し、対応期限と責任者を決めます。 一致件数だけをKPIにせず、重要製品の影響確認に要した時間、判断待ちの件数、供給者回答の遅延、期限内の緩和・更新などを組み合わせて改善します。

5．更新・演習・廃止まで一つの運用にする

製品アップデート、新規リリース、重要部品の変更、供給者変更、サポート終了をSBOM更新の契機へ組み込みます。四半期などの定期確認だけでなく、変更管理やリリース管理から自動的に更新要求が起きる流れを目指します。 実在する脆弱性を使わない机上演習でも構いません。重要部品の問題を想定し、対象製品の抽出、事業影響の確認、供給者照会、暫定対策、経営報告までを通して、台帳や役割の欠落を見つけます。

注意点：SBOMだけで安全性は証明できない

  • 完全性を前提にしない：生成方法や対象時点により、含まれない部品や誤った識別子があり得ます。品質検査と供給者への確認経路を残します。
  • すべての一致を同じ緊急度にしない：含有と影響可能性を分け、事業影響、到達可能性、悪用状況、緩和策を合わせて判断します。
  • 共有範囲を無制限に広げない：詳細な構成情報は攻撃面や知的財産に関わる場合があります。目的に応じたアクセス制御と保存期間を決めます。
  • SaaSをオンプレミス製品と同じ方法で扱わない：利用者が直接確認できない構成もあるため、透明性の説明、通知、保証、終了時の対応など別の確認方法を組み合わせます。
  • ライセンス一覧を法的判断へ直結させない：SBOMは確認材料です。具体的な権利・義務や契約判断は、対象条件を踏まえて専門家と確認します。

最初の90日で作るべき成果物

最初の30日で、対象サービスを一つ選び、利用目的、製品責任者、供給者窓口、現行バージョン、既存SBOMの有無を整理します。次の30日で、受領条件、品質検査、資産台帳への関連付け、脆弱性照合、判断記録を小規模に試します。 最後の30日で、想定脆弱性を使った机上演習を行い、対象抽出から経営報告までの所要時間と判断待ちを振り返ります。

成果物は、大規模なSBOM基盤の導入計画ではありません。対象サービスの範囲、最小の受領条件、品質チェックリスト、資産との対応表、脆弱性判断フロー、役割分担、更新契機、演習結果という小さな運用一式です。 この一式が機能してから、製品数や自動化の範囲を広げます。

まとめ

SBOMは、ソフトウェアの透明性を高める重要な材料ですが、受け取るだけでは事業判断につながりません。重要業務から対象を絞り、受領条件を定め、品質を検査し、資産と脆弱性情報へ結び付け、更新と演習まで回すことで、初めて日常のセキュリティ運用になります。

FourthWallは、ソフトウェア資産管理、調達要件、SBOMの受領・検査、脆弱性管理、供給者連携、インシデント対応を分断せず、組織の規模とリスクに合った段階導入を支援します。 最初の一歩は、重要な一つのサービスについて「影響を判断するために何が足りないか」を実際の流れで確かめることです。

参考資料

本記事は公開資料に基づく一般的な情報提供を目的とし、特定の製品選定、契約、法務、ライセンス、セキュリティに関する個別助言ではありません。実際の導入では、対象システム、事業影響、供給者との契約、情報管理、適用法令を関係専門家と確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る