Why Code Quality and Code Security Remain Two Separate Ideas

The OWASP Top 10 list of the most critical web application security risks is finally being updated for the first time since 2013. A release candidate was published in April 2017, and the most significant takeaway was what was not on the list; namely, anything new. This is the first update in four years, and the list of vulnerabilities has not changed substantially. The same vulnerabilities – some very easy to remediate, but also highly exploitable – have been featured on this list for years.

In addition, we at Veracode create a State of Software Security report every year based on the hundreds of thousands of applications we scan annually. We too continue to see the same vulnerabilities, in the same volume, appear year in and year out.

These data points are clear indications that quality software is not yet synonymous with secure software. Secure, vulnerability-free code is simply not yet a requirement for most organizations before they ship it. Why is this? There are numerous reasons, but to name a few:

The changing digital economy means speed rules: When software is key to an organization’s ability to compete and innovate, security can be a tough sell. In the development world today, functionality and delivery speed outweigh all else – including security. Enterprises simply can’t stay ahead of the competition without getting new features out fast. With that kind of pressure and speed, security typically falls by the wayside.

Developers are not measured on security: We don’t incent developers based on whether their code is vulnerability-free, or whether they have completed an eLearning course on secure coding. They’re measured on how quickly they release functionality, so naturally, that’s where their focus lies.

The C level is not mandating security: Measuring developers on security will need to come from the C-level. The CIO and CISO together will need to buy in to the idea that code security is a priority. They will have to accept that some speed and functionality might initially be sacrificed in the name of security, and they will have to ask for reports on the state of security in the organization’s apps and the rate of remediation of found security defects. It’s tough to make security a priority if it doesn’t come from the top down.

Not a widespread competitive differentiator: This is starting to change in the B2B world, but has little traction thus far in the B2C world. Consumers don’t consider security at all when purchasing an Internet-connected thermostat or lightbulb. Hence, the rise of botnet attacks using these insecure and Internet-connected devices. But even in the B2B world, enterprises are not demanding frequently enough that the software they purchase needs to be secure, and needs to have proof of security. Until security is truly a competitive differentiator, enterprises simply don’t have enough of an upside to focus on secure coding over speedy delivery.

Bottom line: security needs to be part of the quality measurement

As our world increasingly runs on software, we need a mindset shift on code security. Most organizations would consider it unacceptable to ship code with functionality defects, and we need to reach a point where security defects are equally as unacceptable. Considering the role applications now play in our economy and infrastructure, and the kinds of sensitive information they manage – it’s hard to argue that these types of security defects are acceptable. Ultimately, we can only truly protect today’s digital world when quality code equals secure code.

Continue this conversation on our Cyber Second podcast. In Episode 5, Evan Schuman and Veracode’s Director of Developer Engagement Pete Chestna discuss this disconnect between quality and security in software.