車載ソフトウェアのコーディングの課題と、実用的な解決策:セキュアな車載ソフトウェア開発の在り方(2)(2/2 ページ)
静的コード解析やソフトウェアコンポジション解析、ファジングテストの使用など、車載ソフトウェア開発ライフサイクルのセキュリティを向上させるソリューションの概要を説明した前回の記事に続き、今回は静的コード解析をテーマにする。最初にコーディングの問題について説明し、次に実用的な解決策について解説する。
静的コード解析ツール:コーディング規約
静的コード解析ツールを使用する2つ目の目的はコーディング規約の準拠を確認することだ。自動車業界組織が安全目的だけでなくセキュリティ上の理由からもコーディング規約に従うことがますます一般的になってきている。適切なコーディング規約の例には、MISRA C/C++(※7、8)、AUTOSAR C++(※9)およびCERT C/C++(※10、11)が挙げられる。
(※7)MISRA, “MISRA C:2012 - Guidelines for the Use of the C Language in Critical Systems”, 2013
(※8)MISRA, “MISRA C++:2008 - Guidelines for the Use of the C++ Language in Critical Systems”, 2008
(※9)AUTOSAR, “Guidelines for the Use of the C++14 Language in Critical and Safety-related Systems”, 2019
(※10)SEI, “CERT C Coding Standard - Rules for Developing Safe, Reliable, and Secure Systems”, 2016
(※11)SEI, “CERT C++ Coding Standard - Rules for Developing Safe, Reliable, and Secure Systems in C++”, 2016
一部の複雑な車載システムには、自社開発コードや第三者が開発したコード、自動生成コード、商用ソフトウェア、オープンソースソフトウェアなど、さまざまな種類のソフトウェアが含まれている場合がある。従って、静的コード解析ツールを使用してコーディング規約への準拠をチェックする場合の一般的な課題の1つは、ツールが数多くの結果をもたらすことだ。検出結果の数が多いため、組織はどの検出結果を最初に分析し対処すべきかの決定が難しい。これらの結果の多くは、関係ないか重要でないかの可能性もある。
図3に示すように、組織では3段階のプロセスで検出結果に優先順位を付けることを提案する。まずは、特定のガイドライン(例えば、必須でない推奨=Advisoryの項目)や、ソフトウェアコンポーネント(商用ソフトウェアやオープンソースソフトウェアなど)に基づいて、一部の結果を振るい落としその数を減らすことが必要だ。
次に、ガイドラインまたはソフトウェアコンポーネントの優先度に基づいて残りの検出結果にスコア値をつけることも有効だ。1=Lowから4=Criticalまでのスコア値をつけるとして、必須のガイドラインまたはセキュリティクリティカルなコンポーネントには高いスコア値を割り当てる。
そして、スコア値の低い結果を除外し、例えば3=Highと4=Criticalのように優先度の高いスコア値の結果に焦点を当てることだ(※12)。各段階で組織が検出結果を除外する根拠、例えばどのガイドラインやソフトウェアコンポーネントに関連する結果を除外するのか、どのスコア値の結果を除外するのか、はまず対象システムに対するリスク分析を行った上で、十分に検討し判断する必要がある。
(※12)岡デニス健五, “AUTOSARの今後とコーディング規約との向き合い方”, https://www.brighttalk.com/webcast/13983/414011/autosar
まとめ
この記事では、自動車業界でソフトウェア開発を行う組織が静的コード解析を使用し、ソフトウェア開発の早い段階での問題を検出する方法について解説した。品質とセキュリティの問題に対処するため、組織がCWEトップ25などのよくある重大な弱点のリストを参照し、優先順位を検討するがことが重要である。
プログラミング言語特有のチェッカーを検討することも重要だ。例えば、自動運転システムの開発にCUDA特有のチェッカーを使用することによりセキュリティと品質の問題を検出することができる。最後に、組織が静的コード解析ツールを使用して、コーディング規約の準拠を確認することが重要だ。数多くの検出結果を処理することを回避するために、組織は検出結果に優先順位を付け、優先度の高い問題に最初に取り組むことを勧めたい。
著者プロフィール
岡 デニス 健五
日本シノプシス合同会社のソフトウェアインテグリティグループにてプリンシパルオートモーティブセキュリティストラテジストとしてセキュリティソリューション業務に従事。2006年より車載セキュリティを専門としている。
過去にはスウェーデンでボルボの自動車セキュリティ研究を始め、リモート診断やOTA(over-the-air)アップデートを専門としていた。前職のBoschグループでは国内とグローバルの顧客対応に従事。日本とAPACのエンジニアリング及びコンサルティングマネージャーとして特に車載セキュリティの部署(ESCRYPT)の設立に協力し貢献した。
現在、日本シノプシスでは自動車セキュリティのソリューション、主にソフトウェア開発ライフサイクルとサプライチェーンに特化したソリューションを提供しており、60以上の執筆を手掛け、世界中で講演も多数行っている。
関連記事
- ≫連載「WP29サイバーセキュリティ最新動向」
- ≫連載「いまさら聞けない 車載セキュリティ入門」
- 避けて通れぬ自動車のセキュリティ、ソフトウェア開発は何をすべきか
サイバーセキュリティにさらに力を入れるには、ソフトウェア開発のライフサイクル中のサイバーセキュリティ活動も含めて、自動車業界における文化的および組織的なシフトの必要性がある。自動車業界の課題や解決策について解説していく。 - 自動車セキュリティとソフト更新の国際基準が成立、2022年へ対応急務
国連の自動車基準調和世界フォーラム(WP29)が2020年6月24日に開催され、自動車のサイバーセキュリティとソフトウェアアップデートに関する国際基準(UN規則)が成立した。車両の型式認可を受ける際に、国際基準を満たす体制であることを示す必要がある。サプライチェーンや製造後の自動車の使用期間の全体像を見た対応が求められており、自動車メーカーだけでなく、サプライヤーの参加や自動車のユーザーの理解も不可欠だ。 - 自動車メーカーとサプライヤーはどう連携してセキュリティに取り組むべきか
本連載では、2019年9月の改訂案をベースにOEMに課されるWP.29 CS Regulationsのポイントを解説し、OEMならびにサプライヤーが取り組むべき対応について概説する。目次は下記の通り。 - 自動車メーカーに選ばれるのは、セキュリティを理解したサプライヤーだ
本連載では、2019年9月の改訂案をベースにOEMに課されるWP.29 CS Regulationsのポイントを解説し、OEMならびにサプライヤーが取り組むべき対応について概説する。今回は自動車のサイバーセキュリティに必要な組織づくりや、開発フェーズでのプロセス構築について説明していく。 - つながるクルマに求められるサイバーセキュリティ
スパイ映画やSF映画には、自動車がハッキングを受けて乗っ取られるシーンが出てくることがある。つながるクルマ=コネクテッドカーが当たり前になるこれからの時代、これらのシーンは絵空事では済まされない。本連載では、つながるクルマをサイバー攻撃から守る「車載セキュリティ」について解説する。 - 車車間と路車間の通信を守るためのセキュリティ技術
自動車に搭載される通信機能の中でも今後の採用拡大が見込まれているのが、いわゆるITS(高度道路交通システム)に用いる車車間通信や路車間通信だ。今回は、これらV2X通信を守るセキュリティ技術について解説する。
Copyright © ITmedia, Inc. All Rights Reserved.