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 (21)

  1. Garry Trinder says:

    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.

  2. PatriotB says:

    Banned APIs… I’m assuming this is mainly APIs such as lstrcpy that have been deprecated in favor of the strsafe functions?

  3. 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


  4. 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)?

  5. David Hackscroft says:

    Yeah, And despite you imposing these rules on your developers they still fail at security dont they?

  6. Brian Chess says:

    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.

  7. I was in the process of writing a blog on my thoughts about Code Scanning Tools to find security vulnerabilites…

  8. Rob Morton says:

    I have done some source code review and penetration testing for various industries.  I agree that static analysis in its current state is weak.  I do believe that there are some fundamental problems with the way we go about finding vulnerabilities including source code review, black box testing, and network analysis.  The fundamental problem usually relies on creating the notion that a vulnerability exists or doesn’t, a sort of binary concept.  This is a grave mistake as security is not absolute, espically in a mesh of varying architectures and implementations.  

    I believe there is still a lot to be done in determining vulnerabilities, and I believe the process to a degree can be automated.  To shed some light on the matter of new methods for static analysis, I suggest you read this recent  paper from Purdue University

    Vulnerability Likelihood: A Probabilistic Approach to Software Assurance

    This account offers a great alternative to finding the likelihood of a vulnerability, thus giving you reasonable better assurance of software.

    I am currently developing a similar project, I hope to submit to OWASP on this matter that will hopefully improve on WebScarab.  I believe my research and release of an itial tool will be done early this summer.

  9. One of the themes discussed at RSA 2006 was Secure Software.  Secure software is up to businesses…

  10. In today’s webcast we had the opportunity to explore the buffer overrun attack in depth which is considered…

  11. Brad Sarsfield here again. I’d like to share with you my thoughts on David Litchfield’s BlueHatv3 talk….

  12. Introduction

    Even though a prior blog I wrote “Code Scanning Tools Do Not make Software Secure” at …

  13. I was reminded last night, that there are always going to be some constructs that your static analysis…

  14. Introduction Even though a prior blog I wrote “ Code Scanning Tools Do Not make Software Secure ” may

  15. [Nacsa Sándor, 2009. január 13. – február 3.]  A minőségbiztosítás kérdésköre szinte alig ismert

Skip to main content