CRA対応について情報収集を進める中で、「SBOMが必要らしい」ということは理解できても、具体的に何を準備し、どのように運用すればよいのか分からないという企業様も多いのではないでしょうか。

SBOMは、製品に含まれるソフトウェアやライブラリなどを一覧化した「ソフトウェアの部品表」です。

ただし、SBOMは一度作成すれば対応が完了するものではありません。

製品のバージョンアップに合わせて内容を更新し、新たに公表される脆弱性情報と照合しながら、製品への影響や対応の必要性を継続的に判断する必要があります。

CRAでは、製品に含まれるコンポーネントや脆弱性を把握・文書化し、製品のライフサイクルを通じて脆弱性へ対応するプロセスが求められます。SBOMは、そのための基礎情報となります。

SBOMを作成した後に待っている「次の課題」

SBOMを作成すると、製品にどのようなソフトウェアやオープンソースコンポーネントが含まれているのかを確認しやすくなります。

一方で、実際の運用では次のような課題が発生します。

製品やバージョンごとにSBOMを更新する必要がある

ファームウェアやソフトウェアの内容が変更されれば、SBOMの内容も変わります。

複数の製品やバージョンを扱っている場合、どの製品にどのコンポーネントが含まれているのかを継続的に管理しなければなりません。

古いSBOMをそのまま保管しているだけでは、現在販売している製品の状態を正しく把握できない可能性があります。

新たに公開される脆弱性情報との照合が必要になる

製品に含まれているソフトウェアについて、出荷時点では脆弱性が見つかっていなくても、出荷後に新たなCVEが公開されることがあります。

そのため、SBOMを作成した後も、公開される脆弱性情報と製品に含まれるコンポーネントを継続的に照合する必要があります。

検出されたCVEが製品に影響するか判断しなければならない

脆弱性情報との照合でCVEが検出されたとしても、必ずしもすべての脆弱性が製品に影響するとは限りません。

例えば、次のような点を確認する必要があります。

• 該当するコンポーネントやバージョンが実際に製品内で使用されているか
• 脆弱性のある機能が製品上で有効になっているか
• 外部から攻撃可能な状態になっているか
• 修正パッチや緩和策がすでに適用されていないか
• 製品の利用環境や構成を踏まえて、どの程度のリスクがあるか

単に「CVEが検出された」という情報だけでは、対応の優先順位を判断できません。

製品への影響を評価し、対応が必要な脆弱性と、影響が限定的または該当しない脆弱性を整理することが重要です。

手作業によるSBOM管理が難しくなる理由

製品数やバージョン数が少ないうちは、表計算ソフトなどを使ってSBOMや脆弱性情報を管理することも考えられます。

しかし、製品やバージョンが増えるほど、次のような作業負担が大きくなります。

• 製品ごとのコンポーネント情報の収集
• ソフトウェア名やバージョン表記の統一
• SBOMの作成と更新
• 最新の脆弱性情報との照合
• 製品への影響有無の確認
• 対応状況や判断根拠の記録
• 開発部門、品質保証部門、セキュリティ部門との情報共有

特に、外部ベンダーから提供されたソフトウェアやファームウェアについては、ソースコードや詳細な構成情報を入手できない場合があります。

このような状況では、製品に含まれるソフトウェアを正確に把握すること自体が難しくなります。

最初からすべての製品を対象にする必要はありません

SBOMの整備や脆弱性管理を始める際、最初からすべての製品やバージョンを対象にしようとすると、対象範囲が大きくなり、取り組みを始めにくくなることがあります。

まずは、代表的な1製品や、欧州向けに販売している製品など、優先度の高い製品から確認する方法が現実的です。

最初に確認したい4つのステップ

1. 対象となる製品とファームウェアを決める
2. 製品に含まれるソフトウェアやコンポーネントを確認する
3. SBOMを作成し、既知の脆弱性情報と照合する
4. 製品への影響や対応の優先順位を整理する

1製品から実際に確認してみることで、SBOMの作成方法だけでなく、社内で必要となる役割分担や運用フローも見えやすくなります。

バイナリからSBOMを生成するという方法

SBOMを作成する方法の一つとして、開発工程やソースコードからコンポーネント情報を取得する方法があります。

一方、すでに開発済みの製品や、外部から調達したファームウェアなどでは、ソースコードやビルド環境を準備できないこともあります。

このような場合は、製品のバイナリファームウェアを解析し、SBOMを生成する方法が有効です。

当社が取り扱う「ONEKEY」は、バイナリファームウェアをアップロードすることで、製品に含まれるコンポーネントの解析やSBOMの自動生成、脆弱性情報の確認を支援するSaaSプラットフォームです。

ソースコードを用意せずに解析を始められるため、既存製品や第三者から提供されたファームウェアについても、製品内部の構成を確認するきっかけをつくることができます。

ONEKEYでできること

ONEKEYでは、SBOMの作成だけでなく、その後の脆弱性管理まで一つのプラットフォーム上で確認できます。

バイナリファームウェアからSBOMを自動生成

ファームウェアを解析し、含まれているソフトウェアコンポーネントやバージョンなどを可視化します。

開発時のソースコードやビルド環境を準備できない場合でも、バイナリから確認を始められます。

製品に関連する脆弱性情報を確認

検出されたコンポーネントと既知の脆弱性情報を照合し、製品に関係する可能性のあるCVEを確認できます。

脆弱性ごとの情報や解析結果を確認することで、対応すべき脆弱性の優先順位を検討しやすくなります。

製品やバージョンを一元管理

複数の製品やファームウェアバージョンをダッシュボード上で管理できます。

製品ごとのSBOMや脆弱性情報をまとめて確認できるため、表計算ソフトや個別ファイルによる管理負担の軽減につながります。

新たな脆弱性を継続的に確認

製品の出荷後に新しい脆弱性が公開された場合も、モニタリング対象として登録した製品について、継続的に脆弱性情報を確認できます。

製品の開発時だけでなく、販売後やサポート期間中の脆弱性管理にも活用できます。

このような企業様におすすめです

• CRA対応に向けてSBOMの作成方法を検討している
• 自社製品に含まれるオープンソースソフトウェアを把握できていない
• ソースコードを準備できない製品やファームウェアがある
• 自社製品がどのCVEに該当するのか確認したい
• 複数の製品やバージョンのSBOMを管理したい
• 出荷後の脆弱性情報を継続的に確認したい
• SBOMや脆弱性管理をお客様へ提案する商材として検討している

まずは1製品・1ファームウェアから確認してみませんか？

SBOMへの取り組みは、最初から全製品を対象にする必要はありません。

まずは代表的な製品を一つ選び、どのようなソフトウェアが含まれているのか、どのような脆弱性リスクがあるのかを確認することが、具体的な対応を検討する第一歩になります。

ONEKEYの画面デモでは、バイナリファームウェアの解析からSBOMの生成、脆弱性情報の確認まで、実際の画面を使ってご紹介します。

• 自社製品でどのようにSBOMを作成すればよいか
• 現在の管理方法からどのように移行すればよいか
• CRA対応に向けて、どの製品から確認すべきか
• お客様への提案商材として取り扱えるか

このようなお悩みがありましたら、ぜひ一度ご相談ください。