自動車製造とソフトウェア定義型車両 (SDV) における脆弱性フリーの C および C++ 開発
2024年10月23日
0 分で読めますソフトウェア定義型車両 (SDV) の登場により、自動車産業はその歴史の特別な転換期を迎えています。2024 年 4 月 16 日 ~ 18 日にデトロイトで開催された米国自動車技術協会 (SAE) の国際会議の中で、自動車業界の研究開発と技術向上への投資は 5,000 億ドル以上の市場規模になることが明示されました。SDV への移行により、機能とサービスのサブスクリプションを通じた新たな収入源が確保されます。これは、自動車産業が始まって以来つきものだった従来の「一度だけの購入」モデルでは不可能なことでした。
自動車メーカーとサプライヤーは、半導体をこのようなイノベーションの中心に据えて、電気/電子 (EE) アーキテクチャを活用したテクノロジー企業になろうとしています。 そのほかに SDV の重大な実現要因となるのは、マイクロサービス、コンテナ化されたアーキテクチャ、重要なクラウドコンピューティングの存在です。
この分野では、信頼性が高く効率的で堅牢なプログラミング言語として、ほぼ C および C++ のみを使用してソフトウェア開発を行っています。しかし、数十年間をさかのぼってみると、これらの言語にはバッファオー バーフローやメモリの安全性の問題などが発生しています。SDV 市場はソフトウェアのセキュリティを確保するという Snyk のミッションと直接関係しています。自動車メーカーは、Snyk の IaC およびコンテナのサービス、さらにさまざまなクラウド プロバイダーと Snyk の自然な統合のメリットを享受することができます。
たとえば、Mercedes はその MB Operating System で時代の先端を行っています。
私たちは、利用できる中で最も優れているハードウェアと、ほんの 6 か月前に消費者向けに利用可能になったばかりの Qualcomm Gen4 8295 を迅速に統合しました。これは壮大なプロジェクトでした。この挑戦を引き受けてくれたチームを非常に誇りに思っています。チームは 20 GB のコンパイル済みコードを作成し、また、完全な MB.OS 1.0 をリリースするために学習は不可欠であるため、この MB.OS の原型を E クラスに搭載しました。
C および C++ 向け MISRA コンプライアンス
MISRA C:2023 ガイドラインは、アプリケーションセキュリティに関する側面など、重要なシステムの安全性と信頼性に主に焦点を当てています。特に、脆弱性によって安全性のリスクがもたらされるおそれのあるシステムが該当します。MISRA C:2023 ガイドラインには幅広いトピックが含まれますが、未定義の動作、メモリ破損、不正アクセス、その他の一般的な脆弱性を防ぐ実践を促進してアプリケーションセキュリティを強化することには、特定のルールとディレクティブが特に関連しています。
C ガイドラインと同様に、MISRA C++:2023 仕様の構造と内容では、アプリケーションセキュリティに関連するいくつかのルールとディレクティブの概要とともに、準拠しているコードと準拠していないコードの例が示されています。
一部の C および C++ 開発向け MISRA コンプライアンスガイドラインでは、次に示すように、アプリケーションセキュリティとセキュアな C および C++ ソフトウェアの構築に関するディレクティブとルールが引用されています。
MISRA ディレクティブ 4.12 - 動的メモリ確保を使用してはならない: 動的メモリ確保を制限することで、メモリ管理エラーに関連する種類の脆弱性を防ぐことができます。
MISRA ルール 1.3 - 未定義または重要な未指定の動作が発生してはならない: 未定義の動作はセキュリティの脆弱性をもたらす可能性があるため、このルールはセキュリティにとって非常に重要です。
MISRA ルール 18.1 - ポインターオペランドの算術から得られるポインターは、そのポインターオペランドと同じ配列の要素を処理しなければならない: このルールは、C プログラムにおける一般的な脆弱性である、範囲外のアクセスを防ぐことを目的としています。
MISRA ルール 21.3 - メモリの確保および確保解除関数 <stdlib.h> を使用してはならない: ディレクティブ 4.12 と同様に、動的メモリ確保を行わないことで、メモリ管理の脆弱性に関連するリスクを軽減することができます。
MISRA ルール 22.1 から Rule 22.20 (リソース): エラー処理やリソースの解放など、リソースを適切に管理することは、リークや枯渇を防ぐうえで重要です。リークや枯渇は、サービス拒否攻撃で利用されたり、攻撃者によって悪用される未定義の動作をもたらしたりする可能性があります。
MISRA C 仕様ではガイドラインを明示的に「セキュリティ」対策として表記してはいませんが、その包括的なルールとディレクティブに準拠することで、C および C++ コードにおけるセキュリティ脆弱性の多くの一般的な原因が取り除かれ、ソフトウェアのセキュリティ態勢が向上します。これらのガイドラインは、堅固な適切に定義された動作を推進することで、安全で信頼性が高く、セキュリティが確保されたシステムを開発するのに役立ちます。
Snyk が役立つ理由
Snyk は、C および C++ を使用している開発者を含め、開発者がコードのセキュリティを確保できるよう支援することに特化しています。Snyk は、セキュリティを開発ライフサイクルに統合することで (DevSecOps メソッドなど)、重大な問題になる前に開発者が脆弱性を把握できるようにします。それだけでなく、Snyk を使用すれば、開発者は IDE にコードを保存する際にセキュアでないコードパターンを把握できるため、継続的インテグレーション (CI) とビルドパイプラインを通過するまで待つ必要がなく、コードのコンパイルステップも必要ありません。
Snyk Code などのツールを使用すると、C および C++ コードベースをスキャンして脆弱性を発見し、それを修正するための実用的なインサイトを得ることができます。
たとえば、 C++ での一般的な脆弱性であるバッファオーバーフローを考えてみます。以下は、この問題を示す単純なコードスニペットです。
#include <iostream>
#include <cstring>
void vulnerableFunction(char* input) {
char buffer[10];
// ❌ Potential buffer overflow
strcpy(buffer, input);
}
int main() {
char input[20] = "This is a long string";
vulnerableFunction(input);
return 0;
}
このサンプルの C++ プログラムでは、strcpy
関数は、入力文字列がバッファのサイズを超えた場合、バッファオーバーフローを引き起こす可能性があります。Snyk を使用すれば、このような脆弱性を特定して、strncpy
を使用するなどの安全な代替手段の提案を得ることができます。
void secureFunction(char* input) {
char buffer[10];
strncpy(buffer, input, sizeof(buffer) - 1);
buffer[sizeof(buffer) - 1] = '\0'; // Ensure null-termination
}
IDE に Snyk をインストールすると、2 つの便利なことが実現します。
上記のバッファオーバーフローなどの脆弱性を Snyk が検出します。コンパイルステップは必要ありません。
Snyk は Snyk Agent Fix を使用して問題を修正するよう提案します。
これらが実際にどのように行われるのか、こちらをご覧ください:

セキュアコーディングプラクティスを採用し、Snyk などのツールを活用すれば、C および C++ コードベースにおける脆弱性のリスクを大幅に軽減できます。今すぐ Snyk に登録して、重要なソフトウェアプロジェクトを保護しましょう。
セキュアでガイドラインに準拠した C および C++ コードの例と、セキュアでなく脆弱な C および C++ コードの例
MISRA ガイドラインと仕様が実際のコードと脆弱性とどのように関連するかを示すために、C プログラム program2.c
を確認します。これは、先ほどのリストにある、望ましくない動作 (MISRA ルール 1.3) の例を示しています。
こちらが C プログラムコードです。
#include <stdio.h>
void undefinedBehavior() {
int x = 5 / 0;
printf("Value of x: %d\n", x);
}
int main() {
undefinedBehavior();
return 0;
}
ゼロ除算は C で未定義の動作で、予測できない結果を導く可能性があります。当然、MISRA ガイドラインでは、重要なソフトウェアでのコードの安全性とセキュリティを確保するためにこのような演算は禁止しています。
最初にコンパイルしてから実行することで、プログラムを実行します。
$ gcc program2.c -o program2
$ ./program2
GCC コンパイラがゼロ除算に関する警告をスローすることがわかります。
program2.c:5:15: warning: division by zero is undefined [-Wdivision-by-zero]
int x = 5 / 0;
^ ~
1 warning generated.
ただし、これは単純で小さなプログラムコードです。実際のシナリオでは、大規模なコードベースで、標準出力に送られた多くのコンパイラ警告がある中でこのような問題を見つけるのは困難です。
Snyk Code を使用して脆弱性を検出する
_division by zero_ やその他の問題に関するコンパイラ警告から未定義の動作のエラーメッセージを見つけることは、開発サイクルの後半では困難です。Snyk Code を使用すれば、コードをコンパイルする前にコードベースをスキャンして脆弱性がないか確認して、問題を開発サイクルの早期に特定することができます。
これが可能な理由は、Snyk が静的コードアプリケーションセキュリティエンジンに機械学習手法を採用していることにあります。これにより、プログラムの呼び出しフローを理解し、シンクからソースへのコードパスフローを接続して、コードをコンパイルすることなくコードベース内のセキュアでないコードや潜在的な脆弱性を検出します。

C および C++ におけるセキュリティコンプライアンスとセキュアなコードのためのツール
C および C++ での MISRA コンプライアンスを確認するための選択肢として、以下のオープンソースツールをご紹介します。
OpenMRC: OpenMRC は、Eclipse CDT (C/C++ 開発製品) プラグインとして開発された、オープンソースの MISRA-C ルールチェッカーです。このツールの目的は、ソフトウェア定義型車両コードを MISRA-C:2004 ガイドラインと照らし合わせて分析して違反メッセージを生成し、機能安全のコンプライアンスが確保されるようにソースコードを更新できるよう開発者を支援することです。
clang-misracpp2008: このプロジェクトは、すでにアーカイブ済みですが、MISRA C++:2008 ルール用の、LLVM/Clang インフラストラクチャを使用したオープンソースのチェッカーを作成することを目的としていました。アーカイブ済みであり、もうアクティブではありませんが、開発者は代替手段として
clang-tidy-misra
を使用することを推奨しました。clang-misracpp2008
は LLVM/Clang プラグインとして実装され、カスタムロジックとコンパイラが提供するフラグを通じて MISRA C++ ルールを対象にするための努力を実証しています。
上記は別として、ツールが自社の標準に合わせて保守されていて、品質のガードレールとセキュリティテストの総合的なしきい値を維持している場合でも、別の選択肢として検討すべきなのが Snyk です。
Snyk のセキュリティプラットフォームには、開発者向けのリアルタイム SAST である Snyk Code が含まれており、開発者フレンドリーな体験でコードセキュリティが最適化されます。Snyk の調査結果には、学習リソース、対策のアドバイス用の修正例が含まれているほか、場合によっては Snyk Agent Fix に基づく自動修正も行われます。
Snyk は無料で利用でき、さまざまな方法で導入して C および C++ コードをスキャンできます。Snyk IDE 拡張機能をインストールする、Bitbucket または GitHub から Git リポジトリをインポートする、Snyk CLI を使用するなどの方法があります。
C および C++ プログラムでは、コードベースに存在するセキュリティ脆弱性の別のベクトルが、開発者のコードの範囲を越えたところに及ぶ可能性があります。オープンソースライブラリを通じてインポートされたコードです。
最後に、インタラクティブなセキュリティ学習を体験するために、簡潔にまとめられた Snyk Learn の C の脆弱性に関する教育レッスンを確認することを強くお勧めします。レッスンでは、null の違い、二重の free による問題のあるコーディング規約などのさまざまな C と C++ の脆弱性について取り上げています。
最先端のインテリジェンスでコードを保護
わずか 30 分で、Snyk Code SAST 機能の全範囲について学習できます。