一般的なTOCTOU攻撃は最もよく使われる手口だ。攻撃者はファイルシステムのインターフェースを狙い、ファイルのパーミッションを調べ、ファイル内に侵入する。

「さらに並列攻撃の場合は、複数の異なるインターフェースが対象になり、ファイルデータのみならず、共有プログラムデータなども破損させるため、ファイルの不法侵入よりも深刻な影響を及ぼすこともあります」（Kolossov氏）

　このような危険なコードを検出する際には、動的解析ツールだとコード実行のみに対応する傾向があり、セキュリティの脆弱性をあまり検出できないという弱点がある。一方、静的解析ツールの場合は、本来のエラーを覆い隠し、誤判定を多く出す傾向がある。

　ただし静的解析ツールは、現時点でマルチスレッドの問題を特定するための最適で最安の方法でもある。前出のように、保護境界におけるAPIメソッドのエラーに対する検出を優先させたり、脆弱性のあるウィンドウの継続時間をランク付けすることで、危険を伴うエラーを検査することができるからだ。

　最後にKolossov氏は「新しい脆弱性に関しては、新規の防御メカニズムやチェック機構を発見していく必要があります。まだ完全な答えは出ていませんが、多くの組織が解決に向けて努力しているので、開発も進んでいくでしょう」とまとめた。

QA・Cで効率的に静的解析を行うノウハウを伝授

　続いて同社のWojciech Basalaj氏が登場し、QA・Cのプログラム全体検証とセキュアコーディングについて説明した。

　ソースコードの検証に使う静的解析には、多くのツールが提供されている。同氏は「検証を行う際には、可能な限り未検出をゼロに近づけることが求められます。我々は、これを“健全性”と呼んでいます。一方で逆に問題がないものを検出するのが誤検出です。もちろん誤検出も回避したいのですが、こちらは検証における問題というよりも、むしろユーザービリティの問題になるでしょう」（Basalaj氏）。

　同社の静的解析ツール「QA・C」では、解析時のデータフローのメッセージとして「Possible」（～と思われる）がキーワードになっている。このコード・メッセージが現れない場合には、背後にある特定の問題が起こらないため、それを検証に利用できる。

　もしQA・Cの解析によって何かしらの違反メッセージが出た場合には、コードガード（不適切な値の使用を防ぐためのコード）やコードアノテーション（コード中に登場するクラスやメソッドなどに対し、それ自体に関連するメタデータを注記する）で対処していく。

　またQA・Cではバージョン9.0から追加されたオプションの全体検証機能もある。これをオンにすると、呼び出される側の関数に記述されている条件もみて、自動検証をしてくれる。Basalaj氏は「このプログラム全体解析は非常に便利です。QA・Cの静的解析をより有効にしていける機能になるでしょう」と強調した。

　このようにBasalaj氏は、コードガードやコードアノテーション、プログラム全体検証機能によって、セキュアコーディングの問題を解決していけることを示した。QA・Cで検証を実施し、最終的に解決策を導入して完成したコードは、特定のチェックをかけたルールに対して適合性を有するものになる。