Code Scanning Tools Do Not Make Software Secure
There has been a lot of press recently about using ‘code scanning’ tools to find security bugs in source code. So I thought I’d share my view on code scanning tools.
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. If a developer does not know how to code securely, or if a designer does not know how to design secure systems, and testers don’t know how to validate the security-posture of code, tools will provide little, if any, help.
Here’s why.
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.
So allow me to explain how we use tools internally at Microsoft. We use tools for two main purposes:
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.
When you check code into, say, Windows Vista, there are a battery of tools that run automatically to look for use of weak crypto, use of banned APIs, potential buffer overruns, integer overflows, setting weak access control lists (ACLs) in code and so on. If the tools find a bug, the check-in fails and the developer needs to fix the code. But we know from sad experience that there are many other ways of introducing vulnerabilities into software, and after the tools stop, we are relying on our trained engineers and our robust processes to keep those vulnerabilities from being released to customers.
To a certain extent, tools can also provide “just in time learning,” by pointing out potential problems to developers. But personally, I don’t like that idea; I think developers should know the implications of what they are writing in the first place and use great tools too. But that’s just me!
Another take is:
"Not-so-knowledgeable-developer" + great tools == marginally more secure code
Don’t get me wrong, source code analysis tools find real bugs, and they are very useful. I love code analysis tools but I refuse to allow developers at Microsoft, or anywhere else for that matter, to believe that such tools will fix the core problem of developers writing insecure code.
Creating secure software requires having an executive mandated, end-to-end process requiring on-going education, secure design based on threats, secure coding policy and testing policy, penetration and fuzz testing focused on new and old code, a credible response process and finally a feedback loop to learn from mistakes.
And you use great tools too...
(Big thanks to Steve Lipner, Eric Bidstrup, Shawn Hernan, Sean Sandys, Bill Hilf and Stephen Toulouse for their draft comments)
Comments
Anonymous
January 26, 2006
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.Anonymous
January 26, 2006
Banned APIs... I'm assuming this is mainly APIs such as lstrcpy that have been deprecated in favor of the strsafe functions?Anonymous
January 27, 2006
Source code analysis tools are no doubt good for static code testing , for e.g validating for unsecure API or function arguments.
I think developing secure software is an attitude which rely on development processes.
Limit is that right now developement Processes like RUP or MSF roam arround managing customer requirements.
Two destinction can easily been seen
1) Developer know how to code
2) Security Specialist limit with in Network Security
need to do is to combine best of both minds for develop secure application, not to secure developed application.
Zeeshan Ali Shah
MS Information Security Student
KTH, SWEDENAnonymous
January 27, 2006
Hallelujah !Anonymous
February 04, 2006
I'm curious how what your integer overflow tool looks for. It seems like a difficult problem to me: "n-bit integers" are used all over the place in most software, and developers almost always think of them as integers and think of * as multiplication.
Do you use special types that check for overflow or allow arbitrary-size integers? If you use ordinary "n-bit integer" types, does your tool ensure that all mathematical operations are checked, or only operations followed by memory allocations? Or do you make heavy use of hard limits and assertions on size (e.g. images cannot be more than 10000 pixels tall)?Anonymous
February 08, 2006
Yeah, And despite you imposing these rules on your developers they still fail at security dont they?Anonymous
February 12, 2006
A great majority of practiced and professional writers find a spell checker to be a useful tool. Poor writers gain from using a spell checker too, but the tool does not transform the nature of their work.Anonymous
February 14, 2006
I was in the process of writing a blog on my thoughts about Code Scanning Tools to find security vulnerabilites...Anonymous
February 21, 2006
The comment has been removedAnonymous
February 23, 2006
One of the themes discussed at RSA 2006 was Secure Software.  Secure software is up to businesses...Anonymous
March 15, 2006
In today’s webcast we had the opportunity to explore the buffer overrun attack in depth which is considered...Anonymous
March 17, 2006
Brad Sarsfield here again. I’d like to share with you my thoughts on David Litchfield’s BlueHatv3 talk....Anonymous
May 19, 2006
Introduction
Even though a prior blog I wrote “Code Scanning Tools Do Not make Software Secure” at ...Anonymous
July 24, 2006
I was reminded last night, that there are always going to be some constructs that your static analysis...Anonymous
December 01, 2007
The comment has been removedAnonymous
June 24, 2008
Introduction Even though a prior blog I wrote “ Code Scanning Tools Do Not make Software Secure ” mayAnonymous
February 03, 2009
[Nacsa Sándor, 2009. január 13. – február 3.]  A minőségbiztosítás kérdésköre szinte alig ismertAnonymous
May 26, 2009
PingBack from http://backyardshed.info/story.php?title=michael-howard-s-web-log-code-scanning-tools-do-not-make-software-secureAnonymous
June 02, 2009
PingBack from http://outdoorceilingfansite.info/story.php?id=59509Anonymous
June 08, 2009
PingBack from http://quickdietsite.info/story.php?id=12935Anonymous
June 17, 2009
PingBack from http://patiosetsite.info/story.php?id=606