ソフトウエア開発では、オープンソースソフトウエア（OSS）、外部ライブラリ、商用コンポーネントなど、多くのソフトウエア部品を組み合わせることが一般的になっています。

利用しているソフトウエア部品を正確に把握できていないと、新たな脆弱性が公表された際に、自社製品・システムへの影響をすぐに判断できません。

そこで重要になるのが、ソフトウエア部品表であるSBOM（Software Bill of Materials）の作成と運用です。脆弱性対応に役立てるには、作成後も更新し、脆弱性情報との照合に利用する必要があります。

本記事では、SBOM運用の基本や、脆弱性対応に活用する流れ、必要なツール、運用を効率化するためのチェックリストを解説します。

SBOM運用とは？脆弱性対応で重要になる理由

SBOM運用とは、ソフトウエアに含まれる構成情報を継続的に管理し、脆弱性対応やライセンス管理に活用する取り組みです。

例えば、特定のライブラリに重大な脆弱性が見つかった場合、SBOMが整備されていれば、そのライブラリをどの製品・システムで使用しているかを素早く確認できます。

SBOM作成とSBOM運用の違い

SBOM作成は、ソフトウエアの構成情報を一覧化する作業です。OSSやライブラリなどの構成部品（コンポーネント）の名称、バージョン、サプライヤー、ライセンス、コンポーネント間の依存関係などを整理し、SPDXやCycloneDXなどの形式で出力します。

一方、SBOM運用は、作成したSBOMを最新状態に保ち、脆弱性情報との照合、対応優先度の判断、修正履歴の管理、取引先との共有まで行うことを指します。

つまり、SBOM作成は出発点であり、運用は脆弱性対応に生かすための継続的な活動です。

SBOMで管理すべき主な情報

SBOMでは、主に以下の情報を管理します。

• コンポーネント名
• コンポーネントのバージョン
• サプライヤー
• ライセンス
• コンポーネント間の依存関係
• 識別子
• ハッシュ値
• SBOMの作成日時
• 対象製品・バージョン

これらの情報が整理されていることで、脆弱性が公表された際に、影響範囲を機械的に確認しやすくなります。

また、直接利用しているライブラリだけでなく、そのライブラリが依存する別のコンポーネントとの間接的な依存関係も重要です。

脆弱性は、開発者が意識していない深い階層のコンポーネントで見つかることもあります。

SBOM運用が求められる背景

SBOM運用が求められる背景には、OSS利用の拡大とソフトウエアサプライチェーンの複雑化があります。ソフトウエアサプライチェーンとは、部品の調達から開発、提供、運用に関わる組織や工程のつながりです。

現在の開発では、すべてを自社で一から作るのではなく、既存のOSSや外部ライブラリを活用して開発効率を高めることが一般的です。

しかし、利用するコンポーネントが増えるほど、脆弱性管理は難しくなります。自社が直接使っているライブラリだけでなく、そのライブラリが依存している別のコンポーネントまで確認する必要があるためです。

また、外部から調達したソフトウエアの脆弱性にも注意が必要です。取引先や外部ベンダーから提供されたソフトウエアに脆弱性が含まれていた場合、自社の業務や顧客にも影響が及ぶ可能性があります。

SBOMを活用すれば、こうしたリスクを把握し、影響調査や対応判断を効率化できます。

SBOMを活用した脆弱性対応の基本フロー

SBOMを活用した脆弱性対応は、まず対象製品・システムを決めることから始まります。

すべての製品・システムを一度に対象にすると負荷が大きいため、外部公開システム、顧客向け製品、重要業務システムなど、優先度の高い領域から始めるとよいでしょう。

次に、SBOM生成ツールやソフトウエア構成分析（SCA）ツールを使って、対象ソフトウエアに含まれるコンポーネントを可視化します。その後、CVE（共通脆弱性識別子）が付いた脆弱性情報などと照合し、対象となるバージョンのコンポーネントが含まれているかを確認します。

脆弱性が検出された場合は、深刻度だけでなく、実際にその機能を利用しているか、外部から攻撃可能か、攻撃コードが公開されているかなどを踏まえて対応の優先度を判断します。すべての脆弱性を同じ優先度で対応するのではなく、リスクベースで対応順を決めることが重要です。

最後に、修正、バージョンアップ、設定変更、回避策の適用、例外承認などの対応を行い、対応履歴を記録します。

この履歴が残っていれば、監査や取引先への説明にも活用できます。

SBOM運用に必要なツールと選定ポイント

SBOM運用では、手作業だけで構成情報を管理すると、更新漏れや作業負荷が課題になります。対象製品・システムが増えるほど、ツールによる自動化が重要です。

主なツールには、以下が挙げられます。

• SBOM生成ツール
• SCAツール
• 脆弱性スキャンツール
• 脆弱性管理ツール

ツール選定時は、対応しているプログラミング言語、パッケージマネージャー、コンテナやクラウド環境への対応などを確認します。

また、SBOMの出力形式が標準フォーマットに対応しているか、取引先と共有しやすいかも重要です。

SBOM運用を効率化するチェックリスト

SBOM運用を効率化するには、導入前、運用時、取引先確認の観点でチェック項目を整理しておくことが有効です。以下のように、確認すべき項目をあらかじめ決めておくと、運用が属人化しにくくなります。

区分	確認項目
導入前	対象製品・システムを決めているか
導入前	管理対象のOSS、ライブラリ、商用コンポーネントを定義しているか
導入前	SBOMの管理責任者と関係部門を決めているか
導入前	使用するフォーマットやツールを決めているか
運用時	リリース時や主要ライブラリ更新時にSBOMを更新しているか
運用時	脆弱性情報と定期的に照合しているか
運用時	検出された脆弱性の優先度判断基準があるか
運用時	対応期限、例外承認、対応履歴を管理しているか
取引先確認	SBOMの提出可否と、含まれる部品・依存関係の範囲を確認しているか
取引先確認	SBOMの更新頻度や提供形式を確認しているか
取引先確認	脆弱性発見時の報告体制と報告期限を確認しているか

チェック項目を運用に生かすポイント

導入前は、対象範囲を広げすぎないことが重要です。まずは重要度の高い製品や外部公開システムから始め、運用に慣れてから範囲を拡大するとよいでしょう。

運用時は、SBOMが最新状態に保たれているかを確認します。開発中にライブラリを追加・更新しても、SBOMが更新されなければ、脆弱性対応には十分に活用できません。

継続的インテグレーション／継続的デリバリー（CI/CD）の工程に組み込み、ビルド時やリリース時にSBOMを自動生成する仕組みを整えると効率的です。

取引先に対しては、SBOMの提出可否だけでなく、どの範囲まで含まれているか、更新頻度はどの程度か、脆弱性が見つかった際にどのような期限で報告されるかを確認します。

SBOM運用でよくある課題と対策

SBOM運用でよくある課題は、作成後に更新されないことです。運用開始時にSBOMを作成しても、開発や保守の過程でライブラリが変更されれば、内容はすぐに古くなります。

対策として、リリース時、主要コンポーネント更新時、定期診断時など、更新タイミングを明確にしておく必要があります。

また、検出される脆弱性が多すぎて対応しきれないという課題もあります。この場合は、共通脆弱性評価システム（CVSS）による深刻度だけでなく、外部公開の有無、悪用可能性、攻撃実績、業務影響を踏まえて優先度を決めるとよいでしょう。

さらに、担当部門が曖昧になるケースもあります。開発部門、情報システム部門、セキュリティ部門、調達部門のどの部門が何を担当するのかを明確にし、検出後の対応停滞を防ぐことが大切です。

SBOMは脆弱性対応プロセスに組み込んで活用する

SBOMは、ソフトウエアの構成情報を可視化するための重要な手段です。しかし、作成するだけでは十分ではありません。

脆弱性情報との照合、リスク評価、対応優先度の判断、修正履歴の管理まで含めて運用することで、脆弱性対応の効率化につながります。

OSSや外部コンポーネントの利用が拡大する中で、利用部品とその依存関係を把握できる状態にすることは、企業のセキュリティ対策に欠かせない取り組みです。

まずは重要な製品・システムからSBOM運用を始め、ツールとルールを組み合わせながら、取引先との情報共有も含めた継続的な脆弱性管理の仕組みを整えていきましょう。