Micro Focus is now part of OpenText. Learn more >

You are here

You are here

What 8 million software security flaws can teach businesses

Chris Wysopal Chief Technology Officer, Veracode

What lessons can be learned from scanning 85,000 software applications in 12 months and analyzing the 8 million flaws revealed in those tests?

An analysis found that 83% of applications have at least one flaw, and that information leakage (64%), cryptographic issues (62%), and CRLF injection (61%) are the most common flaws. In addition, two out of three applications fail to pass initial tests based on the OWASP Top 10 and SANS 25 industry standards.

Put simply, our software is insecure—indeed, as insecure as it was a decade ago. The challenges organizations face with adhering to secure coding practices are apparent, despite much greater awareness of software security and acceptance from developers and security teams alike in following practices that equate quality code with secure code.

So why is the software powering business around the world in every industry insecure? We can point a finger at the volume of software, the demands on these teams to operate within ever faster release cycles, and a dearth of secure coding education. Yet even with these macro elements in play, the march toward securing the world’s software isn’t doomed.

In fact, there are signs of real progress that indicate a more secure future. In my talk at RSA, “8 Million Findings in One Year: Fresh Look at the State of Software Security,” I share more on why I have that belief.

Here are some of the key findings that can help businesses gain perspective as they strategize to secure their applications and support their developers with the proper technology and training.

Fixing, not just finding

Imagine identifying a problem, then setting it aside without having a plan to fix it. Many times, software testing does just that—it finds flaws, but there is no structure in place to empower developers to fix them. Fixing flaws early in the software development lifecycle (SDLC) is more cost-effective and faster than later in the pipeline.

The analysis found that fixing vulnerabilities has become just as much a part of the development process as improving functionality, suggesting developers are shifting their mindset to view the security of their code as equal to other value metrics. More than half of all flaws found—56%—are being fixed. While this may not sound like a huge number, it is a vast improvement from 10, five, or even three years ago.

Software flaws are persistent, but not impossible to overcome. The overall prevalence of flaws has risen 11% compared to a decade ago, but the proportion of flaws categorized as high-severity dropped 14% over the same period.

This means developers are very likely to fix high-severity flaws, so there is solid evidence that development teams are getting better at figuring out which flaws to fix first. Once again, the data shows that organizations are increasingly focused on not just finding security vulnerabilities, but fixing them, and prioritizing the flaws that put them most at risk.

[ See TechBeacon's special coverage of RSA Conference 2020. Plus: Don't miss the post-conference highlights from RSAC 2020. ]

Security debt is real, and needs to be prioritized 

Like credit card debt, carrying even a small balance of security debt forward on a recurring basis can quickly leave you in the hole. The analysis of 1.4 million application scans over one year reveals that the longer software flaws stick around, the less chance they will be corrected, which adds to an organization’s security debt.

Security debt—defined as aging and accumulating flaws in software—is emerging as a significant pain point for organizations across industries. About half of applications are accruing debt over time, a quarter are driving it down, and another quarter are breaking even. Leaving old flaws may be attractive to development teams because they probably didn’t create them, but those long-unaddressed findings will inevitably come back to haunt an organization.

The recommendation here is to address new security findings while chipping away at the old. The data indicated that how frequently an application is scanned has a direct impact on overall security debt. The top 1% of applications with the highest scan frequency carry about one-fifth the security debt of the bottom third, suggesting that frequent scanning does more than help find flaws—it helps companies significantly reduce risk.

DevSecOps can make a huge difference

Despite the continued prevalence of flaws, development teams are making strides in keeping up with these vulnerabilities—70% are either reducing the number of flaws after first scan or not introducing any other flaws by the time of the final scan. The frequency and cadence of security testing are tied to changing habits to reduce security debt. DevSecOps is the integration of security and compliance testing into development pipelines as seamlessly and transparently as possible, without reducing the agility or speed of developers or requiring them to leave their development environment.

What’s more, applications scanned less than once per month require a median time to remediate (MTTR) of 68 days, yet development teams with more frequent scanning quickly become generators of secure software. Teams that scan daily show an MTTR of just 19 days, contributing to lower security debt accumulation over time.

Organizations can also reduce security debt by teaching developers secure coding practices through interactive web apps based on modern threats that developers exploit and patch. They should also consider creating security checklists for developers for all new feature and scanning codebases following each nightly build.

Secure code is hard but not impossible

With so many applications and flaws, it’s easy to get overwhelmed. Achieving mature application security programs and improving secure coding practices is a marathon, not a sprint. Organizations can take these lessons to heart directly from other companies who are constantly striving to improve their application security programs. The challenge is difficult, but not impossible to meet.

Keep learning

Read more articles about: SecurityApplication Security