State of Software Security v11: How to Use the Findings

As a security professional reading through version 11 of our State of Software Security (SOSS) report, the first statistic that probably stands out to you is that 76 percent of applications have security flaws. It’s encouraging to see that only 24 percent of those security flaws are high-severity, but ultimately, having security flaws in more than three-fourths of applications means there is still work to be done.

How can you better secure your applications?

For this year’s SOSS report, we decided to look at the effects of “nature”– factors we can’t change like application size or age – versus “nurture” – factors we can change like scan frequency – to see how they impact application security. The findings, if put into practice, can significantly improve the security health of your applications.

1. Use DAST with SAST.

SOSS research shows that when using dynamic application security testing (DAST) in conjunction with static application security testing (SAST), organizations are able to find and fix flaws almost 25 days faster. Why is this? Perhaps because dynamic scanning highlights to developers that a vulnerability does, in fact, have “real-world” risk.

2. Scan frequently and on a regular cadence.

SOSS v11 found that organizations that scan their applications infrequently (less than 12 times in a year) spent about 7 months to close half their open findings, while organization that scan their applications at least daily reduced time to remediation by more than a third, closing 50 percent of flaws in 2 months. Likewise, organizations that scan their applications on a steady cadence reduced their time to remediation by 15.5 days. To improve scan frequency and cadence, consider automating application security (AppSec) scans into developers existing processes.

3. Integrate security testing with the API.

Those scanning via API – and therefore in an integrated and automated way – address half their security findings 17.5 days faster than those not scanning via API.

4. Use SCA with SAST.

Just as we highlighted the benefits of using DAST with SAST, it’s important to use software composition analysis (SCA) with SAST. Why? First, this year’s SOSS report found that 97 percent of the typical Java application is made up of third-party libraries and that almost one-third of applications have more security findings in third-party libraries than native codebase. If you only employ SAST, your attack surface is a lot bigger than you think. In addition, this year’s research found that those scanning with both static analysis and software composition analysis improve time to remediation by an average of 6 days.

What flaw types should you keep an eye on?

As a security professional, you’re likely familiar with the OWASP Top 10 and SANS 25 vulnerability lists. But something you might be surprised to know is just how common these severe flaws are in applications. For example, the first flaw on the OWASP Top 10 list is injection flaws. Did you realize that 65 percent of applications have CRLF injection flaws and 28 percent have SQL injection flaws? Some of the other common flaws in applications include information leakage, cryptographic issues, and code quality. By knowing the most common flaws, as well as the most severe flaws, you can create a better plan of action for prioritizing and remediating flaws.

For more detailed information on our SOSS v11 findings, including regional differences, download the full report.