一般社団法人Japan Automotive ISAC（以下J-Auto-ISAC）は、日本の自動車および関連するサービスの安全・安心の確保とサイバーセキュリティの強化を目的に、2021年2月に設立されました。2025年9月現在で120を超える会員を有し、関連団体であるJAMA（一般社団法人日本自動車工業会）やJAPIA（一般社団法人日本自動車部品工業会）、JSAE（公益社団法人自動車技術会）、JASPAR（一般社団法人Japan Automotive Software Platform and Architecture）に加え、国内の他の業界のISAC（Information Sharing and Analysis Center）や米国のAuto ISAC（Automotive-ISAC）とも協力して活動を続けています。

図表1は、J-Auto-ISACの組織体制を示したものです。私が運営するサイバーセキュリティエコシステム構築センターでは、各業界団体が連携したシームレスなサイバーセキュリティの品質向上活動が行える状態を目指した活動を進めています。

ここ数年、クルマのサイバーセキュリティに関する各国政府当局の目が非常に厳しくなっています。大きな理由の一つが自動運転ソフトウェアに対するリスクで、外部からのハッキングによる安全喪失の可能性などが指摘されています。

自動車の車両構造基準などを検討する国連の作業部会「WP.29（World forum for harmonization of vehicle regulations working party 29）」で2016年から進められていたサイバーセキュリティに関する法規は、2020年6月に「UN-R155/156」として正式合意されました。UN-R155は車両のサイバーセキュリティとCSMS（Cyber Security Management System）、UN-R156は車両のソフトウェアアップデートとSUMS（Software Update Management System）に関する法規となっています。

すでに日本やEUでは国内法への取り込みと施行が完了している他、韓国やインド、台湾などのアジア諸国でも順次導入が進んでいます。なお、中国では独自の規格であるGB 44495（自動車完成車情報セキュリティ技術要件）が間もなく導入される予定です。UN-R155/156とGB 44495の大きな違いとして挙げられるのが車両型式試験で、前者がOEMによる実施結果を行政が確認するのに対し、後者では中国当局自身が実車試験を行う点です。試験方法の詳細は開示されていませんが、おそらくハードルは非常に高いと考えられます。

UN-R155/156以外にも、排ガス・燃費・バッテリー耐久性などに関わるシステムの改ざん防止対策を定めた「Euro7（ユーロ7）」、速度計・走行距離計の値や表示を改ざんから保護する「UN-R39」など、サイバーセキュリティやアンチタンパリングに関連したさまざまな規則が発令されています。これらの中にはサードパーティなどの関係者間での議論を要するものや、データ開示の強化などサイバーセキュリティと一部相反する要求を含むものもあるため、対応には十分な留意が必要です。

近年、クルマの利便性や安全性はソフトウェアによって大きな進化を遂げてきました。また、CASE（Connected, Automated/Autonomous, Shared & Service, Electrification）の潮流によって一層の電子化が進み、クルマには膨大な数の制御ユニットやセンサーが搭載されています。さらに、クルマに期待される価値が肥大化し、内外のシステムとの連携によって実現する機能やサービスが増加したことで、サプライチェーンを構成するプレーヤーも大きく変化しています。その結果、クルマのライフサイクル全体におけるセキュリティ保護の対象が爆発的に拡大してきています。

図表2は、クルマのセキュリティ脅威や脆弱性への対応に関するスコープと運用を示したものです。クルマの内外（In-Car/Out-Car）での対応を前提に、情報収集・分析・トリアージ・対応というOODA（Observe, Orient, Decide Act）ループを回し続けていくことになります。

■継続的サイバーセキュリティ活動とは

継続的サイバーセキュリティ活動とは、クルマの安全・セキュリティ品質を確保するために、リスクを能動的に把握しながら対応していくことを指します。これには、企画開発から生産、運用、廃棄というライフサイクル全体にわたって図表2で示したOODAループの継続的な実施が必要で、ここが従来の品質保証の観点にはないユニークなポイントとなります（図表3）。

■継続的サイバーセキュリティ活動の基本プロセス

図表4は、継続的サイバーセキュリティ活動の運用フェーズにおける脆弱性ハンドリングのプロセスを示したもので、活動は情報の監視、イベント評価、脆弱性分析、顕在化した脆弱性への対応という四つのフェーズで構成されます。サイバーセキュリティ情報は、各フェーズで精査された後にリスク評価が行われ、脆弱性管理またはサイバーセキュリティインシデントレスポンスのいずれかの対応が実施されます。

ただし、すでに市場で問題が発生している場合は、OEMの判断で顕在化した脆弱性への対応が必要になります。また、図表内の緑色で示した部分はトリアージによって保留状態とされたものを表していますが、将来的に新たな脅威の対象となる可能性があるため、継続した監視が必要となります。

ライフサイクル全体にわたる脆弱性管理では、現在進行中の車両・部品開発への情報展開、次期開発での反映や量産仕様変更などに同期した改善が想定されます。そのため、サイバーセキュリティ情報の監視はOEMとサプライヤーの双方が実施し、イベント評価以降のプロセスは内容によって一方または両者が協調して行うことになります。

継続的サイバーセキュリティ活動には、サプライチェーンを構成するあらゆるプレーヤーの参加が求められます。しかし、今後も続くリスクの増大や法規制への準拠などを考えると、人材・コスト・工数の全てにおいて個社単独での対応は困難となってきています。こうした状況の中、サプライチェーン全体における共通の管理基盤として期待されているのがSBOM（Software Bill of Materials）です。

SBOMは製品に含まれるソフトウェアを可視化した一覧表で、コンポーネントとその依存関係、ライセンスデータを一意に識別する形式的で機械可読なメタデータと定義されています。SBOMはサプライチェーンを通じた構成管理や脆弱性管理に有効なことから、自動車業界での共通基盤として整備が進められています。また、ISO/SAE 21434では要求事項としてソフトウェアの構成管理（BOM）が例として挙げられており、CRA（Cyber Resilience Act：欧州サイバーレジリエンス法）でもその活用が示唆されています。

■SBOMの活用例

■SBOMの効果

発見された脆弱性の影響を迅速かつ効率的に特定するには、サプライチェーン全体での部品情報の共有が重要になりますが、ここでSBOMが大きな効果を発揮します。サプライチェーンを通じて集約されたSBOMを脆弱性情報と突合することで、影響を受けるソフトウェアの特定に必要な工数の削減が可能になる他、万一インシデントが発生した場合にも素早い対応が可能になります。

SBOMは、脆弱性管理を含むセキュリティコミュニケーションの共通言語と言える存在です。SBOMデータの共有によって依存性の確認が迅速化され、他社で発見された問題が自社のプロダクトやサービスに与える影響の有無を常時漏れなく把握できるようになります。SBOMの有効活用は、プロダクトの開発と運用の安全に客観性を与える手段とも言えるでしょう。

■SBOMで扱うソフトウェアの種別と関係

従来の車載ソフトウェアはプロプライエタリ^※が大半で、そのIPはサプライヤーに帰属する場合がほとんどでした。しかし、SDVの場合にはOSSの活用が不可欠なため、使用するソフトウェアを含めた開発プロセスでの脆弱性検証はもちろん、運用段階においてもSBOMの活用は必須と考えられます。

OSSに関しては、それを管理する団体やコミュニティーがSBOM情報を公開してくれることが望ましいのですが、現実的には期待できないと考えるのが妥当です。また、OSSにサポートを付属して有償のCOTS（Commercial Off-The-Shelf：市販ソフトウェア）として販売するケースもありますが、その一環として使用するOSSや別のCOTSの情報をSBOMに登録することはできると思います。

また、プロプライエタリソフトウェアのCOTSを利用する際ベンダーがSBOM情報を提供しない場合は利用者側でのSBOMへの登録が、ベンダーがSBOM情報を提供する場合は利用者側での情報のマージが必要になります。さらに、プロプライエタリソフトウェアでOSSを使用する場合は、利用者側でSBOM情報の登録が必要になるということも考慮しておかなければなりません。これには、ソースコードを解析してSBOM情報を抽出する必要があります。

※開発者や組織が所有権を独占し、利用方法に制限を設けているソフトウェアのこと。

■SBOMの運用責任

他社から納品されたプロプライエタリソフトウェアを使用する場合には、そこにOSSやCOTSが含まれていることがあるため、SBOM情報の登録が必要です。この際、開発側と使用側のどちらで登録するのかの取り決めが必要となります。使用側が登録する場合はソースコードを解析してSBOMを抽出することになるため、開発側にソースコードの提供を求めることになります。

一方、ソースコードを提供しない場合は、開発側で作成したSBOM情報を使用側に渡す、もしくはSBOMの運用を開発側の責任で実施する必要があります。このように、プロプライエタリソフトウェアでのSBOM運用には、契約単位での対応が必要になります。

■自動車業界におけるSBOM活用の課題

脆弱性管理はクルマにおけるSBOM活用の理解しやすいユースケースと言えますが、自動車業界に特有の課題も見えてきています。

また、脆弱性を検査してデータを出力するだけでは、SBOMを十分に活用しているとは言えません。例えば、開発側が複数のSBOMデータを提出することはよくあることですし、運用側がパッチを含めたアップデートを容易に実施できるとは限りません。また、運用側は複数のチームを横断的に管理、評価していく必要があります。つまり、SBOMの導入に当たっては、SBOMを利用した開発側の監視と運用体制の整備が鍵となります。

現時点では、どのようなソフトウェアに対してもSBOMデータを正確に出力してくれる魔法のようなツールはありませんし、提出されたSBOMデータを使って脆弱性管理の負担軽減や脅威分析の改善を行うためには、その準備が重要であることを理解しておかなければなりません。

ここからは、本稿で取り上げてきた課題に対するJ-Auto-ISACの取り組みを紹介します。

■サプライチェーンに関する取り組み

サプライチェーンに関しては、『クルマのサプライチェーンにおけるサイバーセキュリティの取り組み』という文書を公開しています。ここでは、クルマのライフサイクル全体におけるOEMとサプライヤーとの体制構築および役割分担のあるべき姿について丁寧に解説しています。ぜひダウンロードして一読していただければと思います。

クルマのサプライチェーンにおけるサイバーセキュリティの取り組み
https://j-auto-isac.or.jp/document/#1024

■SBOMに関する取り組み

自動車業界におけるSBOM活用の課題解決に向け、2023年4月からワーキンググループを立ち上げています。ここでは、SBOMの作成や活用のガイドラインとなる「SBOM文書」の作成を進めていて、課題の共有やスコープの決定、市場や法規動向の調査などを踏まえながら、バージョン1.0を内部でリリースした段階です。この文書は、「SBOMを取り扱う上で求められる活動」、「活動をサポートするナレッジ」、「SBOMのユースケース」で構成され、また文書体系はISO/SAE 21434や24089を参考にしています。

また、継続的サイバーセキュリティ活動の中でのSBOMの活用法については、先に紹介した『クルマのサプライチェーンにおけるサイバーセキュリティの取り組み』の内容に沿った形で解説しています（図表5）。

■今後の活動について

SBOM文書に関しては、JAMAやJASPARなどの業界団体と連携して、2025年度末には初版として一般公開する手続きを進めています。

さらに、2025年度末もしくは2026年初頭のリリースを目指して、第2版の作成も進行中です。ここでは、脆弱性以外のライセンス管理などのユースケースに加え、プロプライエタリや有償ソフトウェアも対象にするなど、初版の段階でカバーできなかった内容も取り込んでいく予定です。

車の価値を形成する手段がメカ中心から制御中心に変化し、各種機能を実現する手段もソフトウェア中心に移行しています。自動車製造の原価に占めるソフトウェアの比率はすでに40％にも達していると言われており、これがSDVの進化によって60％を超えるという試算もあります。

製品を支えるサプライチェーンの複雑化が加速する中、ライフサイクル全体にわたってクルマを保守・運用していくためには、脅威や脆弱性との戦いは避けられません。これには、さまざまな法規への準拠や認証取得が必要な上、サプライチェーン全体でのサイバーセキュリティ能力の底上げも必須で、その対応を間違えると企業存続にも関わる問題になってきます。

こうした状況の打開には、個社単独での取り組みに加えて、J-Auto-ISACの活動に代表される共通基盤の活用も必要になってきます。また、業界全体の視点、さらにはその枠を超えた対応や管理が、今後ますます重要になってくると考えています。