自動車業界のSBOM活用｜法規対応と脆弱性管理を効率化する実践ポイント

作成者: 高橋和晃｜2025/10/31

現代のソフトウェア開発では、複数のOSSが利用され、ソフトウェアの構造が複雑化しています。

この複雑さを可視化し、ライセンス管理や脆弱性管理を効率化する手段として「SBOM（Software Bill of Materials：ソフトウェア部品表）」が注目されています。

SBOMは、ソフトウェアを構成するコンポーネントや依存関係、ライセンス情報を一覧化し、ソフトウェアの構造を一目で把握できるようにするものです。

サイバーセキュリティの重要性が増す中、EUでは2024年12月にCRA（Cyber Resilience Act：欧州サイバーレジリエンス法）^[1]によって、SBOMの作成・保持が義務化されました。

自動車業界では現時点で車両を対象としたSBOM作成・保持義務はないものの、脆弱性管理の効率化手段としての活用が期待されています。

本記事は、自動車業界におけるSBOMの具体的な活用方法や、その導入に伴う課題について解説しています。

自動車におけるSBOMの必要性

自動車業界では、車両のサイバーセキュリティに関連する国連の法規として「UN-R155」と「UN-R156」が存在します。

UN-R155：サイバーセキュリティが担保された車両を開発するための体制やプロセスについての要件を規定

UN-R156：車両のソフトウェアアップデートをセキュアに実施・管理するためのシステム・プロセスについての要件を規定

これらの法規を遵守することは、各自動車メーカー（OEM）にとって必須事項となっています。

UN-R155やUN-R156では、コンポーネントのリスク評価やソフトウェアの構成管理が求められていますが、CRAのようにSBOMを明確に管理することを義務付けた記載はありません。ただし、UN-R155では車両のライフサイクル全般にわたる脆弱性対応が求められており、車両を対象とした脅威・脆弱性の監視が必要となります。

このような背景から、車両に含まれる脆弱性を効率的に監視する手段として、SBOMの活用が注目されています。

今後のSBOM活用動向について

現時点では明確にSBOMの作成・管理が義務づけられていませんが、自動車に関連したSBOMの記載はいくつかあります。

ISO/SAE 21434：UN-R155から参照される標準規格です。構成情報管理の例として部品表、ソフトウェア構成の記載があります。

CyberSecurity Best Practice for the Safety of Modern Vehicles Update 2022^[2]：UN-R155,156の対象外国であるアメリカでNHTSAが発行したガイダンスです。車両のサイバーセキュリティを確保する要件が記載されており、構成管理要件の具体的な方法としてSBOMが挙げられています。

コネクテッドカー規制^[3]：アメリカの法律です。コネクテッドカーや自動運転機能を持つ車両を対象としており、当初、SBOMの提出が求められていました。ただし、最終的にSBOMを当局に提出する要求は、運用負荷の増加、SBOMの記載内容・更新タイミングの曖昧さなどから除外されました。

このように、SBOMはサプライチェーン攻撃への対策として自動車業界でも注目されています。ただし、SBOMの導入・活用にはコネクテッドカー規制や経済産業省が発行した手引書「ソフトウェア管理に向けたSBOM（Software Bill of Materials）の導入に関する手引 ver 2.0」^[4]で言及されているような、作成コストや管理体制などの課題が存在します。

現在の課題については、業界全体でのルールの成熟や、ツールの進化・普及に伴い、将来的に解消される可能性があります。なお、自動車業界では2025年中に業界団体のJ-Auto-ISAC^[5]からSBOMに関するガイドラインが発行される予定です。

図：複数のサプライヤが絡む場合のSBOMの課題

SBOM導入時の課題

冒頭で述べた通り、現在、自動車を対象としたSBOMの作成は法規で義務付けられていません。しかし、SBOMの活用が最も期待されるのは、UN-R155で求められている車両に関連する脆弱性対応への支援です。SBOMを活用することで、脆弱性管理の効率化が期待できます。

本記事では、今後の脆弱性対応を効率的に行うためSBOMを活用する際に直面する課題について解説していきます。

適用範囲・精度の課題

SBOMの導入を検討する際、大きく問題となるのは「適用範囲」と「求める精度」と考えられます。

どこまでの範囲を対象とし、どの程度詳細にSBOMを作成するかによって、対応コストや運用の難易度が大きく変わります。

理想的には、車両の構成要素に含まれるすべてのソフトウェアをSBOMで正確に管理することが望ましいですが、以下の課題があるため、完全な管理は現実的に難しいと考えられます。

ソフトウェアの種別による課題
SBOMを用いて脆弱性を管理する場合、OSSはSCAを使うことで脆弱性情報を集められますが、COTS、プロプライエタリソフトウェアは別途管理をする必要があります。
- - OSS（オープンソースソフトウェア）: SCA（Software Composition Analysis、ソフトウェア構成分析）ツールを使用することで、構成要素の特定や脆弱性情報の自動確認が可能です。
  - COTS（Commercial Off-The-Shelf）: 既製品として販売・リース可能なソフトウェア。提供元から構成情報が得られない場合、詳細不明として管理する必要があることがあります。
  - プロプライエタリソフトウェア: 独自開発のソフトウェア。OSSと異なり、自動的な脆弱性確認が難しく、提供元に依存する場合があります。

完全性の課題
SBOMの生成にはツールを使用することが推奨されますが、以下のような問題が発生する可能性があります。
- - 誤検出（過検出・検出漏れ）: コードマッチングや文字列検出などの手法によるSBOM生成では、対象ソフトウェアによって検出精度にばらつきが生じる可能性があります。
  - 階層管理の難しさ: ソフトウェアのコンポーネントを深い階層まで管理するほど、検出率が低下し、誤検出が増える傾向があります。
  - 運用・保守の不透明さ: 利用するツールの違いや適用範囲を取り決めないと、作成されたSBOMに不備が生じる可能性があります。

コストの問題
SBOMの導入には以下のコスト関連の課題が伴います。
- - フォーマットの多様性: SBOMには複数のフォーマット（SPDX、CycloneDX 等）が存在します。自身がSBOMを提供する立場の場合、顧客Aと顧客Bから求められる形式が異なる際には、複数種類のSBOMを整備する必要があります。
  - ツールの限界: ソフトウェアを解析する使用するツールが対応していない場合、手動運用など追加のコストが発生します。
  - 契約・ライセンスの制約: ソフトウェア提供元がSBOMの開示を拒む場合を考える必要があります。また、受け入れ側がSBOMを作成する場合でも、正確にスキャンできているかを確認するのは難しいと考えられます。

図：SBOMを作成するにあたっての課題

発生した脆弱性情報の取り扱い

SBOMを活用する際の第二の課題は、検出される大量の脆弱性情報をどのように管理するかという点です。

SBOMを利用した脆弱性確認では、ソフトウェア部品情報と脆弱性情報の照合が自動化されます。その結果、リスクが低い脆弱性や使用していない機能に関する脆弱性も網羅的に検出される傾向があります。

実際にNDIASでツールを用いて製品に含まれる脆弱性を確認したところ、多いもので1000個以上の脆弱性が検出されました。

検出される数に関しては、対象製品がミドルウェアを多く使っているか、古いバージョンのソフトウェアを使っているのか（出荷後に脆弱性が報告されているか）等が関与すると考えられますが、それでも数としてはかなり多い認識です。

こうした膨大な脆弱性情報を効率的に管理する方法を事前に整理しておかなければ、かえって確認作業のコストが増加し、日々の脆弱性対応が非効率になる可能性があります。

自動車業界では、製品開発を担当する部門と、脆弱性監視やセキュリティ活動を専門に行う部門（PSIRT部門等）が分かれているケースが一般的です。

しかし、脆弱性情報には専門的な知識が必要な場合や、脆弱性自体の情報が不十分な場合が多くあります。そのため、セキュリティに詳しくない部門に確認を依頼すると、想定外に長い時間を要したり、QAなどが多発して運用コストが大幅に増加する可能性があります。

課題に対するアプローチ

前述の「1. SBOMの適用範囲」と「2. 発生した脆弱性の取り扱い」に関する課題へのアプローチとして、大きく以下の3点が考えられます。

SBOM導入の目的を定める
運用・対応方法を事前に検討する
定期的な見直しを実施する

１．SBOM導入の目的を定める

SBOMの導入にあたっては、目的を具体的に定めることが重要です。前述の通り、現状では誤りや漏れのない完全なSBOMを作成するのは難しいため、SBOMを活用する目的を明確にすることで効率的な運用が可能になります。

具体的な目的の例として以下が挙げられます。

車両が外部攻撃者によって悪用される可能性のある脆弱性を早期に検知したい。
名前付きの脆弱性（例：CVE）が公表された際に、対象製品を迅速に特定したい。
各脆弱性の対応状況を細かく管理したい。

例えば「外部攻撃者によって悪用されやすい脆弱性を早期に検知すること」を目的とする場合、すべてのECUを網羅するSBOMを作成するのではなく、Bluetooth、USB、Wi-Fi、リモートキーなど外部インターフェイスを持つECUを優先的に管理する方針を立てることが考えられます。また、リスクアセスメント結果を活用して、リスクの高い箇所を優先的にSBOMで管理することも効果的です。

目的に応じて管理方針や対象範囲が変わるため、SBOM導入に際して何を達成したいのかを明確に整理することが重要です。

２．脆弱性の対応・運用方法を事前に検討する

SBOMを活用して脆弱性を管理する場合、SCA（Software Composition Analysis）ツールを用いた管理方法が想定され、ツールを用いた脆弱性検出では大量の脆弱性が検出されることが予想されます。そのため、対応方針を事前に検討しておくことが必要です。主な対応方針として以下が考えられます：

１．確認する数を減らす

脆弱性の確認対象を絞り込むことで、管理の負担を軽減できます。例えば、CVSSスコアやPoC（攻撃コードの存在）などを活用して脆弱性の危険度を評価し、対応が必要な脆弱性を優先する方法が有効です。また、製品のアーキテクチャやリスクを事前に把握し、これを基に対応方針を立てることも効果的です。

２．確認する速度を早くする

脆弱性対応の効率化には、情報共有がポイントです。同じ脆弱性を複数の製品部門で個別に確認するのは非効率なため、脆弱性の概要や該当するロジックのパターンを取りまとめ、各部門に明確な情報を伝えることで確認プロセスを迅速化できます。

また、大量の脆弱性を管理するためには、以下の点も事前に整理する必要があります。

脆弱性の確認結果をどのように管理するか。
サプライヤから提供されるSBOMをどのタイミングで取り込むか、等

これらの考慮点を既存の社内プロセス・ツールと整合性を持たせることが重要です。

３．定期的な見直しを実施する

SBOMを用いた脆弱性対応が本来の目的に沿って効果的に運用されているかどうか、定期的に見直すことが重要です。運用を進める中で以下のような課題が明らかになる可能性があります。

SBOMの生成や維持にかかるコストが当初の想定よりも高い。
検出される脆弱性が多すぎて対応が追いつかない。

これらの課題を解決することで、目的に沿った効率的な脆弱性確認が可能になります。

また、定期的な見直しを通じて、SBOM生成ツールの機能改善などを取り入れることができます。

このように実運用を進める中で、新たな課題が発生する可能性が考えられるため、導入段階では予測できなかった課題が発生する可能性を考慮し、PoC等、スモールスタートで運用を開始することが推奨されます。

まとめ

本稿では、自動車業界におけるSBOMの現状と、「日々の脆弱性管理をSBOMで効率化したい」というモチベーションを持つ方に向けて、課題やポイントを解説しました。

SBOM導入においては、対象範囲や管理方針を事前に整理し、社内の体制やプロセスを考慮した上での検討が重要です。これにより、導入後の運用がスムーズに進むだけでなく、効果的な脆弱性管理が実現できます。

NDIASは、自動車業界に特化したセキュリティ会社で脆弱性の監視ノウハウ、社内プロセス構築経験、リスクアセスメント経験を保有しております。特に日々の脆弱性監視については数多くのご支援経験、ノウハウがあります。加えて、本稿で記載したお悩みに対応するため、SBOMの導入支援サービスも提供しております。

SBOMの活用、脆弱性管理等に対してお悩みがありましたら是非お問い合わせください。