Our latest research into the State of Software Security has something for everybody. For AppSec managers, the report offers evidence that application security is improving, although not as much as we’d like, with a slight lift since our last report in the percentage of applications passing OWASP top 10 policy.
But what does our analysis, drawn from billions of lines of code over the past 18 months, say about developers and your efforts to write more secure code? Well, there’s good news and bad. And some of the takeaways have a mix of both. Let’s start with the bad news.
The bad: Insecure security features
In the quest to bolster security within their applications, many developers are opening up their software to even more attacks. We found a significant number of vulnerabilities that involve the misconfiguration of protection mechanisms. Fully 65 percent of applications have cryptographic issues, while 25 percent have encapsulation errors. Whether it is incorrectly implementing SSL, accepting the wrong cross-domain policies or improperly using security headers, these types of flaws increase the attack surface area of software while engendering a false sense of security.
The mixed: Some programming languages are lagging, component risk rising
Not all programming languages are equal. On the positive side, developers using C/C++, .NET and Java have a relatively high security success rate with applications passing OWASP top 10 policy, at 88 percent, 62 percent and 61 percent, respectively. On the other hand, PHP (33 percent) and ColdFusion (38 percent) have below-average pass rates.
Then there are security issues that can’t really be pinned on individual developers – the majority of applications have vulnerabilities introduced by open-source components. For example, 97 percent of all Java applications we assessed had at least one component with a known vulnerability. Still, the same vulnerabilities in third-party components frequently show up as weaknesses in developer-written code, too. The same deserialization vulnerability found in a version of Apache Commons Collections library used in 21 percent of Java applications was present in 25 percent of developer-authored Java applications.
The good: Developers do better with sandboxes and continuous learning
Developers should take heart – there are many signs that, with the right resources, your coding improves and you catch and fix flaws at a much higher rate. According to our research, developers who test code in a private developer sandbox, without fear of scan-and-scold by security, fix 59 percent of flaws. Without sandbox scans, the fix rate drops down to 30 percent.
Developer sandboxes allow you to scan your code without alerting security or affecting an application’s overall compliance with policy. While the average application is scanned just seven times over 18 months, we’ve seen applications tested in sandboxes up to six times per day. That gives you many more opportunities to catch flaws and improve your coding skills.
As more organizations move towards DevOps and continuous release, improving your secure coding skills is gaining in importance. We’ve found that developer training such as eLearning courses has a significant impact on flaw density. In our State of Software Security study, development teams using eLearning saw a 55 percent reduction in flaw density between the first scan and latest scan. That rate of reduction was six times better than teams without eLearning.
5 key takeaways for developers
So what’s the bottom line? Here are five recommendations developers should take from our 2016 State of Software Security report.
1. Train up
Training around commonly discovered vulnerabilities can greatly help you to fix the problems you find, and avoid making similar mistakes the next time.
2. Test early and often
Frequent scanning in a developer sandbox helps you fix code faster and more efficiently.
3. Keep an eye on components
An alarming number of components have vulnerabilities. Be sure you know what version of each component you are using to help keep software vulnerability-free.
4. Remember that security is a journey not a destination
Security is not a point-in-time issue, and it takes everyone working together. A well-rounded approach with security assessments throughout the software lifecycle, including in production, is required.
5. Help security teams help you
Developers may be shouldering more security responsibilities these days, but that doesn’t mean you need to go it alone. Ask your security managers to offer eLearning and remediation coaching.