State of Software Security Vol 9: Top 4 Takeaways for Developers

We’ve just released the 9th volume of our State of Software Security report and, as always, it’s a treasure trove of valuable security insights. This year’s report analyzes our scans of more than 2 trillion lines of code, all performed over a 12-month period between April 1, 2017 and April 30, 2018. The data reveals a clear picture of both the security of code organizations are producing today, plus how organizations are working to lower their risk from software vulnerabilities. There are many significant and actionable takeaways, but we’ve pulled out what we consider the top 4 for developers.

The usual suspects emerge

This year’s scans includes some familiar faces. In fact, they’ve been familiar for years. Breaking down the prevalence of flaws by vulnerability categories shows that all of the usual suspects are present at roughly the same rate as in previous years. Specifically, our top 10 most prevalent flaw types have hardly budged over the past year.

The top 10 vulnerabilities in 2018 were:

• Information leakage
• Cryptographic issues
• Code quality
• CRFL injection
• Directory traversal
• Credentials management
• Cross-site scripting (XSS)
• Insufficient input validation
• SQL injection
• Encapsulation

One big takeaway here for the development team? Make sure you and your team are getting the support and training you need to code securely. We’ve conducted surveys that highlight a big gap in developer training surrounding secure coding. Almost no university software engineering programs require or offer coursework in security, and once on the job developers report little to no security training. We also have research that highlights the effect of training on code security. We’ve found that our customers who offer their developers eLearning on secure coding best practices improve fix rates by 19 percent.

Open source components are still a pain point

For several years now, we’ve drawn attention to the fact that vulnerable open source software components run rampant within most software. That trend continues. Last year, about 88 percent of Java applications had at least one vulnerability in a component; this year, that figure dipped down marginally to 87.5 percent.

For other languages, here are the percentages of apps that had at least one flaw in a component:

• PHP: 90.2%
• .Net: 85.7%
• C++: 92.4%
• JavaScript: 68.5%

The crucial thing to keep in mind about vulnerable components is that it’s not just important to know when a component contains a flaw, but whether that component is used in such a way that the flaw is easily exploitable. Data compiled from customer use of our SourceClear solution shows that at least nine times out of 10, developers are not necessarily using a vulnerable library in a vulnerable way. By understanding not just the status of the component, but whether or not a vulnerable method is being called, organizations can pinpoint their component risk and prioritize fixes based on the riskiest uses of components. Learn more about vulnerable methods.

Scanning more = fixing faster

It might seem counter-intuitive, but this year’s SoSS data reveals that the speed and incremental nature of DevOps actually improves and enables security.

As the DevOps movement has unfolded, security-minded organizations have recognized that embedding security design and testing directly into the continuous software delivery cycle of DevOps is a must for enterprises. This is the genesis of DevSecOps principles, which offer a balance of speed, flexibility, and risk management for organizations that adopt them.

It’s only natural that a DevSecOps organization will scan much more frequently than a traditional waterfall development organization. These organizations tend to top-load huge changes into a lengthy development cycle, and usually kick security tests to the end of that process as a cursory checkbox action item.

Our data this year shows that there is a very strong correlation between how many times a year an organization scans and how quickly they address their vulnerabilities. Whether they officially call what they do “DevOps,” “Agile,” or something else entirely, we can show that the teams that are scanning more often are making incremental improvements every time they test. Once organizations reach the point of 300 or more scans per year — the true territory of DevSecOps unicorns — the fix velocity goes into overdrive.

In fact, organizations scanning more than 300 times per year shorten flaw persistence 11.5x across the intervals compared to applications that are only scanned one to three times per year.

Improving fix rates is a joint effort

Our data this year reveals both there are a lot of flaws in code out there, and that fixing them is a big, challenging task. Prioritization is key, but developers rely on their companies’ policies for prioritization.

Based on our analysis, many policies take into account flaw severity. Some might take into account exploitability, others might emphasize certain vulnerability categories, and a few others will dictate how fixes are made to specific applications based on what they do for the business.

But at the end of the day, an individual developer is going to be looking at his or her organization's policy to chart the plan of attack for closing out vulnerabilities. For any given customer, those policies may be based on some of the variables we laid out here, or they could be based on other factors unique to their organization or industry.

The bottom line is that organizations need to start thinking more critically about the factors that impact what they fix first. And security teams and developers need to work together to address this issue.

Get the full report

Read the full SoSS report to get all the software security insights and best practices from our scan data. This year’s report contains details on the above points, plus data and insights on specific vulnerability types, which industries are more secure than others, a deep dive into fix rates, and more.