Chapter 15

ソフトウェア防御と脆弱性管理

この章がなぜ必要なのか——CRA が要求するのは、まさにここだから.

04 章で見たとおり、セキュアブートは「正規に署名された脆弱なファームウェア」を 喜んで起動する。完全性は守っても、安全性は守らない。

そして 03 章で見たとおり、EU CRA は「既知の脆弱性なしで出荷すること」と 「サポート期間中の脆弱性対応」を法的義務にした。

つまり——脆弱性管理は、もはや技術的な良心ではなく、法的な要件である。

この章で使う既出の用語（定義は各リンク先）. セキュアブート（02 章 3 節）、サポート期間中（03 章 2 節）、不可能（04 章 3 節）、完全性（06 章 6 節）、必要（09 章 6 節）、ベンダ提供（13 章 9 節）、最も危険（13 章 6 節）、CRA（14 章 6 節）、市場（14 章 5 節）、確実（14 章 6 節）、開発（14 章 5 節）

1. 組み込みで起きる脆弱性の型

メモリ安全性のバグ

C/C++ で書かれた組み込みソフトウェアの、最大の脆弱性源である。

メモリ安全性の脆弱性を見る

コードパターンを選ぶと、何が起きるか、どの防御が効くかが表示される。

組み込みでは、PC より状況が悪い.

要因	内容
MMU がない	プロセス分離がない。1 つの脆弱性で全メモリが触れる
ASLR がない	アドレスが固定なので、攻撃コードを書きやすい
スタックとヒープが近い	オーバーフローが他の重要データを踏む
クラッシュが見えにくい	「たまに再起動する」で片付けられる
W^X が徹底されていない	RAM 上のデータを実行できてしまうことがある

代表的な攻撃対象

「認証前に処理されるコード」が最も危険である.

TLS ハンドシェイクの前、ペアリングの前、ログインの前に動くコードは、 誰からでも攻撃できる。ここに脆弱性があると、認証機構が意味をなさない。

• TCP/IP のパケット処理
• TLS ハンドシェイクの ClientHello / 証明書解析
• BLE のアドバタイズ・接続要求処理
• USB のディスクリプタ処理

この範囲のコードは、特に厳しくレビュー・テストすること。

2. 防御 — コンパイラとツールチェーン

まず、無料でできることを全部やる。

# GCC / Clang で必ず有効にすべきフラグ
-Wall -Wextra -Werror              # 警告を全部出し、エラーにする
-Wformat=2 -Wformat-security       # フォーマット文字列
-Wconversion -Wsign-conversion     # 暗黙の型変換（組み込みでは重要）
-Wshadow                           # 変数の隠蔽
-fstack-protector-strong           # スタックカナリア
-D_FORTIFY_SOURCE=2                # 標準関数の境界チェック（最適化と併用）
-fstack-usage                      # スタック使用量の静的解析
-fno-common                        # 暫定定義を禁止

# リンカ
-Wl,--gc-sections                  # 未使用コードの除去（攻撃面の削減）

Armv8.1-M の PACBTI

Cortex-M85 / M55（一部）などが対応する、ハードウェアによる制御フロー保護。

ROP（Return-Oriented Programming）攻撃への直接的な対策である.

ROP は「既存のコード断片を戻りアドレスの改ざんで繋いで、 任意の処理を実行する」攻撃で、W^X を回避できる。

PAC があると、戻りアドレスを書き換えても署名が合わないので検出される。 これは組み込みにとって大きな進歩である。

Cortex-A では Armv8.3-A から PAC、Armv8.5-A から BTI と MTE （Memory Tagging Extension、メモリ安全性のハードウェア支援）が使える。

3. 防御 — 言語とライブラリ

メモリ安全な言語

Rust は「一部だけ置き換える」ことができる.

全部を書き直す必要はない。 最も危険な部分——パーサ、プロトコル処理——だけを Rust で書き、 C から呼ぶという段階的な移行ができる。

米国の CISA・NSA も「メモリ安全な言語への移行」を推奨する文書を出している。 新規開発では、少なくとも検討する価値がある。

コーディング規約

MISRA C を「全部守る」のは現実的でないことが多い.

だが、セキュリティに直結する規則だけを選んで適用するのは有効である。

• 暗黙の型変換の禁止
• 動的メモリ確保の制限
• 再帰の禁止
• ポインタ演算の制限

CERT C のほうが、セキュリティ目的には直接的である。

4. テスト

ファジングは組み込みでも有効

1. プロトコル処理の関数を、ホスト（PC）でビルドできるように切り出す
2. AFL++ / libFuzzer のハーネスを書く
3. ASan / UBSan と組み合わせてビルドする
4. 数時間〜数日走らせる
5. クラッシュした入力を最小化して、バグを特定する

/* libFuzzer のハーネスの例 */
extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size)
{
    parse_protocol_packet(data, size);   /* 実機と同じコードを呼ぶ */
    return 0;
}

「実機でしか動かない」を理由にテストを諦めないこと.

プロトコル解析、パケット処理、設定ファイルの読み込み—— これらはハードウェアに依存しないことが多い。

HAL をモックに差し替えれば、ホスト上でファジングできる。 ホストなら 1 秒に数千〜数万回実行できるので、実機の比ではない効率で見つかる。

CI に組み込むこと。 コミットのたびに数分走らせるだけでも効果がある。

5. SBOM — ソフトウェア部品表

CRA が明示的に要求する項目である。

SBOM とは、 「この製品には、どのソフトウェア部品が、どのバージョンで入っているか」の一覧である。

なぜ必要か

組み込みで実際に入っているもの:

BLE / Wi-Fi スタックが最大の盲点である.

ベンダ提供のバイナリブロブになっていて、中身が分からないことがある。 だが過去に複数のチップベンダの BLE スタックで、 リモートコード実行を含む脆弱性が公表されている。

選定時に「ベンダの脆弱性開示ポリシーと、更新の提供期間」を確認すること。 これは 23 章の選定基準に含めるべき項目である。

SBOM の生成

Yocto / Buildroot ベースの Linux 組み込みでは、 ビルド時に SPDX を出力する機能が整備されている。

6. 脆弱性の追跡

SBOM を作っただけでは意味がない。継続的に照合する必要がある。

「影響評価」の工程が実務では最も重い.

CVE が出ても、自社製品では該当機能を使っていないことが多い。 全部に対応していたら、リソースが持たない。

VEX（Vulnerability Exploitability eXchange）という仕組みがある。 「この CVE は、当製品では影響しない（該当コードを呼んでいない、等）」 を機械可読な形で表明するものである。

CycloneDX や CSAF が VEX に対応している。 CRA 対応では、この「影響しない理由の記録」が重要になる。

7. 脆弱性開示ポリシー

PSTI・CRA・EN 303 645 すべてが要求する。

「報告しても無視される」「訴えられる」と思われたら、 研究者は報告せずに公開するか、闇市場に流す.

報告しやすい窓口を作ることは、それ自体がセキュリティ対策である。

ISO/IEC 29147（脆弱性開示）と ISO/IEC 30111（脆弱性処理プロセス）が 参考になる。CRA の要求もこれらと整合している。

8. セキュア開発ライフサイクル（SDL）

標準:

CRA 対応の実質は、SDL の導入である.

CRA が要求するのは、個々の技術的機能というより、 「そういうプロセスが回っていること」とその文書化である。

IEC 62443-4-1 の認証を取っておくと、CRA 対応の大部分が済むという関係にある （03 章）。

9. この章のまとめ

次章では、第 V 部の残り——通信のセキュリティを扱う。