セキュリティエンジニア不足：自動化とAIでSOPをクリーンに迎える

この仕事をこなせる人が足りていません。それが車載サイバーセキュリティの背後にある不都合な事実であり、状況は良くなるどころか悪化しています。

計算が合わない

ISC2の人材調査は、世界のサイバーセキュリティ人材不足を数百万人規模と見積もっており、2026年の推計では約480万人、需要を満たすには業界が約87%成長する必要があるとしています。セキュリティチームの約90%がスキルギャップを報告しています。

これを車載分野に絞り込んでみましょう。ECUのテストは一般的なITセキュリティではありません。CANとCAN FD、UDSとDoIP、SecurityAccess、診断セッション、組み込みターゲットのリアルタイム制約を理解し、そのすべてをISO/SAE 21434にマッピングできる人材が必要です。それはすでに不足している分野の中の、ごく小さく、予約で埋まった一部です。一方で車載サイバーセキュリティ市場は急成長しており、2026年の約40億ドルから2030年代初頭には120億ドル以上に向かっています。需要は崖を駆け上がっているのに、実際に制御ユニットをテストできる人材のプールはほとんど動きません。

次に、仕事の量を数えてみましょう。現代の車両プログラムには数十のECUがあります。それぞれが量産に至るまでに多くのリリースを重ね、量産後もさらに続きます。深いセキュリティテストが、すべてのECUのすべてのリリースに対して一握りの専門家の一人を予約することに依存しているなら、待ち行列はプログラムより長くなります。何かが犠牲になり、それはたいていテストです。

SOPは一度しかぶつからない壁

量産開始は動きません。車両がSOPに達すると、セキュリティ欠陥のコストは完全に変わります。ラインが動き出す前はコードレビューのコメントだったものが、その後はフィールドキャンペーンやリコールになります。そしてUN R155とISO/SAE 21434の下では、ただ出荷して祈ることはできません。緩和策がテストされ、既知の問題が対処されたことを示す必要があります。

したがって、本当の目標は具体的です。既知のローハンギングフルーツがない状態でSOPを迎えること。誰にも約束できない完璧なECUではなく、明白で影響が大きく最初の1時間で見つかる発見事項が取り除かれ、文書化されたECUです。認証なしで到達できる診断サービス。脆弱またはデフォルトのSecurityAccess。露出したXCPやCCP。ロックされるべき書き込み可能な識別子。これらはよくあり、壊滅的で、そして完全に回避可能です。誰かがリリースごとにテストしていればの話ですが。

その最後の条件こそが問題のすべてです。SOP前の一度きりのペネトレーションテストは、その週に手元にあったソフトウェアのスナップショットにすぎません。ECUは変わり続けます。2スプリント後に追加された機能がひっそりとサービスを再び開き、次の監査まで誰も再テストしません。その時点で、それはもう車の中にあります。

採用では抜け出せない。しかし何倍にはできる

直感的には専門家をもっと採用したくなります。それは正しい直感ですが、十分ではありません。採用できる人材がいないからであり、たとえチームを倍にしても、すべてのECUのすべてのリリースを手動で再テストすることはできないからです。

ここでAIと自動化がユニットエコノミクスを変えます。その仕組みについては正確に述べる価値があります。AIだけでスキルギャップが埋まることはなく、AIがセキュリティエンジニアを置き換えると言う人は何かを売り込もうとしています。AIが得意とするのは、すでにいるチームのレベルを引き上げることです。優れたテスターが手作業で行うことを、テスターなしで動くエンジンにエンコードし、希少な人材を人間にしかできない仕事に充てるのです。

具体的には、UDSスタックを列挙する方法、SecurityAccessを探る方法、インターフェースを安全にファジングする方法、DoIPゲートウェイを歩き回る方法といった知識は安定していて反復可能です。毎回専門家が立ち会う必要はありません。必要なのは、テストを構築するために専門家が一度関わること、そしてそれ以降はマシンがすべてのリリースで永続的に実行することです。専門家はそれによって、新規の攻撃経路、TARA、自動化が想像できないことに取り組めるようになります。

実際のプログラムではどうなるか

AutoSTはまさにこのために作られています。そのエンジンがテストの知識を担います。UDS列挙、SecurityAccess分析（0x27）、UDSとCANのファジング、DoIPとSOME/IP、Android IVI。ECUをベンチに一度配線すれば、それ以降AutoSTはAPIからもCIの中でも実行されます。

これによりテストは「空いている専門家がいれば、監査前に」から「すべてのメジャーリリースで自動的に」へと移ります。すべてのECUのすべてのビルドが同じベースラインのセキュリティチェックを受けます。ローハンギングフルーツは、車の中で発見されるのではなく、持ち込まれた瞬間に捕捉されます。SOPまでには、各リリースがテストされ既知の問題がクローズされたことを示す日付付きの証跡が揃います。これはISO/SAE 21434のアセッサーが見たいものそのものでもあります。

そして、手元にいる一握りのセキュリティエンジニアは、40台目のECUで同じ脆弱なSecurityAccessを再発見することに貴重な時間を費やさなくなります。本当に人間を必要とする攻撃に時間を使えるようになるのです。

正直なところ

自動化はセキュリティエンジニアを不要にするわけではありません。手元にいるエンジニアの価値を高めるのです。AutoSTが広さとリグレッションを引き受けるので、小さなチームでも車両プログラム全体をカバーし、既知のローハンギングフルーツがない状態でSOPを迎えられます。深さ、創造性、TARA、そして監査には引き続き人が必要であり、Zyberumはそれも提供します。Tier 1、Tier 2、OEMのプログラムをまさにこの道筋で導いてきたチームです。リファレンスはご要望に応じて提供します。

セキュリティエンジニアよりもECUの数が多いプログラムであれば（ほぼすべてのプログラムがそうですが）、そのギャップこそAutoSTが埋めるために作られた問題です。デモをご予約ください。すべてのリリースをテストするとは実際にどういうことかをお見せします。