What Developers Need to Know About the State of Software Security Today

We recently published our annual research report, the State of Software Security, analyzing data from 400,000 application scans over 12 months spanning 2016 and 2017. Now we’re issuing a State of Software Security Developer Guide, featuring additional data and analysis aimed at helping developers meet the goal of creating great software that’s also secure software.

This report offers the developer and security communities more information about what development practices make the biggest impact on application security, and what organizations should do to better support developers. Here are the major takeaways from the report, along with Veracode’s recommendations for making security a seamless part of your development and DevSecOps processes.

1. Developers aren’t trained in secure coding.

Traditionally, the focus for developers is creating functional, rather than secure code. Veracode research shows that the pass rate of applications against standards like the OWASP Top 10 hasn’t budged in recent years, with applications failing policy consistently around 70 percent of the time on the initial scan. When we looked at the prevalence of major vulnerability categories like SQL injection in initial application scans, we see a similar consistency over time. If SQL injection, and other flaws like credentials management, are continuing to show up at the same rate during development, that indicates developer education programs still aren’t providing secure coding training.

Even though security defects are being introduced during the initial coding phase, the good news is that developers are fixing security flaws after the initial test – indicating that they do understand the importance of releasing secure code. And as application security programs mature, developers and security teams are getting better at stomping out these common flaws at a higher rate. Mature application security programs have a 35 percent higher OWASP pass rate than programs just starting out.

2. Developers take security testing seriously.

Some security professionals, and even security vendors, chalk up the high rate of vulnerabilities in software to the idea that developers don’t care about security. Our past surveys of developers have proven this to be a myth. Developers want to create great code, and to them that also means code that won’t get their company breached.

Data from the Veracode platform analyzed in our State of Software Security report offers further proof that developers are serious about fixing security flaws. When we looked at the flaw mitigation rate, we found that only 14.4 percent of flaws were mitigated, meaning developers closed a flaw because they believed some other factor makes it less of a threat, such as network implementation or operating system features.

Out of that subsection of flaws that were mitigated, only 25 percent were marked as a false positive. That would seem to indicate that developers aren’t rejecting security findings out of hand. More often, developers feel that mitigating factors including the design of the application make certain coding flaws unlikely to affect the security of an application.

That said, some developers are offering mitigation comments indicating that they sometimes don’t understand how an application might be attacked. Environmental changes or new attack techniques can render ineffective many mitigating factors, including network and operating system mitigations. Veracode recommends that mitigations should be part of a long-term plan to remediate the flaws in the code. Even flaws that do not affect the overall security of an application may indicate some underlying problem that requires more investigation.

It might not be possible to fix every flaw you find in your applications, at least not initially. You have to pick your battles and start with the most critical flaws first. We found in our data that developers are doing this. During our study period last year, the fix rate (measured as flaws/MB of code) for high and very high vulnerabilities was about twice the overall fix rate.

3. DevOps and DevSecOps are accelerating.

Our scan data offers quantitative proof that the shift to DevOps and DevSecOps is accelerating. Over the past two years, our scanning data indicates that developers and security professionals are scanning applications more frequently on average. There’s been a growth over the past two years in applications that are scanned monthly or more often, with 28 percent of applications being scanned 12 or more times per year in 2017, up from 24 percent of applications in 2016.

When we looked at the scan data by programming language, we found that Java and .NET showed the highest scanning frequency in the last year. This could indicate that organizations using these enterprise-friendly languages are more mature in their adoption of DevOps. Also significant, the popular web scripting languages like JavaScript and PHP are showing a lower frequency of testing.

It doesn’t feel like a coincidence that the low-scan frequency languages PHP and JavaScript had a higher prevalence of major flaw categories like SQL injection, cross-site scripting, cryptographic errors, and credentials management flaws. We saw in our scans that 47 percent of applications written in PHP had a SQL injection flaw and 43 percent had a cross-site scripting flaw. Meanwhile, 31 percent of .NET applications had SQL injection flaws and just 14 percent had cross-site scripting flaws.

4. Vulnerabilities in components are a big blind spot for developers and security teams.

Despite the fact developers are showing greater care in creating secure code, the use of open source components remains a virtual black hole for developers. Components caused several major data breaches recently, but developers frequently can’t or don’t track what components are in the open source or third-party code they’re integrating into their applications.

Our scan data shows that 91 percent of Java applications using Apache Struts were using version with a high or very high severity vulnerability. Meanwhile, attackers are moving very fast these days to attack new vulnerabilities as soon as they are discovered. For example, the Struts-Shock vulnerability discovered in March 2017 was exploited by attackers within days.

Some AppSec vendors offer software composition analysis that can identify components within applications and show you which versions of components have a vulnerability. But developers can’t rely on composition analysis only – they need to keep an up-to-date inventory of the components in their applications and use the most recent version. Security teams and vulnerability managers need to update the components as soon as new vulnerabilities are discovered.

5. Developers make big improvements when they get the security training they need.

Despite the high prevalence of flaws at the beginning of testing, developers make great strides in fixing vulnerabilities when they have software development tools and resources to support them, including testing tools that allow them to run scans on small batches of code instantly, right in their IDE. Sandbox scanning, where developers can scan their code against policy before checking the code in, results in a 48 percent higher fix rate. Remediation coaching from security experts helps developers improve fix rates by an average of 88 percent vs. developers who don’t use remediation coaching. And developers who receive eLearning courses have an average 19 percent higher fix rate.

Security training isn’t a one-time proposition, however. The threat landscape is constantly changing, the architecture, languages, and features in modern applications are changing, and DevSecOps is changing everything. Developers need to keep learning application security skills, with the same passion that they bring to learning and experimentation in other areas of their professional and personal lives. As our studies have shown, developers are already doing this. They just need the right tools and training to help them succeed.

We’ve also seen evidence that when developers are given these tools and training resources, they introduce fewer security defects into the code they create. This suggests that what developers need is tools to learn secure coding, not lessons in the importance of security.

Download the State of Software Security Developer Guide for more data and deeper analysis of the AppSec trends affecting developers, and best practices to help you create secure code at the speed of DevOps.