ALM3年以内に標的になるなら、TARAはいつ再び開くのか

VisualPro Tech Brief

3年以内に標的になるなら、TARAはいつ再び開くのか

1つの公開エクスプロイトでリスクレベルが2から5へ：VisualPro TARAによる生産後サイバーセキュリティの再評価

VWAY 技術資料 · 2026年11月4日 · 読了時間 約8分

TARAISO/SAE 21434攻撃実現可能性リスク対応の決定OTA生産後セキュリティ

01要約

0283%が示すこと、示さないこと

QNXの「Under the Hood: SDV Developer Report」2026年版は、OnePollが7月20日から8月4日までオンラインで実施した調査です。セキュリティに関する数値は次のとおりです。

これらの数値を読む際には、2つの点に留意してください。この調査は車載ソフトウェアを販売する企業が委託したもので、回答者は報酬を受けて参加しています。また、83%は開発者による予測であり、実際に発生した攻撃の統計ではありません。車両の83%が攻撃されるという意味ではありません。

この調査を取り上げたTheAutoExecの記事は、さらに一歩踏み込んでいます。筆者は、車両がいつまでセキュリティアップデートを受けられるのか、脆弱性が見つかったときにどう対応するのかを、メーカーは説明できるべきだと書いています。これは調査結果ではなく、筆者の意見です。ただ、エンジニアにとって、この問いはすぐに別の問いに変わります。その回答の根拠となるリスク評価は、今も正しいのか、という問いです。

03量産開始時のTARAは前提の上に成り立っている

ISO/SAE 21434は、コンセプトと開発で終わりません。その適用範囲には生産、運用、保守、廃棄が含まれます。箇条8はサイバーセキュリティサポート終了まで継続的なリスク評価と脆弱性管理に情報を提供する活動を、箇条13はインシデント対応とアップデートを、箇条14はサポート終了と廃棄を扱います。UN R155に基づくサイバーセキュリティ管理システムも、生産後のフェーズにまで及びます。

なぜ量産開始後に評価が変わるのでしょうか。攻撃ポテンシャル方式では、攻撃実現可能性は5つの要素の合計で決まります。

スコアが低いほど、攻撃が容易であることを意味します。量産開始時に「この攻撃は難しい」とした根拠の大半はこの5つのセルにあり、5つとも車両の外の世界が変われば変わります。資産も被害の大きさも変わらないまま、攻撃だけが容易になることがあるのです。

04例1：攻撃コードが公開されたとき

これは教育用の架空のシステムです（特定の車両やメーカーの設計ではありません）。テレマティクス制御ユニット（TCU）はセルラーネットワークに接続され、ネットワークスタックにオープンソースライブラリを使用しています。アップデートマネージャーは、署名検証鍵でOTAパッケージを検証します。脅威は2つあります。

• TH-1 TCUのネットワークスタックの脆弱性を突いてリモートでコードを実行し、偽造した車両制御メッセージを送信する（影響度 Severe）
• TH-2 診断ポート経由でECUのメモリを読み出し、署名検証鍵を抽出して偽造アップデートパッケージをインストールする（影響度 Major）

量産開始時（T0）には、2つの脅威はいずれも難しいと評価されていました。攻撃者がTH-1の脆弱性を自ら見つけなければならなかったためです。ここで、TCUが使用するライブラリの脆弱性が攻撃コードとともに公開されたと仮定します（T1）。AP-1の値が変わります。

次はリスク計算画面です。

ここで注目すべき点が2つあります。

第一に、最初からやり直す必要はありません。変わったのは1つの攻撃パスの評価であり、TH-2はそのままでした。公開された脆弱性がどの資産と攻撃パスに関わるかが分かれば、見直す範囲は絞り込めます。

第二に、リスク値は再計算されますが、決定はひとりでには変わりません。リスクレベル5の横に「保有」が残ったままです。この決定はリスクレベルが2だったときに下されたものです。誰も見直さなければ、文書は古い決定をあたかも今も有効であるかのように示し続けます。リスク対応の決定は責任を伴う判断であるため、ツールが下すべきものではありません。だからこそ、誰がいつ見直すのかを手順で定めておく必要があります。

この例では、TH-1の決定を「低減」に変更し、2つのサイバーセキュリティ目標を攻撃パスに紐づけました。

• SG-1 TCUネットワークスタックの公開脆弱性は、定められた期間内にOTAパッチで解消する
• SG-2 TCUからの制御メッセージは、許可されたものだけがゲートウェイを通過して車両内部に入る

SG-1の「定められた期間」こそ、TheAutoExecの筆者が問うサポートの約束につながる部分です。パッチ期間とサポート期間を示すには、その裏付けとなるリスク評価が必要です。

05例2：OTAで機能が追加されるとき

2つ目のシグナルは外部からではなく、自社側から生じます。量産開始後にOTAでリモートスタート機能が追加されたとします（T2）。量産開始時のTARAには、この機能の資産も攻撃パスもありません。既存の値を修正するだけでは不十分で、新しい項目が必要です。

QNXの調査では、79%がスピードへのプレッシャーを感じていると回答しました。機能のリリース頻度が高まるほど、TARAを一度で完了する文書として扱うことは難しくなります。新機能のリリース手順には、TARAが更新されたかどうかを確認する項目が必要です。

06いつ再び開くか：4つのシグナル

シグナルを見つけることと、評価をやり直すことは別の仕事です。脆弱性情報の収集とインシデント対応には別の仕組みが必要です。TARAは、その仕組みが見つけたことがリスクと決定をどう変えるかを記録する場です。

07VisualPro TARAでできること・できないこと

できること

できないこと

VisualPro TARAは評価を記録し、計算するツールです。脆弱性情報の収集やインシデント対応は行わないため、攻撃コードが公開されたという事実は担当者が判断して入力する必要があります。

08明日確認すること

セキュリティ担当

• 各リスク対応の決定について、いつ下されたのか、当時のリスクレベルはいくつだったのかが分かりますか。
• 公開脆弱性が見つかったとき、どの資産と攻撃パスを確認すべきかをすぐに特定できますか。

開発・製品担当

• OTA機能のリリース手順で、TARAが更新されたかどうかを確認していますか。
• オープンソースライブラリはTARAの資産と紐づけられていますか。

品質・法規担当

• TARAを再び開くシグナル、担当者、期限が手順に明記されていますか。
• 顧客に約束するサポート期間はリスク評価と整合していますか。

09まとめ

10よくある質問