Vulnerability Scanners: Are These Enough for Your Applications?

Over the past decade, testing applications for security flaws and vulnerabilities has increased considerably. Only a few organizations today would consider not testing their software and opening themselves to the regulatory, reputational, and financial risks of insecure software.

Security testing methodologies have also evolved during this time.

Twenty years ago there were few tools available to organizations — SPI Dynamics (now MicroFocus Fortify) and Sanctum (later Watchfire and IBM) were beginning to offer dynamic analysis tools and Veracode, Ounce Labs, Fortify, Klocwork, and Coverity were still in the future. 

Organizations that did application security testing relied primarily on code reviews and penetration testing services. Now, in addition to manual services, organizations can license tools and services for static analysis, dynamic analysis, source composition analysis, interactive application security testing, runtime application security protection, and other technologies.

Why security testing might not be enough

While these tools and services have helped teams build more secure software, they remain reactive solutions. Security scanners identify design flaws and coding vulnerabilities after they are produced. Remediating these issues requires developers to refactor code, slowing down the development process and causing friction between DevOps and security teams. 

While vendors are making progress in “shifting left” with IDE plug-ins, real-time micro training, and faster, iterative scans, security testing is still often left to later in the development process when remediating issues is more time consuming and expensive.

When starting application security testing programs, most organizations opt for third-party penetration tests. These fulfill regulatory requirements like PCI DSS 11.3 and do not require in-house security expertise. As the security program matures, the next step can be to bring dynamic analysis tools in-house so testing can be conducted more frequently.

These tests require a running application in a staging environment and therefore occur very late in the development lifecycle. They can also fail to identify the root cause of an issue, making full remediation difficult. An example is SQL Injection, a common input validation vulnerability.  Many times, these vulnerabilities are reported by testers (and tools) in multiple locations where the improperly validated data is used (the data “sink”) rather than where the data originally enters the software (the data “source”).  In these cases, developers are attempting to fix bugs in multiple code locations, inevitably missing others and leaving vulnerabilities in the software. 

As programs continue to mature, source composition analysis tools can be added to identify out-of-date open source components with known vulnerabilities and those with restrictive licenses. Source composition analysis has grown in popularity as organizations have embraced open source. Exploits for vulnerabilities in open source are often publicly available and provide a simple attack vector for hackers. Requiring developers to use only company-approved open source components is often part of an organization’s secure coding policy. It is also easily bypassed by busy developers with critical deadlines.

Static analysis tools complement the dynamic analysis and can be used much earlier in the development lifecycle. Like dynamic analysis, however, these tools can be “noisy” and produce hundreds or thousands of false positives and informational warnings. This results in long delays in analyzing the results as findings must be reviewed carefully to find those that matter to the organization.

Use vulnerability scanners to validate controls

Security scanners find vulnerabilities after they have been produced. Using scanners as a primary way of building security into applications, however, is inefficient. More mature organizations focus on prevention; helping developers by building security tasks into their requirements. While many DevOps teams will have secure coding policies, few have ways to validate that each policy is followed.

Secure coding is not a secret process. Over 90 percent of the threats to an application are inherent to the application’s functionality, technology stack, and deployment environment. 

Enumerating these threats and adding controls to mitigate these risks prior to starting development allows developers to build software correctly the first time, reduces the testing burden on scarce security resources, and minimizes remediation efforts later in the development process.

In short, by anticipating security issues early, security testing is converted from a process of discovering vulnerabilities to a more focused approach to validating controls.