What We Learned from Our Vulnerabilities Benchmark Report

We published our first “Vulnerabilities Benchmark Report” (download it here) last week, a synthesis of anonymous data from tens of thousands of students on our training platform, representing hundreds of companies across multiple industries. During the process of developing the report, we were stunned by some of our findings.

One example is the fact that injection vulnerabilities have been either #1 or #2 on the OWASP Top 10 for 14 years! When we dug into the reasons why the statistic has remained unchanged for as long as it has, it made a lot more sense. Injection vulnerabilities are the ones that are most often fixed incorrectly. So while development and QA teams may think that they’ve taken care of a weakness in their software after it’s initially flagged, the reality may be different.

Another startling discovery we made is that the most problematic vulnerability reported by our customers is the use of components with known vulnerabilities. It seems counterintuitive that companies would continue to use software components that they know have vulnerabilities. When we delve into the realities of the contemporary development lifecycle, however, we begin to understand why it’s a problem, and why it could remain an issue for a while.

Development teams are under increasing pressure to deliver more code, more quickly, than ever before. A Dimensional Research report titled “The Emergence of Big Code” states that over 50% of developers surveyed say that today, they have to work with 100x the volume of code that they had to work with ten years ago, and 90% of them report that they are under pressure to release code faster than ever before. Using open source or third party code components is a common solution to the problem of doing more with less time. Since this demand is unlikely to change (and likely will get worse), the use of pre-packaged code will likely persist.

The problems associated with shorter software development lifecycles can manifest themselves in numerous ways. For the developers behind open source and third party components, it could mean delays in developing and releasing patches to fix vulnerabilities because they’re focused on their roadmap. For the programmers who rely on these components, it may mean being slow to implement the patches…