サイバーセキュリティのためのAutomotive SPICE
～エンジニアリングにおけるSECプロセスの位置づけ～

　今回のメルマガでは、「サイバーセキュリティのためのAutomotive SPICE」（以降：本文書ではCS SPICEと表記）に定義されている、サイバーセキュリティエンジニアリングプロセスについてお話します。

　先日2025年3月に、CS SPICEのVer.2.0（英語版）が公開されました。新しいバージョンのPAMでは、土台となるAutomotive SPICEのVer.が3.1から4.0に更新され、それに伴って対象ドメインにハードウェアが追加されるなどの変更がなされています。現時点でもCS SPICEは、欧州を中心としたOEMによるサプライヤ評価等ですでに活用されていますが、このバージョンアップによってその活用はさらに拡大されると考えられます。

　さて、このCS SPICEをプロセス改善に役立てる際に多く聞かれる疑問として、従来のエンジニアリングプロセスと、サイバーセキュリティエンジニアリングプロセス（SEC）との関係があります。SECプロセス群では、TARA（脅威分析およびリスク評価）を除くサイバーセキュリティ関連のエンジニアリング活動が一括して取り扱われています。プロセス改善の現場では、Automotive SPICE 上のプロセス構造に従ってサイバーセキュリティエンジニアリングを従来のシステム、ソフトウェア、ハードウェアエンジニアリングから完全に独立したものとして実装しようとするアプローチが散見されます。しかしこのようなアプローチは効果的なサイバーセキュリティリスク管理の妨げとなる場合があります。SECプロセスの本来の役割と立ち位置を理解することが、CS SPICE活用の最初の一歩として大切です。

　SECプロセスは他のプロセスから独立して存在するのではなく、システムやソフトウェア、ハードウェアエンジニアリング活動に統合する形で実施されるべきです。セキュリティの分析、設計、検証といった活動が、各エンジニアリング工程の適切なタイミングに組み込まれていくことが理想です。図１はエンジニアリングプロセスとSECプロセスの典型的な関係を表しており、各エンジニアリング活動の一部としてSECプロセスの要素が実装されることを表現しています。実際、欧州OEMによるアセスメントでは、SECプロセス単体ではなく、SYSやSWEの中でセキュリティ関連活動の妥当性や実装状況を併せて確認するケースが一般的です。
　さらに、同じSECプロセスであっても、開発領域やタイミングによって求められる活動は異なります。例えば、SEC.3プロセスは検証工程のほとんど全体に関係しますが、車載製品としての統合が完了したタイミングでは製品単体のファジングテスト、製品を車両に組み込んだタイミングでは車両レベルのネットワークテストといったように、製品特性や開発領域、タイミングに合わせて適切な活動をエンジニアリング工程に追加するという方針が重要になります。

図１ アイテム/コンポーネント各レベルのエンジニアリングプロセスとSECプロセスの関係

　「SECプロセス群」という枠組みは、プロセスを改善/評価する際の視点を示しているにすぎません。サイバーセキュリティ関連プロセスの構築においては、SECプロセスという枠組みに囚われず、エンジニアリング全体との融合を意識することが重要です。自社の開発プロセスが、こうした観点で効果的に整備できているか、今一度見直してみてはいかがでしょうか。サイバーセキュリティプロセスのギャップ分析や、第三者視点からのチェックをご検討の際は、ぜひ弊社までご相談ください。

2025/5/29 大野 貴正