コードスキャニングツールは万能ではない

セキュリティ

少し前になるが、Writing Secure Codeの著者として有名なMichael Howardが自身のブログの投稿「Code Scanning Tools Do Not make Software Secure」にて、セキュリティ対策としてのコードスキャニングツール（もしくは静的解析ツール）への過度な期待に警鐘を鳴らしている。

ここで言うコードスキャニングツールとはVCでいう"/GS"フラグやPREfastのようなツールのことだ。

Such tools, often called static analysis tools, such as the tools we have included in Visual Studio 2005, are very useful, but they are no replacement for human intellect.

つまり、そのようなツールは便利ではあるが、人間の知性を超えるものではない。

その理由として次の3点を挙げている。

1) Code analysis tools find only a small fraction of real bugs. Sure, some of them are very real and should be fixed. But simply running a tool does not mean the code is clean.

2) Code analysis tools have to keep the number of false positives low so developers are not sent on wild goose chases hunting down non-issues. Because of this high bar, many tools will miss real bugs. Hopefully, the number of real bugs missed is low, but it’s never zero.

3) A design bug will not find be found by a source code analysis tool. A missed authentication step or a poorly encrypted key or a weakly-ACLd object will rarely be caught by static analysis tools.

1) ツールは完璧ではない。ツールを実行するだけでは、コードがクリーンであることの証明にはならない。2) ツールは誤検出を出来るだけ少なくするため、検出精度を意図的に弱くしている。そのため実際に問題のあるバグを検出できないこともある。これは改善されるだろうが、完全にはならない。3) デザインバグはツールでは見つけることはできない。

しかし、これらのツールが使い物にならないわけではない。彼はマイクロソフトでの利用法として次の2つを挙げる。

1) They help scale our attack on the problem. If a new code-level bug type is found, we can often build a tool or augment an existing tool to search for the problematic construct and understand how bad the problem is. And in many cases, this allows us to find and fix real bugs.

2) They are used to enforce policy. This is the most important use of tools in my mind. We have a policy under the Security Development Lifecycle (SDL) mandating what constructs can be checked into Microsoft products. We expect the developers to do the right thing in the first place (because we educate them), and then we use tools as a backstop to make sure that policy is being adhered to.

1) 問題への対応を促進させる。たとえば、新たな問題が見つかった場合、すぐにツールを改良し、その問題の影響がどの程度大きいかを把握することができる。これにより本当の問題を探し出し、修正することが可能となる。2) ツールを流すということを通じて、セキュリティポリシーを強制することができる（ここではマイクロソフト社内のSDLというポリシーを例にあげている）。

彼はツールへの過信を次の言葉を持って警告している。

"Not-so-knowledgeable-developer" + great tools == marginally more secure code

あまり知識の無い開発者 + 偉大なツール == わずかに優れているセキュアコード

さらに、コメント欄にもツールを使う必要性についての良い例が出ている。

I feel that it's reverse "Code Scanning Tools Make Software Insecure".
Attackers can use them to find exploits.

So - using tools for development and not using them - will have major effect. You are required to catch all issues those tools can reveal - to not allow attackers find them.

More complex issues are hard to find both by developers and attackers - so here is everything fine.

つまり、ツールが検出できるようなレベルの脆弱性はアタッカーも簡単に見つけ出すことができる。ツールを流すのは、そのようなごく簡単なレベルの脆弱性をまず防ぐという意味でも重要ではある。

実は、この投稿ではHowardはスキャニングツールについて否定的に述べているが、VSや最近のWindows SDKで追加されたSAL（Standard Annotation Language）についてはその可能性を高く評価している。

SALについて興味のある方は次の2つの投稿を読むことをお勧めする。

SALについては、ここでもまた機会を改めて紹介したい。