Today's threat landscape is constantly evolving, and now more than ever, organizations and businesses in every sector have a critical need to consistently produce and maintain secure software. While some verticals - like the finance industry, for example - have been subject to regulatory and compliance requirements for some time, we are seeing a steady increase in attention on cybersecurity best practices at the highest levels of government, with the US, UK, and Australia all shining very recent light on the need for secure development at every stage of the SDLC.

Despite this, attackers are constantly finding new ways to bypass even the most advanced protections and defenses. For example, many have shifted their focus from delivering malware to instead compromising APIs, or launching targeted attacks against a supply chain. And while those high-level incidents are happening with much greater frequency, so too are the more simplistic exploits like cross-site scripting and SQL injection, both of which have been a scourge on cybersecurity defenses for decades. Just last month, a critical SQL injection vulnerability was reported in a WooCommerce WordPress plugin, with a 9.8/10 severity rating.

It's becoming apparent that while cybersecurity platforms and defenses are critical components in defense against modern attacks, what is truly needed is secure code that can be deployed free from vulnerabilities. And that requires a deliberate and committed lift in secure coding standards, actioned by security-aware developers.

Many developers say they are willing to champion security and commit to higher standards of code quality and secure output, but they can't do it alone. We cannot afford to ignore developer needs in the fight against common vulnerabilities, and they need the support of right-fit tools and training, as well as a reworking of the traditional metrics by which they are often judged by their employers and organizations.

Why Most Developers Don't Already Prioritize Security

Coding best practices have continued to evolve over the years, in response to business needs and market trends. In the past, most applications were created using the so-called waterfall development model where software engineers worked to get their code ready to meet an ongoing series of milestones or goals before moving on to the next phase of development. Waterfall tended to support the development of programs that, having met all of the previous milestones along the way, were free from bugs or operational flaws by the time they were ready for the production environment. But by today's standards, it was painfully slow, with sometimes 18 months or more between starting a project and getting to the finish line. And that's not going to fly in most companies these days.

The agile method tended to replace Waterfall, putting a much greater emphasis on speed. And this was followed by DevOps, which is built for even more speed by combining development and operations together to ensure that programs are ready for production almost as soon as they clear the final development tweaks.

Putting speed over security, and nearly everything else beyond functionality, was a necessity as the business environment evolved. In a cloud-based world where everyone is online all the time, and mobile transactions by the millions can happen every few seconds, getting software deployed and into the continuous integration and continuous delivery (CI/CD) pipeline as quickly as possible is mission critical for businesses.

It's not that organizations didn't care about security. It's just that in the competitive business environment that exists in most industries, speed was seen as more important. And developers who could match that speed thrived to the point where it became the primary means by which their job performance was judged.

Now that advanced attacks are ramping up so dramatically, deploying vulnerable code is becoming a liability. The preference is once again shifting, with security increasingly becoming the primary focus of software development, with speed a close second. Bolting on security after the fact is not only dangerous, it also slows the process of deploying software. That has led to the rise of the DevSecOps methodology that attempts to merge speed and security together to help generate secure code, and consider security as a shared responsibility. But developers trained for pure speed can't become functionally security-aware without a lot of support from their organizations.

What Developers Need to Truly Make an Impact on Vulnerability Reduction

The good news is that most developers want to see a shift to secure coding and a reprioritizing of security as part of the development process. In a comprehensive survey conducted by Evans Data of over 1,200 professional developers actively working around the world earlier this year, the overwhelming majority said they were supportive of the concept of creating secure code. Most also expected it to become a priority in their organizations. However, only 8% of the respondents said that writing secure code was easy to accomplish. That leaves a lot of room for improvement within most organizations' development teams between what is needed, and what is required in order to get there.

Simply mandating secure code won't get the job done, and without effort to build the right skills and awareness, it will be highly disruptive to their workflow. Development teams need to exist in an environment that nurtures their security mindset, and promotes a culture of shared responsibility.

The biggest thing that is needed is better training for them, followed by tools that help make secure coding a seamless part of their workflow. And the program should be customized so that less experienced developers can begin their training by learning how to recognize the kinds of common vulnerabilities that often creep into code, with lots of hands-on learning and examples. Meanwhile, more advanced developers who demonstrate their security skills can instead be tasked with more complex bugs and perhaps even advanced threat modeling concepts.

In addition to funding and supporting training programs, including giving developers enough time away from coding in order to properly participate in those programs, organizations also need to change the way that their cohort is evaluated. The primary metric for rewarding developers needs to shift away from raw speed. Instead, evaluations could reward those who can create secure code that is free from vulnerabilities or exploits. Yes, speed can be an evaluated factor as well, but first and foremost, code needs to be secure, and modern development needs to forge a path where security at speed is no longer a myth.

Shipping insecure or vulnerable code should not be an acceptable business risk, and bolting on security after the fact is becoming increasingly ineffective. Thankfully, the best weapon to fight this disturbing trend is having the developer community produce secure code that attackers can't exploit. Most developers are willing to step up to that challenge; give them the support to make it happen.

Secure Code Warrior is one of four companies named in the Gartner® Cool Vendors™ in Software Engineering: Enhancing Developer Productivity report. We're ready to help development teams navigate the complexities of secure software development with tools that make sense in their world. Learn more.

Note — This article is written and contributed by By Matias Madou, CTO & Co-Founder, Secure Code Warrior.