One line. Ever since the Blaster worm snaked across the Internet, the security community has known that it takes but one line of vulnerable code. Heartbleed and iOS Goto Fail made the point again last year. Both were one line mistakes. Even the Bash Shellshock vulnerability was made possible by a small number of lines of code.
Let’s put that in perspective. Today, our thermostats have tens of thousands of lines of code. Our cars have hundreds of thousands and our operating systems have millions. The industry standard for quality is 0.69 defects per 1,000 lines of code. Any one of those defects can lead to the next Blaster or Heartbleed. And it only takes one.
To manage the risk of code-level vulnerabilities, many organizations have implemented security testing in their software development lifecycle. Such testing has touch-points in the implementation, verification, and maintenance phases. For example, an organization might:
Implement. As the code is produced and checked into source control, run static application security testing (SAST) with HP Fortify Static Code Analyzer. This identifies vulnerabilities and allows them to be corrected during development.
Verify. As part of the final quality assurance checks, perform dynamic application security testing (DAST) with HP WebInspect. This identifies security concerns in the running software. Some organizations go so far as to integrate their QA scripts with the DAST processes.
Maintain. Through-out the lifespan of the software, perform periodic audits with SAST and DAST to ensure that defects are not introduced through maintenance or that new vulnerabilities are not discovered.
This example approaches security as a quality management concern with routine checks and gates. With SAST and DAST, along with other activities during the development lifecycle, organizations reduce defects and manages the risk of software exploitation. The toolset for these tasks has matured to the point where program management is now possible; including scheduling, tracking, communication, metrics, and more.
Moreover, the tooling must be easy to use and fit within the development workflow. It must be stood up in a way that is usable by the development team. Good security is usable security. The success of a tool depends upon the adoption and implementation.
Managing a security program is more than tooling, of course. There are other manual tasks to perform, primarily around requirements and design. These include establishing security requirements, threat modeling, security architecture, and performing manual application penetration testing. Mature programs will contain all these touchpoints and more. Yet significant risk reduction can be made simply by beginning down the path towards a full secure development program.
In sum, take any code base. How many lines of code does it have? Given the standard defect density, how many possible defects are there? Take a moment to run SAST and DAST. The results may be surprising, if not downright scary. Thankfully the solutions and processes exist to find and secure that one line of code.
Posted by