公開:
SBOMの運用にあたって企業が直面する壁とは?運用成功に向けたポイントも解説
ソフトウェアサプライチェーンの脆弱性を狙った攻撃が増加するなか、セキュリティ対策の手段として近年注目が集まっている「SBOM」。米国やEUでの規制強化を背景に重要性が高まり、国内でも運用する企業が増えています。
一方で、「SBOMを導入したものの、更新や活用が定着せず形骸化している」という企業も少なくありません。
SBOMの運用にあたっては、環境構築や知識の習得、サプライチェーン内での連携など、多くの課題を乗り越えることが求められます。一方で、セキュリティに対する正しい理解のもと、組織体制やワークフローを整えることができれば、日々新たに発生する脆弱性に対し、盤石な対応体制を維持できるようになります。
本記事では、SBOM運用にあたって企業が直面することの多い課題や、SBOM活用を成功させるためのヒントを解説します。
目次
SBOM運用で企業が直面する問題
SBOMを効果的に運用し続けられる体制を構築するまでには、乗り越えるべき多くのハードルが存在します。
企業が直面する問題は、段階に応じて以下の3つに分類できます。
- SBOMの作成
SBOMの作成自体ができない、または作成できてもソフトウェア全体を反映しきれない - リスクの検出(脆弱性、ライセンス違反、EOL/EOS)
SBOMを作成しても、検出漏れや誤検知が起きる - 対応方針の策定
脆弱性を検出できても、どう対処していいか判断できない
では、あらゆる場面で表面化する問題に対して、どのような対応を取ればよいのでしょうか。その答えにたどり着くには、背景にあるSBOM運用のボトルネックについて理解を深める必要があります。

SBOM運用のボトルネック
SBOMの運用には、取り扱う情報の複雑さや環境整備のコストなど、さまざまなハードルが存在します。
ここでは、SBOMを運用する際にボトルネックになりやすい5つの要素を見ていきましょう。
現代のソフトウェアの複雑性
ソフトウェアの構成は年々複雑さを増しており、自社のシステムの全体像を把握することも一筋縄ではいきません。
特に注意が必要なのが、複数の業者が役割を分担して開発することで、コンポーネントやライブラリ同士の依存関係が連鎖する「推移的依存関係」の問題です。
例えば、自動車の開発の場合、一般的には以下のようなサプライチェーンを構築しながらプロジェクトが進行します。
自動車メーカー
車両全体として調達・統合
↓
Tier-1:システム/ECUサプライヤ
例:TCU(車をインターネットにつなぐための制御装置)ソフト、IVI(カーナビやオーディオ、動画配信、スマホ連携などを統合した車内情報・娯楽システム)のミドルウェア、OTAクライアント(車載ソフトを遠隔でアップデートするための仕組み)などを統合して納入
↓
Tier-2:ソフト部品/モジュールサプライヤ
通信モジュールやログ収集、セキュリティなど用途別のモジュールを提供
↓
Tier-3:基盤ライブラリ
通信や暗号などの共通機能を担う基盤ライブラリを提供
※各レイヤーの業者が提供するコンポーネントやライブラリには、通信・暗号・OS周辺機能などを中心に、OSSが広く利用されている
このように、1つのプロダクトを完成させるまでには多層的な分業構造があり、合計で数千・数万のコンポーネントがシステムに含まれているケースが少なくありません。多くのプロジェクトでは、完成品を提供するベンダーも、内部で利用されているOSSやライブラリを完全には把握できていないのが実情です。

環境整備・運用にかかる工数
SBOMは、作成から日々の運用まで多くの工数を要します。
例えば、作成段階では、単にツールを導入すればよいわけではなく、以下のような要件を細かく定義していく必要があります。
- 記載の粒度(OS単位、アプリケーション単位、ライブラリ単位など)
- 更新の頻度(毎ビルド、月1回などの定期更新など)
- アクセス権限(開発者全員、セキュリティ担当のみなど)
- 誤りがあった際の対応フロー
これらの要件についてセキュリティ担当や法務を交えて合意形成を図ったうえで、CI/CDパイプラインによる自動更新の設定を進めることとなります。
さらに、作成後の運用でも、監視やエラー対応、検出された脆弱性への対応など、さまざまなコストが日常的に発生します。
こうした多くの負荷により、SBOMを「作成できない」「作成しても運用を続けられない」といった事態に陥る企業が少なくありません。
脆弱性の発生速度
技術の発展が速い現代では、日々新たな脆弱性が発見されています。米国の国立標準技術研究所(NIST)が公開している脆弱性データベース(NVD)によると、1か月あたり数千件規模の脆弱性情報が更新されているといいます。
悪意のあるユーザーは、新たに発生した脆弱性を狙って即座に不正アクセスを仕掛けてくるため、企業は常に最新の脆弱性情報にキャッチアップし、リスクに対応する必要があります。
対応方針を判断する難しさ
SBOMを作成できたとしても、すべての脆弱性に対して完璧に対応することは事実上不可能です。現実的な負荷で安全なリリースを実現するためには、リスクの種類に応じて対応の必要性の有無や優先順位を考えていく必要があります。
脆弱性には「インターネットから到達可能になった時点で顕在化するもの」「呼び出されたときに顕在化するもの」などさまざまなタイプがあり、システムの構成や設定によって顕在化の有無や影響範囲は変わります。
SBOMで脆弱性を可視化できても、それを実際の対策につなげていくためには、セキュリティの専門知識が求められるのです。
無償ツールの限界
SBOMツールには、有償から無償まで幅広いプロダクトが存在し、プロジェクトの性質やチームの状況に合ったツールを選定することが求められます。
ここで注意すべきは、無償ツールの場合、機能・サービスの両面でさまざまな限界があり、脆弱性への適切な対応につなげにくい傾向があるという点です。
まず機能面について、多くの無償ツールでは、無視できない量の検出漏れや誤検出が発生し、生成されたSBOM自体の信頼性を十分に担保しづらいという特徴が見られます。
さらに、無償ツールではベンダーによるサポートがない場合が多く、保管方法やバージョン管理のフローといった運用上の判断や、検出された脆弱性に対する「外部から到達可能か」「緩和策(WAF、IP制限など)で当面耐えられるか」などの判断が自社に一任されます。
以上のような限界から、特にセキュリティの専門人材が不足している企業で無償のツールを利用した場合、SBOMを作成しても適切に運用できず、重大なリスクが残存してしまう可能性が高まります。
SBOM運用のポイント
SBOMの運用では、上述のようなボトルネックを克服するために、組織の体制やワークフロー、ツールの選び方などの面でさまざまな工夫が必要です。
最後に、SBOMを効果的に運用するためのポイントを解説します。
トリアージの体制を整える
SBOMを機能させるためには、セキュリティ面でのトリアージ(※)の体制を整える必要があります。
セキュリティインシデントに対応する専門組織としてのSIRT(Security Incident Response Team)を立てるか、あるいはその役割をアプリケーション管理チームやサーバー管理チームで担当するなど、継続的に運用しやすい組織体制やワークフローの整備を進めましょう。
※トリアージ:バグ、機能リクエスト、ユーザーからの問い合わせなどの問題について、深刻度、範囲、ビジネスへの影響度に基づいて評価し優先順位を検討する体系的なプロセス
管理工数を減らす
機能の追加や変更のたびにSBOMを手動で更新するのは現実的ではなく、実務ではCI/CDパイプラインへ組み込むのが基本となります。ビルド(ソースコードから実行ファイルを作成する工程)時にSBOMを自動生成し、成果物とセットで保管することで「どのビルドで・どの依存関係が入ったか」が追跡できるようになります。
また、システム構成を変更する際は、可能な限り自社が直接管理できる層(上位層)を置換することで、影響範囲の見積もりや検証が容易になり、保守コストの低下につなげられます。
使用するフォーマットについて事前に合意する
複数の企業が協力して進める開発プロジェクトの場合、SBOMの作成に向けて、それぞれの発注先から担当範囲の部品表を収集する必要があります。このタイミングでフォーマットがバラバラであることが判明すると、統一や変換のために予期せぬ時間と労力を費やすことになります。こうしたコストを回避するためには、契約時点で使用するフォーマットを指定しておくことをおすすめします。
代表的なフォーマットとして、経済産業省の手引書にはSPDX(Software Package Data Exchange)、CycloneDX、SWIDタグ(Software Identificationタグ)の3つが記載されていますが、近年は特にSPDXとCycloneDXの普及が進んでいます。
それぞれのフォーマットの特徴については、以下の記事もご覧ください。
SBOMとは?義務化の流れや重要性、3つの標準フォーマットについて解説
機能・サポートの充実したツールを活用する
信頼性の高いSBOMを作成し、脆弱性に対する適切な対応を続けていくためには、機能・サポートの充実したツールを選ぶことが重要です。
機能面では、タスク管理ツールとAPI連携したものを使用することで、SBOMの生成や脆弱性検出に加え、対応タスクの割り当てまでをスムーズに進められます。
また、ベンダーのサポートがあるツールを使用すれば、運用設計や検出された脆弱性に対する対策の方法や優先順位について専門的な知見から助言を得られ、効果的な対応につながります。
SBOMの継続的な運用と、適切な脆弱性対策に向けて
SBOMの導入・運用にあたっては多くのハードルが存在し、ノウハウがない状態から十分な運用体制を構築するまでは一定の時間を要します。まずは現状のリソースやナレッジで可能な範囲から導入し、更新頻度や網羅性については、運用のなかで改善していくとよいでしょう。
AGESTの「SBOM Archi」は、SBOMの生成および検出された脆弱性の定期的な評価と改善をサポートします。リスク予測を含めた多次元評価や、改善効果をシミュレーションするレコメンドなどの多面的な機能に加え、経験豊富なエンジニアによるサポート体制も充実。初めてSBOMを導入するチームにも安心して使用いただけるツールとなっています。
SBOMの導入や運用に課題を持つ企業は、ぜひ一度AGESTにご相談ください。
