公開：
SBOM管理ツールの選び方 | 自社に最適なツールを見極めるためのポイント
サプライチェーン攻撃への対抗策としてSBOM（Software Bill of Materials）が注目されるなか、「導入を進めたいが、どのようにツールを選べばいいかわからない」と悩む企業も多いのではないでしょうか。
コストをかけてツールを契約しても「現場が使いこなせない」「アラートが多すぎて担当者が疲弊する」といった問題が生じれば、SBOM管理の形骸化を招き、セキュリティ対策の機能不全に陥るリスクがあります。
また、ツールの仕様を正確に確認しないまま導入することで「自社の開発環境に合っておらず、正しく部品表を出力できなかった」という運用以前の問題も発生しかねません。
こうした失敗を避けるためには、自社の組織体制をもとにニーズを整理し、開発環境やシステムの性質に合わせて最適な管理ツールを選定することが重要です。
本記事では、SBOM管理ツールの選定に悩む企業の担当者に向けて、自社に最適なツールを見極めるためのポイントを解説します。
目次
SBOM管理ツールの基本的な機能
「SBOM」とは、ソフトウェアに含まれるすべてのコンポーネントやそれらの依存関係、ライセンスデータなどをリスト化した一覧表のことです。
セキュリティ対策としてのSBOMの重要性がうたわれる昨今、多くのベンダーから多様なSBOM管理ツールが提供されています。それぞれ異なる機能や特長を持ちますが、近年のグローバル市場で求められるSBOM管理を実現するためには、最低限次の2つの作業を行えるツールの導入が必要です。
- 対象プロダクトの部品表を正確に出力できる
- 一度限りのスキャンではなく、継続的に更新できる
ツールの選定にあたっては、まず自社のプロダクトに対してこれらが対応可能であることを確認したうえで、これから解説するような観点から比較・検討を進めることをおすすめします。
自社との相性を確認する判断軸
自社に合ったSBOM管理ツールを見極める際には「誰がどのようにSBOMを運用するか」という組織体制を考慮しながら、開発環境やプロダクトの相性をもとに判断する必要があります。
ここでは、SBOM管理ツールを選定するうえでの主要な判断軸について解説します。
運用体制と合っているか
SBOM管理ツールを選ぶ前にまず整理したいのが、自社のセキュリティ対策の体制です。
開発者とセキュリティ担当が一体で動くDevSecOps体制なのか、セキュリティ専任チームが別に存在するのか、あるいは運用チームがシステムを安定稼働させながらリスク管理も担うのか。こうした体制の違いにより、ツールに求めたいアラートの内容やレコメンデーションの粒度は変わります。
例えば運用チームが主体となる場合、脆弱性が見つかった際の対応として、ファイアウォールやWAFの設定変更などの選択肢が考えられます。しかし、開発チーム向けの色が強いツールを導入した場合、コードレベルでの修正などがサジェストの中心となり、実際の対応に活きるヒントが得られないといった事態が想定できます。
このように「誰がSBOMを見るのか」によってSBOM管理ツールに期待する役割に差が出るため、自社のセキュリティ対策の体制を整理したうえで、ツールベンダーに問い合わせることが望まれます。
自社の開発・運用環境で使えるか
ツールの機能がいくら優れていても、自社の開発・運用環境で動作しなければ意味がありません。
SBOMをCI/CDパイプラインに乗せて自動生成・自動アップロードする運用体制の場合、「SBOMを生成して管理サーバーにアップロードする一連の流れが、自社のビルド環境で実行できるか」を確認する必要があります。
また、特にオンプレミスのCI/CD環境では、プロキシやHTTPSなどセキュアな通信環境でしか外部に接続できない構成が一般的であるため、ビルド環境からアップロード通信が可能かどうかの確認も欠かせません。
プロダクトの性質と合っているか
対象となるプロダクトの種類や内部構造との相性も大切な判断軸の1つです。
例えば、Webアプリケーションや業務システムなどの場合は、ビルド環境から比較的容易にコンポーネント情報を取得できる仕様が一般的です。
それに対して、IoT機器や車載システムといった組み込み系ソフトウェアは、ファームウェアに書き込まれて中身がブラックボックス化しているケースが多いため、SBOM生成に際してはバイナリ解析が必要となります。セキュリティ保護がかかったファームウェアはバイナリ解析もできないことがあり、こうしたケースに対応できるSBOM管理ツールは限られています。
また、業務システムであっても、モダン開発に典型的なOSSを多分に含んだシステムなのか、金融・社会インフラに多いOSSを限定したシステムなのかなど、内部構造の違いがツールとの相性に影響を及ぼす側面もあります。
ツール導入前にチェックしたい、実務上の利便性を左右するポイント
上記のような「自社の体制や対象プロダクトに合っているか」という判断軸に加えて、実務上の利便性を左右するいくつかのポイントがあります。
ここでは、継続的なSBOM運用に向けて、ツールの比較・検討段階で確認しておきたい要素を解説します。
アラートの抑制・重複排除ができるか
SBOMツールの運用における問題としてよく挙げられるのが、過剰なアラートによる「アラート疲れ」です。
セキュリティ担当者は、有事の際は即座に対応できるように社用端末を常に持ち歩いていることも少なくありません。こうした状況下で、ひっきりなしにアラートが鳴り、その多くが対応不要な脆弱性であれば、担当者に大きな精神的負荷がかかることは想像に難くないでしょう。こうしたストレスは注意力の低下をもたらし、本当に対応すべき脆弱性の見落としにもつながります。
ツールベンダーとの商談で特に確認しておきたいのが、アラートの重複の問題です。あるライブラリに脆弱性が見つかったとき、そのライブラリが複数の箇所で使われていて、同一の脆弱性に対して何度もアラートが発生する。こうした事態が頻発すると、担当者は短時間で多くの通知に煩わされることになります。
こうした重複アラートを抑制する仕組みがツール側にあるかどうか、またアラートの閾値や対象範囲を自社の開発環境に合わせて調整できるかは、ツール検討段階で入念に確認しておくとよいでしょう。
複数の指標で判断できるか
多くのSBOM管理ツールでは、脆弱性の重大さそのものを表す「CVSS」による診断システムが実装されています。しかし、CVSSだけでは「実際にその脆弱性が悪用されやすい状態にあるか」を判断できず、CVSSが高いと表示された脆弱性をすべて議論の対象とすると、関係者のリソースを著しく圧迫します。
そこで有効なのが、「EPSS」（脆弱性が実際に悪用される可能性を示す指標）などを含めた複数の指標を組み合わせて判定するツールを使い、多面的にリスクを評価することです。
最終的なトリアージは人間に委ねられるものの、自動トリアージにより複数の指標をもとに一定程度要注意な脆弱性を絞り込めれば、トリアージにかかる時間の大幅な短縮につながります。
非技術者にもわかりやすいUIか
SBOMの情報を読み解くのは、セキュリティ担当やサービス運用担当だけではありません。経営層・マネージャー層、取引先への状況報告など、専門知識を持たないステークホルダーにSBOMを用いて自社のプロダクトの安全性について説明する場面は、実運用では頻繁に発生します。
過去の変更履歴について説明責任を果たすためのバージョン管理機能や、ステークホルダーへの説明に用いるサマリーグラフなども含め、ツールの検討段階でデモ画面を確認しておくとよいでしょう。
国産ツールを選ぶことのメリット
現状、SBOM管理ツールの多くは海外製ですが、日本でも政府のSBOM活用推進の流れを受け、国産ツールを提供するベンダーが増えています。
国産のSBOM管理ツールを選定することで、次のようなメリットの享受が期待できます。
日本語でのサポート体制がある
トラブル発生時に、ベンダーから日本語でのサポートを受けられる
ユーザーの声が反映されやすい
日本の市場を対象にしているため、サービスへの要望が反映されやすい
契約のハードルが低い
海外製のSaaS型ツールを使う場合、サーバーの物理的な場所（国内リージョン等）にかかわらず、自社の機微な構成データが海外法人の管轄下（現地の法規制の対象）に置かれることになる。安全な運用に向けて、データ管理ポリシーや約款、準拠法を慎重に確認する必要がある
特に初めてSBOMを運用する場合や、社内にセキュリティの専門人材が不足している場合は、国産ツールの利用を検討するとよいでしょう。
最適なツールの選定で、SBOM運用の挫折を防ぐ
SBOMツールの選定にあたっては、自社の運用体制や開発環境、プロダクトの種類などさまざまな要素を確認する必要があります。
また、アラートの重複排除やUIの見やすさといった実用性も含めて選定することで、SBOMの日常的な利用を円滑化し、結果としてセキュリティ対策の質向上にもつながります。
AGESTの提供するSBOM管理ツール「SBOM Archi」は、SPDX・CycloneDXの両方の国際標準フォーマットに対応し、CVSSとEPSSを組み合わせた自動トリアージを実装しています。国産ツールならではの日本語での充実したサポート体制を備え、初めてSBOMを導入する企業から本格的な運用体制の構築を目指す企業まで、幅広くご支援します。
SBOMの導入・運用に課題をお持ちの方は、ぜひ一度ご相談ください。
