What Developers Need to Fight the Battle Against Common Vulnerabilities

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^[1]. 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^[2], 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^[3]
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^[4]
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^[5]
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^[6]
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.^[7]

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