SBOMツールの選び方~自社構築と外部委託、どちらが向いているか~
SBOMツールとは、ソフトウェアを構成するコンポーネントを特定してSBOM(部品表)を生成・管理したり、その情報を脆弱性データベースと照合したりするためのツールです。
自社で構築するか、外部の商用ツールや専門事業者を活用するかによって、コストや運用負荷、対応スピードが大きく変わります。
【結論】 SBOMツールの選定は、自社の製品規模・専門人材の有無・制度・規制対応までの猶予期間で判断します。
-
開発体制が限られ、対象製品数が少ない場合は、商用ツール・外部委託の活用が現実的
-
自社構築は継続的な開発体制と専門人材の確保が前提になる
-
選定時はフォーマットだけでなく、解析方式・データの取り扱い・継続的な脆弱性管理まで確認する
-
CRAやJC-STAR等への制度・規制対応を急ぐ場合は、スピード重視で外部活用を検討する
本記事では、SBOMツールを自社構築と外部活用(商用ツール・外部委託)のどちらの方式で導入すべきか、判断基準と選定時のチェックポイントを解説します。
目次
- SBOMツールとは何か?なぜ選定に迷うのか
- SBOMツール導入にはどんな選択肢があるか?
- 自社構築・商用ツール導入・外部委託、メリット・デメリットは何か?
- 自社構築と外部活用、どちらを選ぶべきか?
- SBOMツール選定で失敗しないためのチェックポイントは何か?
- SBOMツール導入の費用はどう考えればよいか?
- よくある質問
- まとめ
- SBOMツール選定・IoT機器のセキュリティ対応でお悩みの方へ
1. SBOMツールとは何か?なぜ選定に迷うのか
SBOMツールの選定に迷いやすい背景には、規制対応の広がりと、自社に十分な知見がないという2つの要因があります。
1.1. SBOMとは何か?
SBOMとは、Software Bill of Materialsの略で、ソフトウェアを構成するコンポーネントやライブラリを一覧化した部品表のことです。
含まれるオープンソースソフトウェア(OSS)のバージョンやライセンス情報を可視化し、既知の脆弱性と突き合わせることで、迅速な対応を可能にします。
IoT機器メーカーや組み込みソフトウェア開発企業にとっては、CRA(サイバーレジリエンス法)への対応や、対象製品・適合レベルによってはJC-STARへの対応にも関わる重要な基盤になります。
SBOMの基本的な仕組みやメリットについては、以下の記事で詳しく取り上げています。
1.2. SBOMツールの選定が重要になっている背景は?
EUのCRAでは、少なくとも製品のトップレベル依存関係を含むSBOMを、一般的に使用される機械可読形式で作成し、技術文書に含めることが求められます。
また、市場監視当局から適合確認のため合理的な理由に基づいて求められた場合には、SBOMを提供する必要があります。
米国でも、2021年の大統領令14028を契機に、連邦政府調達を中心としてSBOM活用が進みました。
2026年1月、OMBはM-26-05を公表し、従来のM-22-18・M-23-16を撤回したうえで、連邦政府のソフトウェア・ハードウェアセキュリティ確保を、各機関のリスク判断に基づく方針へ見直しました。
同文書では、各連邦機関が必要に応じて、ソフトウェア提供者に最新のSBOMを要求時に提供することを契約条件として採用できるとしています。
日本国内でも、経済産業省がSBOM導入の手引を策定するなど、ソフトウェアサプライチェーンの可視化を求める動きが国内外で強まっていることが背景にあります。
(出典:経済産業省「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引 Ver.2.0」)
(出典:OMB「M-26-05: Adopting a Risk-based Approach to Software and Hardware Security」)
CRAでは2026年9月11日から、積極的に悪用されている脆弱性・重大なインシデントの報告義務が適用され、2027年12月11日から全面適用されます。
JC-STARでも適合レベルによって要件が異なり、2026年に公開された通信機器・ネットワークカメラ向け★3では、SBOMの作成・管理が要件に組み込まれています。
(出典:Regulation (EU) 2024/2847 (Cyber Resilience Act))
(出典:IPA「セキュリティ要件適合評価及びラベリング制度(JC-STAR)」)
CRAの適用時期が近づき、JC-STARでも対象カテゴリ・適合レベルごとの要件整備が進むなか、自社にSBOM作成のノウハウがない企業ほど「どの方法で対応すべきか」の判断に迷いやすくなっています。
CRAの詳しい適用時期や対象範囲については、以下の記事もあわせてご参照ください。
2. SBOMツール導入にはどんな選択肢があるか?
導入方式は、大きく「自社構築」と「外部活用」に大別できますが、実務上は自社構築(自社開発・OSS活用)・商用ツール導入(自社運用)・外部委託(診断・作成代行)の3パターンに整理すると判断しやすくなります。
本記事では便宜上、自社でツール・体制を構築する「自社構築」と、商用ツール導入や外部委託を含む「外部活用」の2つに大別して解説します。
2.1. 自社構築(自社開発・OSS活用)とはどのような方式か?
自社構築とは、SBOM生成ツールを自前で開発するか、オープンソースのSBOM生成ツールを自社エンジニアが導入・保守する方式です。
社内で担当者や責任分担を明確にし、ツールや脆弱性情報源、対応フォーマットなどの更新に継続的に追従する体制が必要です。
2.2. 商用ツールを導入して自社運用するとはどのような方式か?
商用ツール導入とは、SBOMの生成・管理や脆弱性照合などの機能を備えた商用ツールを導入・契約し、自社の担当者が解析・運用を行う方式です。
構築(ツール調達)は外部の製品に頼りつつ、日々の運用は自社で行う点が、後述の外部委託との違いです。
2.3. 外部委託(診断・作成代行)とはどのような方式か?
外部委託とは、SBOMの作成・脆弱性診断業務そのものを外部の専門事業者に委託する方式です。
自社で専用の解析基盤を構築したり、高度な解析ノウハウをすべて内製したりする必要がなく、比較的導入しやすい点が特徴です。
ただし、対象範囲の確認や解析結果の精査など、委託後も自社で確認すべき事項が残る点には注意が必要です。
3. 自社構築・商用ツール導入・外部委託、メリット・デメリットは何か?
3方式の違いは、主にコスト構造・運用の主体・専門知識の必要性に表れます。
|
観点 |
自社構築(OSS) |
商用ツール導入(自社運用) |
外部委託 |
|
初期コスト |
環境構築・検証・体制整備の工数・人件費が中心 |
ライセンス費用・初期設定が中心 |
初回解析費用が中心 |
|
運用の主体 |
自社(構築も運用も内製) |
自社(ツールは外部、運用は内製) |
外部事業者(契約形態に応じて製品追加・更新時に依頼) |
|
導入スピード |
環境構築・検証・運用体制の整備に時間を要する |
自社構築と比べて導入期間を短縮しやすい |
自社で解析基盤を構築する場合より開始しやすい |
|
必要な専門知識 |
脆弱性DB連携やフォーマット対応の知見が必要 |
ツール操作・結果の読み解きの知見が必要 |
高度な解析知識は外部に補完できるが、要件整理や結果確認の知識は必要 |
|
継続運用の負荷 |
脆弱性DB更新・フォーマット改定への追従が必要 |
ベンダー提供の更新を利用できるが、自社での運用・結果確認は必要 |
契約形態によっては、更新・再診断時に追加依頼や追加費用が発生する |
自社構築は、対象製品数が多く継続的な開発体制を持つ企業ほど、初期投資を複数製品で活用できるメリットが出やすい方式です。
一方で、必要な知見を持つ担当人材の確保や運用体制の維持が課題となるため、継続的に更新・運用できる体制をあらかじめ整えておく必要があります。
商用ツール導入・外部委託を含む外部活用は、自社で解析基盤をゼロから構築する負担を抑えつつ、比較的早期にSBOM対応を開始したい企業に向いています。
4. 自社構築と外部活用、どちらを選ぶべきか?
判断基準は、対象製品数・社内の専門人材・制度・規制対応までの猶予期間の3つに整理できます。
4.1. 自社構築が向いているのはどんな企業か?
以下のいずれかに当てはまる企業は、自社構築を検討する価値があります。
-
継続的に多数の製品・ソフトウェアを開発しており、SBOM運用を長期的な資産にしたい
-
セキュリティ・開発の専門人材を確保できる、または育成する余力がある
-
自社独自のシステム構成に合わせた解析ルールが必要
4.2. 外部活用(商用ツール・外部委託)が向いているのはどんな企業か?
以下のいずれかに当てはまる企業は、商用ツール導入または外部委託の活用が現実的です。
-
SBOM対応の専任担当者を置く余力がない
-
CRAの適用時期や、JC-STARのラベル取得を目指す時期までに、必要なSBOM運用体制を整える必要がある
-
対象製品数が少なく、専用の解析基盤を持つほどの規模ではない
専門人材や開発リソースが限られる場合は、まず商用ツール導入や外部委託で運用を開始し、体制が整った段階で一部を内製化する、という段階的な進め方も選択肢の一つです。
4.3. 外部委託すれば自社の責任はなくなるのか?
なくなりません。
SBOM作成や脆弱性解析を外部に委託しても、対象範囲や解析結果を確認し、自社製品の脆弱性管理につなげる責任まで外部化できるわけではありません。
CRA上の製造者としての義務についても、委託先に移るわけではない点は同様です。
特に規制対応を目的とする場合は、納品されたSBOMを継続的に確認し、製品構成の変更に応じた更新を適切に管理できる体制もあわせて検討しておく必要があります。
5. SBOMツール選定で失敗しないためのチェックポイントは何か?
選定時は、対応フォーマット・データの取り扱い・運用サポート体制に加え、解析方式や継続的な脆弱性管理への対応まで確認します。
経済産業省の「SBOM導入の手引 Ver.2.0」でも、対応フォーマット・コンポーネント解析方法・サポート体制・他ツールとの連携・提供形態・対応開発言語などが、SBOMツールの選定観点として例示されています。
(出典:経済産業省「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引 Ver.2.0」)
5.1. 対応フォーマットは十分か?
SPDXやCycloneDXなど、業界標準フォーマットに対応しているかを確認します。
提出先の規格や取引先が指定するフォーマットに対応していないと、後から作り直しが必要になることがあります。
5.2. データの取り扱いは安全か?
SBOMツールは、解析方式によってソースコード・ファームウェア・バイナリなど機密性の高いデータを扱う場合があります。
特にクラウド型サービスを利用する場合は、どのデータが外部へ送信・保存されるのかを確認します。
スタンドアロン環境やオフライン環境で完結するツールであれば、解析データを外部クラウドへ送信・保存することに伴う情報漏洩リスクを抑えやすくなります。
5.3. 運用・サポート体制は整っているか?
脆弱性データベースの更新頻度や、導入後の技術サポート・バージョンアップ対応の有無を確認します。
外部委託を利用する場合は、診断後の改善提案や再診断まで対応してもらえるかどうかも、選定時の重要な判断材料になります。
5.4. 解析方式・対象データは自社製品に合っているか?
ソースコード解析・バイナリ解析・パッケージマネージャー連携など、ツールによって解析方式は異なります。
IoT機器・組み込み機器ではソースコードを入手できないサードパーティ製コンポーネントやファームウェアを扱うことも多いため、自社製品の開発言語・OS・ファイル形式に対応した解析方式かどうかを確認します。
5.5. 継続的な脆弱性管理・外部連携に対応できるか?
自社の運用要件に応じて、検出精度(誤検出・未検出)の確認、CI/CDパイプラインとの連携、VEX(Vulnerability Exploitability eXchange)対応などの機能も確認します。
VEXは、SBOMに含まれるコンポーネントの脆弱性が製品に実際に影響するかどうかなどを示す情報です。
6. SBOMツール導入の費用はどう考えればよいか?
外部ツールの費用は、利用ユーザー数・対象製品数・解析データ量・利用機能・オンプレミス/クラウドなどの条件によって大きく異なるため、一律の相場を示すことは困難です。
自社構築の場合も、ツールそのものの費用だけでなく、環境構築・検証・担当者教育・脆弱性情報との連携・継続的な保守更新にかかる人件費まで含めて評価する必要があります。
|
方式 |
主なコスト構成 |
|
自社構築(OSS) |
開発・環境構築・検証・担当者教育・保守・脆弱性情報との連携にかかる人件費 |
|
商用ツール導入 |
ライセンス費用・初期設定・運用担当者の工数 |
|
外部委託 |
初回解析費用・製品追加時の費用・アップデート時の再診断/継続支援費用 |
上記の表は費用構成の目安であり、具体的な金額は製品規模・診断範囲・契約条件によって大きく異なるため、個別に確認することを推奨します。
7. よくある質問
7.1. SBOMツールは無料版でも十分か?
無料のオープンソースツールでもSBOM生成や脆弱性照合が可能なものがあります。
ただし、検出結果の精査、ツール・脆弱性DBの更新、問い合わせ対応、規制要件への適合確認などを自社で担う必要がある場合があります。
規制対応など継続的な運用が前提の場合は、有償ツールやサポート付きサービスの活用も検討に値します。
7.2. SBOM作成にはどれくらいの工数がかかるか?
SBOMファイルの生成自体は、ツールによっては短時間で完了する場合があります。
一方、初回導入では対象範囲の整理、解析結果の精査、コンポーネント名・バージョン・ライセンスの確認、運用ルールの策定などに相応の工数がかかるため、対象製品の規模やコンポーネント数に応じて計画しておく必要があります。
継続運用でも、ソフトウェアコンポーネントの追加・変更を伴うアップデート時などには、SBOMへ差分を反映する工数を見込んでおく必要があります。
7.3. 内製から外部委託への切り替えは可能か?
可能です。
運用途中で自社の体制だけでは対応しきれなくなった場合、一部の製品・工程だけを外部委託に切り替えることもできます。
逆に、外部委託で運用ノウハウを蓄積したうえで、段階的に内製化を進める進め方も選択肢の一つです。
8. まとめ
SBOMツールの選定は、自社の製品規模・専門人材の有無・制度・規制対応までの猶予期間をふまえて判断することが重要です。
体制が整っていない段階では、商用ツール導入や外部委託を活用しながら運用を軌道に乗せ、必要に応じて内製化を検討する進め方が現実的です。
ただし、外部を活用する場合も、自社製品の脆弱性管理につなげる最終的な責任は自社に残ることを踏まえて体制を検討することが重要です。
9. SBOMツール選定・IoT機器のセキュリティ対応でお悩みの方へ
9.1. SBOMツールの導入・選定にお困りの方へ
「SBOMスキャナ」は、監視カメラやIoT機器の組み込みソフトウェアを分析し、SBOM生成から脆弱性照合までをワンステップで行えるツールです。
スタンドアロンPCで動作するため、バイナリデータを社外に出さずに運用でき、PCへのソフトウェアインストールのみで導入できます。
9.2. 開発段階からの脆弱性対策を相談したい方へ
「IoT脆弱性診断」は、企画・設計段階から出荷後まで、複数のタイミングでIoT機器のセキュリティリスクを評価するサービスです。
ハードウェア・ファームウェア・機器仕様・アップデート方式の4層を対象に診断し、報告書提出後の改善提案や再診断までを一貫してサポートします。
弊社、サイエンスパーク株式会社は1994年の創業より、ソフトウェア・ハードウェアのセキュリティ対策を30年以上に渡り続けてまいりました。
セキュリティリスクの診断から対策導入・運用までのお手伝いが可能ですので、お気軽にお問い合わせくださいませ。ご相談だけでも大歓迎です。
参考情報・出典
・経済産業省「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引 Ver.2.0」
・IPA「セキュリティ要件適合評価及びラベリング制度(JC-STAR)」
・IPA「★3(レベル3)適合基準・評価手順(評価手法・評価ガイド)」
・OMB「M-26-05: Adopting a Risk-based Approach to Software and Hardware Security」
・Regulation (EU) 2024/2847 (Cyber Resilience Act)