Software security myth #2: A tool is all you need for software security
Q: Are tools the key to software security? A: Software security tools are important, but a comprehensive approach must also include architectural analysis.
All software projects produce at least one common artifact—code. This source code is the number one software security touchpoint your organization should address when strategizing a software security initiative (SSI). We’ve made great strides in the last 15 years building technology to find some types of security defects in code. At the code level, the security focus is on implementation bugs, especially those that can be discovered by static analysis tools.
This brings us to the topic of our second myth about software security best practices. Software security tools have played a major role in the acceleration of finding and resolving many defects in code. But are they the key to solving security threats and vulnerabilities?
A history of software security tools
To look ahead, we must first take a step back in time. Let’s take a look at where security tools got their start.
Black box testing tools were the earliest approach for simple protocols (such as HTTP). Dynamically scanning a Web app for known problems using a black box approach is both affordable and appealing. However, generalizing to other protocols isn’t feasible using this approach.
Next came the idea of looking at the code itself with static analysis tools (also called source code analyzers). These tools examine the text of a program statically, without attempting to execute it, by looking for a fixed set of patterns or rules in the code. Theoretically they can examine either a program’s source code or a compiled form of the program to equal benefit, although the problem of decoding the latter can be challenging.
Static analysis tools are capable of scouring a program’s code with less fuss than dynamic analysis, which requires running the code. Static analysis also has the potential to be applied before a program reaches a level of completion at which testing can be meaningfully performed.
The promise of static analysis is to identify common coding problems automatically, before a problem is released. Technology for automating code review has improved vastly since the days of ITS4. Static analysis capability is now available worldwide through IBM, HP, Synopsys, and other firms.
Today, there is a combination of software security tools blending dynamic and static analysis in many interesting ways (albeit mostly for HTTP).
The problem: Software security tools aren’t a catch-all solution
Although more advanced tools allow new rules to be added over time, if a rule hasn’t yet been written, the tool will never find that problem. When it comes to security, what you don’t know could very likely hurt you. Security ignorance truly isn’t bliss.
Further, these software security tools can have an absolutely limited impact. Black box security testing only works for Web applications due to the fact that the HTTP protocol is stateless and simple. Code review tools only look for bugs in code written in certain programming languages. Code review tools also don’t understand the context of the application for which the code is being written.
Doing code review is an extremely useful activity, but since this kind of review can only identify bugs, the best a code review can uncover is about 50% of security vulnerabilities. The other 50% are architectural flaws which are very difficult (downright impossible) to identify from code.
Software security should leverage tools and automation whenever possible, but tools alone simply do not solve the problem. The old software testing adage applies in security as well as it did in quality assurance: A fool with a tool is still a fool.
This adage leads into another weakness within secure development—the fact that security isn’t yet a standard part of the programming curriculum. You can’t really blame programmers who introduce security problems into their software if nobody ever told them what to avoid or how to build secure software. Not to mention that programming languages weren’t designed with security in mind. Unintentional (mis)use of various functions built into these languages leads to very common and often exploited vulnerabilities.
The problem of polar implementation
Integrate software security testing tools and automation into your SSI for reasons of efficiency and scale. But do not confuse tool use with an SSI. An SSI uses tools to enable efficiency and scale of a good strategy, but does not devolve to only using tools, as many firms tend to do.
On the other hand, manual auditing is very time consuming and to do it effectively, human code auditors must first know how security vulnerabilities look before they can rigorously examine code. Static analysis tools compare favorably to manual audits because they’re faster, which means they can evaluate programs more frequently. They encapsulate security knowledge in ways that don’t require the tool operator to have the same level of security expertise as a human auditor.
The solution: A happy hybrid approach
Use the software security tools. They expedite processes and eliminate the low-hanging fruit vulnerabilities. But don’t underestimate the effectiveness of humans. Output delivered by static analysis tools requires human evaluation. There’s no way for a tool to know which problems are more or less important to the organization. There’s no way to avoid sorting through the output, prioritizing which issues should be fixed now, and which ones carry an acceptable level of risk.
And remember, the tools really only tackle 50% of the problems. Static analysis tools can find bugs in the deep, dark corners of code, but they aren’t designed to critique design. A comprehensive approach to software security involves holistically combining both code review and architectural analysis.
Tools also suffer from false negatives (the program contains bugs that the tool doesn’t report) and false positives (tools report bugs that the program doesn’t actually contain). False positives can cause irritation to analysts who are responsible for sorting through them, but false negatives are more dangerous because they lead to a false sense of security.
Maintain best practices
So, is it true that a tool is all you need for software security? No.
While tools (such as those that perform code review) are a proactive resource in secure development, they’re not a sufficient stand-alone practice for achieving secure software. A comprehensive approach of tools and architectural review conducted by security experts is the only approach to achieving the most secure software.
