イベント日：2026年9月12日。 セキュリティ研究者のクリストファー・ドーマスは、防御的な慣行に従って書かれたCのソースコードでも、正当なコンパイラー最適化を経た後に脆弱な実行ファイルが生成される可能性があると警告した。Black Hat USA 2026で収録された議論の中で、ドーマスは、変換によってメモリー消去処理が除去されたり、ソース上では明らかでなかったTOCTOU（検査時と使用時のずれ）の隙が生じたりした事例を説明した。

中心的な問題は、プログラマーの意図と、Cの抽象機械が要求するものとの差にある。プロセッサーが実行するのは元の文ではなく、コンパイラーの出力だ。言語規則上、ソースレベルの処理に観測可能な効果がなければ、プログラマーがセキュリティ目的で追加したものであっても、オプティマイザーがそれを削除したり並べ替えたりする可能性がある。保存領域がスコープ外になる直前に機密性の高いメモリーを消去する処理が典型例であり、書き込みを残すよう意味論で保証された仕組みを使用しない限り、通常のコードは不要と見なされることがある。

ドーマスはまた、レジスターへの圧力、構造体のレイアウト、データサイズによって、問題のあるパターンがコンパイル後も残るかどうかが決まり得ると説明した。議論とともに要約された一例では、17バイトまたは33バイトのバッファーでは安全な結果となった一方、それに近いサイズでは脆弱なバイナリーが生成された。この不安定さにより、一見わずかなビルドやレイアウトの変更でも生成後の動作が変わり得るため、ソースレビューだけでは不十分となる。

この議論は、開発者が防御的なコードを書くのをやめるべきだと主張するものではない。その代わり、ユーザーが実際に受け取る成果物そのものをセキュリティ作業の対象に含めるよう求めている。推奨される対策には、コンパイラー警告の有効化、サニタイザーの実行、最適化済みビルドの調査、デバッグ構成だけに頼らず最終バイナリーをテストすることが含まれる。リリース時のコンパイラーオプション、対象プロセッサー、リンクされたコンポーネントも、システムのセキュリティ動作の一部である。

GCCとClangを単に切り替えることは一般的な解決策として示されておらず、Rustへ移行してもコンパイラーに関連するあらゆるリスクがなくなるわけではない。メモリー安全な言語は広範な種類のバグを防止できるが、オプティマイザーは依然として言語の意味論に従ってプログラムを変換する。開発者には、機密性の高い処理向けにサポートされたプリミティブと、それらがリリース用出力でも有効性を保っていることの検証が必要だ。

議論の要約によると、このBlack Hatでの研究では人工知能も使用し、5億行のオープンソースコードを分析して、危険である可能性のあるパターンを約300件特定した。これらの結果は検証を要する手掛かりとして扱うべきであり、フラグが付けられたすべてのプロジェクトが悪用可能であることの証明ではない。実際に悪用できるかどうかは、コンパイル後のコンテキスト、攻撃者のアクセス権、周囲の制御策に左右される。

より広い教訓は、セキュリティ保証がソースと実行ファイルの境界を越えなければならないということだ。コードレビューでは意図を確認できるが、逆アセンブル、最適化済みビルドのテスト、実行時解析によって、出荷されるバイナリーがその意図を維持しているかどうかが分かる。コンパイルを中立的な変換として扱うビルドパイプラインは、この研究がまさに焦点を当てている変換を見落とす恐れがある。