Incentivizing Developers is the Key to Better Security Practices

Professional developers want to embrace DevSecOps and write
secure code, but their organizations need to support this seachange
if they want that effort to grow.

The cyber threat landscape is becoming more complex by the day.
Attackers are constantly scanning networks for vulnerable
applications, programs, cloud instances, and the latest flavor of
the month is APIs, widely considered an easy win thanks to their
often lax security controls.

They are so persistent that new apps can sometimes be
compromised and exploited within hours of deployment. The Verizon
2021 Data Breach Investigations Report makes it very clear that the
threats leveled against businesses and organizations are more dangerous^[1]
today than at any other point in history.

It’s becoming very clear that the only way to truly fortify the
software being created is to ensure that it’s built on secure code.
In other words, the best way to stop the threat actor invasion is
to deny them a foothold into your applications in the first place.
Once you start fighting that war, most of the advantages are skewed
towards the attackers.

This situation first gave rise to agile development^[2]
and DevOps, and later to the entire DevSecOps
movement^[3], where security is a
shared responsibility for everyone involved in the process of
creating software from development to deployment. But the base of
that pyramid, and arguably the most important part, are the
developers. While most developers want to do their part and write
secure code, many of the organizations they work for are less
supportive of the changes such a major shift in priorities
requires.

Defeat by Design

For many years, developers were told that their primary role at
their organizations was to quickly build and deploy apps in a
fast-paced environment, where business never stops and customers
never sleep. The faster that developers could code and the more
features they could deploy, the more valuable they were seen in
terms of their performance reviews.

Security was an afterthought, if it was considered at all.
Instead, all of that was left to the application security (AppSec)
teams to figure out. AppSec teams were disliked by most developers
because they would often send completed applications back into
development to apply security patches or to rewrite code to
remediate vulnerabilities. And every hour that a developer spent
working on an app that was already “finished” was an hour they were
not creating new apps and features, thus decreasing their
performance (and their value, in the eyes of a particularly
punitive company).

And then the threat environment changed the importance and
prioritization of security for most companies. According to the
recent Cost of a Data Breach Report^[4] from IBM and the Ponemon
Institute, the average cybersecurity breach now costs about $3.8
million per incident, although that is hardly the upper limit. One
company alone incurred $1.3 billion in losses following a breach on
their network. The companies of today want the security offered by
DevSecOps, but, sadly, have been slow to reward developers who
answer that call.

Simply telling the development teams to consider security won’t
work, especially if they are still being incentivized based on
speed alone. In fact, within such a system, developers who take the
time to learn about security and secure their code could actually
be losing out on better performance reviews and lucrative bonuses
that their less-security-aware colleagues continue to earn. It’s
almost like companies are unwittingly rigging the system for their
own security failures, and it comes back to their perception of the
development team. If they’re not seeing them as the security
frontlines, then it’s very unlikely a viable plan to utilize their
workforce will come to fruition.

And this doesn’t even account for the lack of training. Some
very skilled developers have decades of experience coding, but very
little when it comes to security… after all, it was never required
of them. Unless a company provides a good training program to its
skilled programmers, it can hardly expect its developers to
suddenly gain new skills and put them into action in a meaningful
way that actively reduces vulnerabilities.

(Are you already security-confident and want to
compete against other secure coding all-stars? Join
Secure Code
Warrior‘s Devlympics
2021, our biggest and best global
security tournament, and you could win big!)^[5][6]

Rewarding Developers for Good Security
Practices

The good news is that the overwhelming majority of developers do
their job because they find it both challenging and rewarding, and
because they enjoy the respect that their position entails.

Lifelong professional coder Michael Shpilt recently wrote about^[7]
all of the things that motivate him and his coding colleagues in
their development work. Yes, he lists monetary compensation among
those incentives, but it’s surprisingly far down the list. Instead,
he prioritizes the thrill of creating something new, learning new
skills and the satisfaction of knowing that his work is going to be
directly used to help others. He also talks about wanting to feel
valued within his company and community. In short, developers are
like a lot of good people who take pride in their work.

Developers like Shpilt and others don’t want threat actors
compromising their code and using it to harm their company, or the
very users they are trying to help. But, they can’t suddenly shift
their priorities to security without support. Otherwise, It’s
almost like the system will be working against them.

To help development teams improve their cybersecurity prowess,
they must first be taught the necessary skills. Utilizing
scaffolded learning, and tools like Just-in-Time (JiT) training can
make this process much less painful, and helps to build upon
existing knowledge in the right context.

The principle of JiT is that developers are served the right
knowledge at just the right time, for example, if a JiT developer
training tool detects that a programmer is creating an insecure
piece of code, or is accidentally introducing a vulnerability into
their application, it can activate and show the developer how they
could fix that problem, and how to write more secure
code^[8] to perform that same
function in the future.

With a commitment to upskilling in place, the old methods of
evaluating developers based solely on speed need to be eliminated.
Instead, coders should be rewarded based on their ability to create
secure code, with the best developers becoming security champions^[9]
that help the rest of the team improve their skills. And those
champions need to be rewarded with both company prestige and
monetary compensation. It’s also important to remember that
developers don’t typically have a positive experience with
security, and uplifting them with positive, fun learning and
incentives that speak to their interests will go a long way to
ensuring both knowledge retention and a desire to keep building
skills.

Companies can still include coding speed as one part of a
developer’s evaluation, but with the expectation that developing
secure applications might take a little longer, especially as
coders are learning those new skills.

DevSecOps can be the ultimate defense against the dark arts of
an increasingly dangerous threat landscape. Just don’t forget that
the champions of this new world, the developers who are
consistently creating new code, need to be respected and
compensated for their work.

Want to put your security skills to the test against
other developers all over the world? Check out
Secure Code
Warrior‘s Devlympics
2021, and you could take out a major
prize in our global tournaments!^[10][11]