1. はじめに

1-1. 自動車もサイバーセキュリティが必要

“ネットワークの一部”となった自動車のサイバーセキュリティリスク

2015年、米国において、走行中のジープ・チェロキーのコントロールを外部から奪うという、センセーショナルなハッキング事例が公開されました。対象となった車両は、車載インフォテインメントシステムの通信モジュールを介して外部ネットワークに接続されており、これを経由して車両内部への不正アクセスが行われました。
このハッキング事例は、一般販売されている車両の主要機能（走る、曲がる、止まる）の制御を、車両に一切触れることなく奪うことができるという点でそれまでの事例とは一線を画し、自動車がネットワークに接続されることのリスクを明確に示すものでした。
実際にクライスラーはこの脆弱性への対処として、140万台にも及ぶリコールを行いました。

CASE領域の変革とサイバーセキュリティリスクの増大

自動車のサイバーセキュリティリスクを増大させている要因は、ネットワークへの接続だけではありません。CASE(*1)に代表される自動車の変革の様々な側面が、それぞれにサイバーセキュリティリスクの増大を招いており、こうしたリスクへの対処が自動車業界全体の急務となっています。

1-2. 型式認証時のレギュレーション

UN-R 155とUN-R156

自動車のサイバーセキュリティリスクが増大している状況を受けて、国連の下部組織である自動車基準調和世界フォーラム（以降 WP.29）では、自動車サイバーセキュリティに関する2つのレギュレーションUN-R155とUN-R156が合意されました。これらはいずれも、車両型式認証を取得する際の追加要求を規定しており、UN-R155では自動車のサイバーセキュリティ及びその管理システムに関する要求を、UN-R156ではソフトウェアアップデートおよびその管理システムに関する要求を扱っています。これらのレギュレーションに対しては1958年協定に加盟している全58か国が批准しており、欧州では新型車両の型式認証は2022年7月以降、継続生産車両は2024年7月以降、適合が必須となっています。日本もこれらのレギュレーションに批准しており、無線ソフトウェアアップデート対応車両では欧州同様のタイミングで適合必須、無線ソフトウェアアップデート非対応車両では新型車が2024年1月以降、継続生産車が2026年5月以降、適合必須となります。
これらのレギュレーションにはそれぞれ、適合のガイドラインとして機能する規格が存在しており、UN-R155にはISO/SAE 21434が、UN-R156にはISO 24089がそれぞれ対応しています。

認証の仕組み

自動車サイバーセキュリティに関するレギュレーションUN-R155の認証は、新型車両の型式認証の際に国の任命を受けた認証機関により実施されます。OEMは認証機関に対し、個別の車両型式の設計においてサイバーセキュリティリスクが十分に低減されていることを論証するとともに、車両が適切なサイバーセキュリティ管理システム（CSMS）の下で開発されたことの証明も併せて行う必要があります。個別の車両型式のセキュリティは型式認証の都度個別に論証する必要があるのに対し、CSMSの証明は一度認証されれば組織に「CSMS適合証明」が発行され、証明書は有効期間中であれば他の型式認証にも利用可能です。CSMS適合証明は、プロセスの変更がない限り3年間有効となります。

1-3. 主な国際規格

ISO/SAE 21434　自動車サイバーセキュリティの概要

ISO/SAE 21434は、路上を走行する車両内部のE/Eシステムのエンジニアリングにおける、サイバーセキュリティ観点でのプロセス定義およびリスク管理をガイドする目的で作成された国際規格です。対象となるフェーズはコンセプトから廃棄に至る自動車のライフサイクル全体であり、対象となるアイテム、コンポーネントには、車両および車両のシステム、部品、ソフトウェアに加え、ネットワークにより車両へ繋がる外部デバイス（カーナビ、ETC車載機など）も含まれます。ISO/SAE 21434は前述の国際レギュレーションの内UN-R155に対応する規格となっており、要求事項を正しく理解して組織および製品に適用することによって、UN-R155の規定を満足することが可能となります。

ISO/SAE 21434はClause1からClause15までの15節およびAnnex A～Hの付属書で構成されています。各節の内容は以下の通りです。Clause5からClause15が主要な要求事項になりますが、Clause4でその前提となる道路車両のサイバーセキュリティ エンジニアリングへのアプローチの背景と観点について述べられています。

Clause 1：適用範囲
Clause 2：引用規格
Clause 3：用語、定義および略語
Clause 4：一般的な考慮事項
Clause 5 : 組織的なサイバーセキュリティ管理
Clause 6 : プロジェクト依存のサイバーセキュリティ管理
Clause 7 : 分散サイバーセキュリティ活動
Clause 8 : 継続的サイバーセキュリティ活動
Clause 9 : コンセプト
Clause 10 : 製品開発
Clause 11 : サイバーセキュリティ妥当性確認
Clause 12：生産
Clause 13：運用および保守
Clause 14：サイバーセキュリティサポートの終了および廃車
Clause 15：脅威分析およびリスクアセスメント手法

2. ISO/SAE 21434の詳細

ISO/SAE 21434の主要な要求事項を定義しているClause5からClause15の内容について以下で解説します。

Clause 5:組織的なサイバーセキュリティ管理

組織として取り組むべき要求事項が定義されています。要求の軸は、サイバーセキュリティリスクを適切に管理するための仕組み、およびサイバーセキュリティ文化の構築と維持です。具体的には、以下の仕組みが必要です。

• 標準プロセス定義（ルール、役割と責任）
• リソース提供
• 能力管理：スキル、知識だけなく、人員のサイバーセキュリティに対する意識付けも考慮する
• ツール管理：開発フェーズだけなく、生産・製造フェーズで使用するツールがサイバーセキュリティに与える影響を考慮する
• サイバーセキュリティ監査の実施：組織の標準プロセスのISO/SAE 21434に対する遵守をチェック
• 継続的な改善

ポイント：情報セキュリティマネジメントシステム（ISO27001）で要求されている組織的な活動と同じ項目が要求されています。また、サイバーセキュリティの前提として、品質マネジメントシステム（IATF16949）が確実に維持されている必要があります。個別にマネジメントシステムを構築するのではなく、情報セキュリティマネジメントシステム、品質マネジメントシステムとの統合方法を考えることが重要です。

Clause 6:プロジェクト依存のサイバーセキュリティ管理

製品開発プロジェクトの単位で実施すべき管理活動について、要求事項が定義されています。以下が主な要求項目です。

• サイバーセキュリティ関連活動の計画
• 製品サイバーセキュリティの論証（サイバーセキュリティケース）
• サイバーセキュリティアセスメント
• 生産に向けてのリリース：サイバーセキュリティケース、サイバーセキュリティアセスメント結果（実施した場合）から判定する

ポイント：計画策定に関しては、過去に開発したコンポーネントの再利用や既製品の採用といった戦略や、それに応じた組織標準プロセスのテーラリングからサイバーセキュリティ活動が計画される必要があります。（各サイバーセキュリティ活動が計画された根拠が重要です。）

Clause 7:分散サイバーセキュリティ活動

サイバーセキュリティ関連製品を分散開発する場合に適用される要求事項が定義されています。分散開発とは、開発、生産や脆弱性情報の監視など、一部のサイバーセキュリティ関連活動をサプライヤーに委託する開発を指します。これは、OEMに対するティア1、ティア1に対するティア2といったサプライヤーチェーンにおける委託開発が対象になります。以下が、発注者とサプライヤー間でサイバーセキュリティ活動を実施するための主な要求事項です。

• サプライヤーの開発能力
• サプライヤーへの明確な要求
• 発注者とサプライヤー間の責任分担

ポイント：活動の一部を外部業者に委託した場合でも、本規格の要求は例外なく適用されるという点です。

Clause 8:継続的サイバーセキュリティ活動

製品の脆弱性情報の収集と、それによって明らかになったサイバーセキュリティリスクの管理に関する要求事項が定義されています。これらの活動は、製品の開発中だけでなく、開発完了後も含めて継続的にサイバーセキュリティ管理を実施すべきものと位置づけられています。以下は、主な継続的なサイバーセキュリティ活動です。

• サイバーセキュリティ情報（インシデント、脆弱性情報）の監視とサイバーセキュリティ事象の判定
• サイバーセキュリティ事象の評価：弱点の特定
• 脆弱性の特定と管理

これらは、サイバーセキュリティの特質が強く表れている節の一つと言えます。機能安全における故障に起因する安全リスクとは異なり、サイバーセキュリティリスクは時間とともに変化する特徴があります。その要因は、新たな脆弱性や攻撃手法の発見などです。そうしたリスクの変動に適切に対処するため、製品のライフサイクルを通じて継続的に脆弱性情報の収集とリスクの管理を行うことが重要です。このような活動は一般的に、製品開発プロジェクトとは別の、PSIRT（Product Security Incident Response Team）と呼ばれる体制の下で実施されます。

ポイント：脆弱性の特定と管理を継続的に実施するために、開発対象の製品種類や特性、組織体制を考慮して、各社に適したPSIRTを構築することが重要です。

Clause 9:コンセプト

車両レベルで実施すべきサイバーセキュリティコンセプトの定義に関する要求事項が定義されています。コンセプト設計で定義される最重要要素はサイバーセキュリティゴールであり、これはサイバーセキュリティに関する最上位要求となります。サイバーセキュリティゴールは、車両レベルでの脅威分析およびサイバーセキュリティリスクアセスメント（TARA：Threat Analysis and Risk Assessment）を通じて定義されます。TARAの具体的な要求はClause 15に定義されています。以下は、コンセプト設計で実施する主な活動です。

• アイテム定義：車両レベルの機能、初期アーキテクチャをベースに定義
• サイバーセキュリティゴールの定義：TARA実施結果から導出
• サイバーセキュリティコンセプトの設計

ポイント：コンセプト設計の実施主体は主にOEMですが、コンセプト設計ではサイバーセキュリティのコア要素が定義されるため、サプライヤの立場においても本節の要求事項を正しく理解しておくことは重要です。

Clause 10:製品開発

サイバーセキュリティコンセプトに基づいて実施される開発全般に関する要求事項が定義されています。対象領域には、システム、ハードウェア、ソフトウェアが含まれており、サプライヤにおけるE/E製品エンジニアリング活動は基本的に全て対象となります。要求の大半は、上位要求を遵守しながら不具合のない製品開発を行うというエンジニアリングの基礎に基づくものです。これは、設計不具合やバグ自体がサイバーセキュリティ上の脆弱性となりうるためです。以下は、エンジニアリング領域における主な開発活動です。

• サイバーセキュリティ要求の仕様化とアーキテクチャ要素への割当て（システム/ハードウェア/ソフトウェアレベル）
• アーキテクチャ設計および分析（弱点の特定）
• サイバーセキュリティコントロールの実装
• サイバーセキュリティ要求仕様に対する検証（システム/ハードウェア/ソフトウェアレベル）

ポイント：開発の各タイミングでサイバーセキュリティ上の弱点を見つけ出して対処するというサイバーセキュリティ特有の要求も含まれています。開発中に検出された弱点は必要に応じてTARAを通じた分析にかけ、その対処を決定することが重要です。

Clause 11:サイバーセキュリティ妥当性確認

製品におけるサイバーセキュリティゴールの達成確認に関する要求事項が定義されています。エンジニアリングにおける最後の活動を扱っており、不合理なリスクが残っていないことを確認することが求められます。V字モデルに当てはめると、Clause 9 コンセプトの対抗位置になります。以下は、妥当性確認における主な活動です。

• 妥当性確認をどのように実施するかの戦略、妥当性確認計画の策定
• 妥当性確認（レビュー、テスト）の実施と結果の要約

ポイント：ペネトレーションテストを行う際、どこまでテストを実施するべきかを判断する基準にCALを使用することが可能です。

Clause 12:生産

製品の生産におけるサイバーセキュリティリスク管理に関する要求事項が定義されています。要求の趣旨は、開発からのサイバーセキュリティ関連要求を確実に生産の仕組みに反映することです。生産設備には、ネットワーク（イーサネット、CAN、LINなど）技術やソフトウェアツール（カメラデータ処理、シーケンサーなど）が使用されるため、生産プロセスのサイバーセキュリティ管理システムの確立が推奨されている点には注意が必要です。生産における主なサイバーセキュリティ活動は以下です。

• 生産の工程設計時に、サイバーセキュリティリスクアセスメントの実施
• 特定されたリスク低減方策のコントロールプランへの反映

ポイント：生産する製品のサイバーセキュリティに直接影響する工程（例えば、適合データの書き込み、フラッシュプログラミングなど）、製品に書き込むデータの管理に着目するとサイバーセキュリティ対策の労力を削減するこができます。

Clause 13:運用および保守

製品の開発完了からサポート終了まで継続する運用、保守に関する要求事項が定義されています。具体的には、Clause 8で述べたPSIRTによって、インシデントや脆弱性の対応が必要と判断された時に、ソフトウェアアップデートを含むインシデント対応を行います。設計不良等の内的要因以外に、新たな脆弱性や攻撃手法の発見といった外的要因によってもインシデント対応が必要になる点が、サイバーセキュリティに特有と言える部分です。以下は、運用・保守に関する主な活動です。

• サイバーセキュリティインシデント対応の計画策定
• 計画に基づいたアップデートの実装

ポイント：ソフトウェアアップデートの実施に関しては、ISO 24089を参照することになります。21434では、インシデント対応のためのソフトウェアアップデートと考えられていますが、製品の付加価値の面において、ソフトウェア機能の更新（例えば、ある機能の性能改善）を考慮することも重要です。

Clause 14:サイバーセキュリティサポートの終了および廃車

サイバーセキュリティに関するサポート終了の通知と、製品のセキュアな廃棄に関する要求が定義されています。廃棄については、製品が廃棄されるタイミングでメーカーやサプライヤに求められる活動はありませんが、製品をセキュアに廃棄できるように予め手を打っておくことがメーカー/サプライヤの責務となります。例えば、個人情報リセット機能の組込みや、ユーザーマニュアルへの廃棄手順の記載などがこれにあたります。

ポイント：車載システムが保有している個人情報や走行中に収集し保存されたデータの廃棄に関しては、国ごとの法規によって扱いが大きく異なる場合があります。マニュアル等の作成において、考慮が必要になります。

Clause 15:脅威分析およびリスクアセスメント手法

各製品のサイバーセキュリティリスクを洗い出して分析、評価する一連の活動であるTARAに関する要求事項が定義されています。TARAは、資産の識別、脅威分析、影響分析、攻撃経路分析、リスク評価といった活動により構成されます。TARAは、各製品のライフサイクルを通じて繰り返し実施すべき活動と位置づけられており、様々な活動から呼び出されて実行される、活動モジュールと捉えるべきものです。

ポイント：製品のサイバーセキュリティ方針を決定づける最も影響力の大きいTARAはコンセプトフェーズにおけるTARAですが、製品開発フェーズおよび開発後フェーズにおいても度々TARAは実行されるため、OEMだけでなくサプライヤも、本節の要求を正しく理解して仕組みを構築しておくことが重要です。

3. 最新動向

自動車サイバーセキュリティ関連法規、各国の自動車サイバーセキュリティ対応、自動車サイバーセキュリティ技術の最新動向を紹介します。

3-1. 各国のサイバーセキュリティ関連規則

2024年に、各国で自動車サイバーセキュリティに関する法規・規則の発行が行われました。国内のOEM、およびサプライヤーに影響があると考えられる欧州、北米、中国の状況を紹介します。

地域＼分類	関連する規則・ガイドライン	適用動向
相互認証協定 グループ	UN-R155、UN-R156 ISO/SAE 21434	地域・国の違いはあるが、2024年7月以降のOTA車両は対応必須（国内・欧州）
北米	BIS- MPRM：米商務省の輸入規制、 その他NHTSAサイバーセキュリティベストプラクティス, NIST SP 800	ソフトウェア：2027年モデルから、ハードウェア：2030年モデルから適用予定
中国	GB 44495-2024：UN-R155およびISO/SAE 21434を参照しつつ、中国独自の要求を追加	2026年1月から施行予定で、CSMS要求やデータセキュリティ、暗号化方法などを扱う

3-2. SBOMへの要求

SBOMは、ソフトウェアに含まれる全てのコンポーネントとその依存関係を明示する文書であり、近年の複雑化・多層化したソフトウェア構造において、セキュリティ確保に不可欠です。特にOSSの利用拡大により、既知の脆弱性が含まれるリスクが高まっており、SBOMによって迅速な脆弱性特定と対応が可能になります。また、国際的な規制（例：米国大統領令14028）でもSBOMの活用が求められており、信頼性の高い製品開発の基盤となります。

SBOM作成時には、使用しているソフトウェアコンポーネントを過不足なく正確に特定することが重要です。名称、バージョン、サプライヤ情報、ライセンス情報などを明記し、再現性ある形式（例：SPDX、CycloneDX）で記述する必要があります。自社開発・OSS・商用ライブラリの区別や、ネストされた依存関係も網羅することが求められます。また、機密情報や不要な内部情報を含めないよう注意する必要があります。

SBOMは一度作成して終わりではなく、ソフトウェアの更新や新たな脆弱性発見に応じて随時更新し、最新の状態を保つ必要があります。また、セキュリティチームや関係者間での共有体制の整備、CI/CDパイプラインへの統合、脆弱性データベース（例：NVD）との自動照合による監視など、運用プロセスへの組込みが鍵となります。さらに、インシデント発生時のトリアージや報告体制とも連携できるよう準備しておくことが重要です。

SBOMの参考情報

2025年1月にAUTO-ISACから『SBOM情報レポート』が一般公開されました。このレポートには、インシデント対応、脆弱性管理、ソフトウェアアップデートの仕組み、サプライチェーンのリスク管理などの活用事例が掲載されています。各社でのSBOM活用方針を定める際にこのレポートが参考になります。

3-3. Secure by Designコンセプト

自動車業界を含むソフトウェア業界全体で、いま注目を集めているのが「Secure by Design（セキュア・バイ・デザイン）」というコンセプトです。

このコンセプトは、米国のCISA（Cybersecurity and Infrastructure Security Agency）を中心に、日本を含む各国の政府機関が連携して取りまとめたものであり、“製品が設計段階からセキュリティを備えていること”を当たり前にすることを目的としています。すでにMicrosoft、Cisco、Googleなど多くの企業がこの原則への賛同や実践を公表しており、今後のソフトウェア設計に大きな影響を与える可能性の高い指針といえます。

Secure by Designでは以下の3つの基本原則（Principles）が示されます：

1. 顧客のセキュリティ成果に責任を持つこと（Take Ownership）
2. 透明性と説明責任の徹底（Radical Transparency）
3. 経営層の関与と主導（Lead from the Top）

これらの原則を実践するための具体的な手法も本ガイドラインでは示されています。中には、自動車業界の文化として当たり前に実践されてきた内容もありますが、PCやWebサービスといった分野で育まれ、自動車業界が学ぶべき内容も含まれます。

たとえば、SDV（Software Defined Vehicle）によってソフトウェアの自由度が高まり、機能のカスタマイズが一般化すれば、セキュリティ設定をユーザー任せにせず、初期状態で安全性を確保する「Secure by Default」の考え方がより重要となります。

また、TARAの結果や脆弱性情報といったセキュリティ情報をサプライチェーン内で積極的に共有することが、情報の悪用リスクよりもむしろ確実なセキュリティ確保につながるという「透明性」の考え方も、自動車業界のセキュリティ活動に新たな視点をもたらすものと言えます。

4. 実装のポイント

4-1. 基本アプローチ

ISO/SAE 21434を読み解くと、記載されている要求事項は大きく2つのアプローチに分類可能であることが分かります。一つはサイバー攻撃を想定して適切な対策を製品に組み込む「セキュア設計」のアプローチであり、もう一つは開発製品のセキュリティを確実にするための体制と仕組みを構築する「セキュアプロセス」のアプローチです。セキュア設計の成果は、製品のセキュリティ機能やセキュリティ特性として現れ、セキュアプロセスの成果は、組織内のサイバーセキュリティ管理システム（CSMS）として現れます。

ここで、いずれのアプローチにおいても重要になるのがリスクベースの考え方です。ISO/SAE 21434はその成り立ちにおいて、ISO 31000（リスク管理ガイドライン）を基盤としています。設計開発から運用、廃棄までの全ライフサイクルを通して、サイバーセキュリティ関連のリスクを識別、分析、評価、管理するということが、ISO/SAE 21434の要求の本質です。

4-1-1. CSMS構築支援

サイバーセキュリティ管理システム（CSMS）を構築する際、国際規格の要求を表面的に満たすようなやり方では、結局本来の目的を達成できない、あるいは現場で運用できないシステムとなってしまうケースが非常に多いのです。弊社のサポートには、以下のような強みがあります。

既存のシステムとの確実な連携

QMS（品質管理システム）、SMS（安全管理システム）といった既存領域の理解/改善を含めてサポートし、全体として機能するCSMSの構築を支援いたします。

ライフサイクル全体をカバーするCSMS構築

開発フェーズだけでなく、製品開発とは異なるレベルで継続的な活動を行うPSIRT（Product Security Incident Response Team）の体制づくりや仕組みづくりも含めて、ライフサイクル全体を視野に入れたCSMS構築を支援します。

CSMS構築後の充実したサポート

構築したシステムの現場への定着支援から、内部監査を含む継続的な改善の仕組みの構築まで、一貫してご支援いたします。

4-1-2. 人材育成

車載製品のサイバーセキュリティ対応を現場で確実に実行していくためには、標準や規格の知識だけでなく、開発プロセスとのつながりや実務上の判断力を備えた人材の育成が不可欠です。

弊社では、ISO/SAE 21434に関する基礎知識から、TARAの実践、監査/アセスメントの実践および対策まで、幅広い内容をカバーした研修メニューを提供して参ります。

4-2. SafetyとSecurityの両立

これらはどちらも“守る”ためのものですが、そのアプローチは時に真逆になります。実際、機能安全とサイバーセキュリティから導かれる要求が矛盾したり、衝突したりすることは珍しくなく、たとえば以下のようなケースがあります：

Safetyの要求	Securityの要求	想定されるリスク
異常発生時、CANメッセージをバックアップECUが肩代わりして送信すること	CANバスは定義されたECU以外からのメッセージをブロックすること	代替ECUからの送信をセキュリティが拒否するリスク
外部衝突時は直ちにエアバッグ展開判断処理に移行すること	外部イベントは攻撃の可能性があるため、信頼性チェックを行うこと	セキュリティによる遅延が展開遅れを招くリスク

こうしたリスクを確実にコントロールするために重要なポイントは、以下の2点です。

1．要求同士の整合性を確認すること
HARA（Hazard Analysis and Risk Assessment）やTARA（Threat Analysis and Risk Assessment）によって導き出されたゴールや要求同士に矛盾や衝突がないか、各分析の実施後など適切なタイミングでしっかり確認する必要があります。現場では、双方の成果物が孤立し照合されないままレビューに進んでしまうケースが少なくありません。

2．評価軸を揃えること
TARAにおけるSafety観点での“Impact”と、HARAにおける“Severity”は、同じ現象を異なる文脈で扱う指標です。事前にこうした評価基準を揃えておくことで、評価結果のズレが減り、整合の判断がしやすくなります。

4-3. サイバーセキュリティ対応コストの最適化

悪意ある攻撃を想定して対処するサイバーセキュリティには本質的に「完璧」はなく、どこまでもリソースを投入しうる領域です。サイバーセキュリティ対応に膨大な人員と時間を費やして商品性や事業性を犠牲にしないためには、何をどこまで実施すれば十分にセキュアだと言えるのか、根拠を伴った独自の基準を確立しておくことが大切です。しかしその基準は、製品の特性や脅威の度合いによって左右されます。そこで活用いただきたいのが「CAL」の仕組みです。

ISO/SAE 21434では、機能安全におけるASILに似た仕組みとして、CAL（Cybersecurity Assurance Level：サイバーセキュリティ保証レベル）の概念がAnnexに示されています。これは、想定される脅威の度合いに応じて開発の厳密さや実施内容を調整するための「重み付け」として機能します。

CAL決定基準の例

		攻撃元区分（攻撃の容易さを示す一要素）
		物理	ローカル	隣接	ネットワーク
影響	深刻	CAL2	CAL3	CAL4	CAL4
	重大	CAL1	CAL2	CAL3	CAL4
	中程度	CAL1	CAL1	CAL1	CAL3
	無視できる	—	—	—	—

ASILと同様に、CALも“効率的なリソース配分”を可能にする仕組みです。すべての製品や機能に対して均一な対応をするのではなく、リスクの高い部分に重点的にリソースを投入することで、開発負荷を抑えながらも、全体としてのサイバーセキュリティの担保が可能になります。

CALの仕組みはあくまでOEMが活用するもので、サプライヤはOEMの要求に従うものと捉えられるケースがありますが、CALはサプライヤが起点となってコンポーネントレベルで活用することも可能な仕組みです。

• サプライヤが独自にCALを活用する意義：
  TARAに基づいて自社でCALを定義・適用することで、限られた開発リソースを効果的に活用できる
• CALに裏打ちされた説明があれば、顧客要求とのすり合わせにおいて説得力を持って交渉できる
• その結果、サイバーセキュリティ活動の実効性を保ちつつ、事業性や効率を高めることも可能になる

ただし、CALの仕組みの定義は規格上では概念レベルにとどまっており、詳細の定義は各社に委ねられています。CALによる重み付けの効果を最大限に引き出すには、以下のような考え方やルールの定義が必要になります。

• CAL毎の開発の厳密さと実施する活動の定義
• 製品内で異なるCALを共存させるための、ルールや分析観点の定義

5. よくあるご質問（FAQ）

Q1. サプライヤは顧客からのサイバーセキュリティ要求（技術要求）を満足するだけでは不十分なのでしょうか？

はい。上位の技術要求を満足するだけでは、製品のサイバーセキュリティを確実にするには不十分です。脆弱性は開発工程のあらゆるタイミングで導入される可能性があります。自社の開発工程での脆弱性導入を防止/検出できる仕組みを確立し、 その仕組みに則って製品の開発、運用を行う必要があります。

Q2. サイバーセキュリティ関連製品の開発を行う準備としては、ISO/SAE 21434へ適合すれば良いのでしょうか？

はい。ISO/SAE 21434はサイバーセキュリティ管理の仕組みづくりのガイドとして十分です。ただし、ISO/SAE 21434の要求には、基礎的な品質管理（ISO 9001 + IATF 16969など）や情報セキュリティ管理（ISO 27001など）の仕組みの整備が前提として含まれている点には注意が必要です。

市場の車両に関連するバックエンドサーバ（OTA用サーバなど）を有している場合、サイバーセキュリティ管理の適用範囲をISO/SAE 21434のスコープである車載製品からバックエンドサーバまで拡大する必要が生じます。

Q3. サイバーセキュリティ監査は、開発プロジェクト毎に実施する必要がありますか？

いいえ。サイバーセキュリティ監査は、開発プロジェクト毎に実施する必要はありません。サイバーセキュリティ監査は組織のサイバーセキュリティ管理の仕組み（CSMS）の評価を目的としていますので、CSMSを作成/更新したタイミングでの実施に加え、1年に1回のような定期的な実施がされれば問題ありません。

Q4. PSIRTのような、開発完了後のサイバーセキュリティ活動の体制や仕組みは必須なのでしょうか？

はい。サイバーセキュリティ関連製品の開発を行う場合、必須と考えるべきです。一般に機密とされる設計情報なども全て顧客に開示/納入するような例外的なケースを除き、製品に関する脆弱性の監視や分析、対処はその製品の開発を担当した組織にしか実践できません。

Q5. サイバーセキュリティの対応コスト（工数）を抑える方法はありませんか？

サイバーセキュリティリスクの程度に応じてサイバーセキュリティ活動の厳密さを変更するコンセプトCAL（サイバーセキュリティ保証レベル）の導入で、コストを低減できる可能性があります。サイバーセキュリティ活動の内容は顧客からの要求だけで決めず、自社基準を提示した上で調整し、合意することが重要です。