A Single AppSec Technology Is Not Enough

There is no application security silver bullet; if you’re relying on only one technology, you are leaving your organization open to attack. Over the past 10 years, we have scanned 2 trillion-plus lines of code, and we consistently see that different testing types are better an uncovering different vulnerabilities, and that one testing type is not enough. Our most recent State of Software Security (SoSS) report brought even more clarity to this issue.

Based on the goldmine of data we have accumulated over the past 18 months and 300,000 security assessments, our seventh SoSS report is intended to give security practitioners a clear picture of application security trends and how their initiatives compare to their peers’. This year, we broke down the vulnerabilities we found by the type of testing used to scan code. And we found some interesting differences. The results clearly illustrate that there are significant differences in the types of vulnerabilities discovered by looking at applications dynamically at runtime, as compared to static tests in a non-runtime environment.

A shift in the top 5 vulnerabilities

The following are the top five vulnerability categories we found during dynamic testing:

Information leakage Cryptographic issues Deployment configuration Encapsulation Cross-Site Scripting

Two of these were not in the top five found by static testing: Encapsulation (dynamic found in 39% of apps; static only in 22%) and Cross-Site Scripting (sixth on the static list). And one category deployment configuration was not found by static at all. Clearly, only running static scans would leave some significant vulnerabilities unidentified.

A trend that only dynamic would uncover

In addition, when analyzing our platform data for this report, we discovered a trend that’s increasing vulnerabilities, and that would only be unearthed with dynamic testing.

When we looked at three of the top four vulnerability categories unearthed through dynamic testing:

Cryptographic issues Deployment configuration Encapsulation

we realized that these all involve the misconfiguration of protection mechanisms.

In other words, developers are actually introducing vulnerabilities by not properly configuring elements that are intended to keep data safe. This could mean utilizing SSL incorrectly or using secure cookies the wrong way. It could also include the improper use of security headers. For example, there’s a header value that can be sent in a web application that tells a browser to turn on protection against Cross-Site Scripting, and it turns out that a lot of developers get that wrong.

And you would only find these misconfigurations that are creating vulnerabilities by adding dynamic testing to your application security program.

In addition, unearthing these misconfiguration through dynamic testing create valuable lessons for developers in how to improve the use of these security mechanisms going forward.

The bottom line on using multiple testing technologies

Another new feature in this year’s SoSS is a “what good looks like” analysis. We took a closer look at the organizations that are really moving the needle on AppSec and have top-tier vulnerability fix rates.

We found that the application security programs of these top-performing organizations feature:

Readout calls for remediation coaching eLearning subscriptions to improve developer skills Using more than one assessment technique Leveraging Developer Sandbox testing for more frequent unofficial scans Tracking progress against benchmarks

Clearly, using more than one assessment technique is a proven way to ensure application security success.

Bottom line: Neither type of test is necessarily better than the other, they’re just different. It takes a balanced approach to properly evaluate and mitigate your application-layer risks.

For all the findings and analysis from our last 18 months of code scanning, check out the full State of Software Security v7 report .