How to Get Developers to Go All-In on Security

We're living in the age of DevSecOps. If you work in software development, it's almost impossible to avoid conversations about how important it is to integrate security into development and IT operations.

But talk, as they say, is cheap. If businesses were excelling at integrating security into development workflows, we'd probably see declining rates of cybersecurity incidents. Instead, each year continues to set new records for the frequency and scope of attacks. This suggests that, although developers may say they care deeply about security, they may not be embracing concepts like DevSecOps as much as chief information security officers (CISOs) would like.

Related: The DevSecOps Model: What You Need To Know

What can businesses do to ensure developers actually make security a top priority? How can they put DevSecOps words into action? This article explores these questions by assessing what would motivate developers to take security super-seriously.

Software Developers and Security

To be clear, I don't mean to suggest that developers don't care at all about security. Most developers do take security at least pretty seriously.

Related: Developer Burnout Fueling Great Resignation Staff Migration

But they also have a number of other priorities, and security doesn't always rank at the top of the list. They have to think about application performance, resource usage cost, keeping code up-to-date, documenting software, and much more.

Again, if developers were obsessing over security in the way that DevSecOps advocates say they should, you'd think we'd be seeing fewer application security breaches. But we're not. And although only some breaches can be attributed to mistakes made by developers (others originate from problems with infrastructure configurations, cloud entitlements, and so on), it would be hard to argue that the typical developer today is doing as much as possible to ensure that code is secure.

Encouraging a Security-First Culture Among Developers

Changing that hinges on three main initiatives: education, better security tooling, and stronger motivations.

1. Education

Security threats come in many shapes and forms. They are always evolving. And in general, developers are not on the front lines of dealing with them.

What this means is that, in general, developers are likely to have less expertise about security risks than ITOps and security engineers, who have to deal with security incidents when they happen.

Indeed, unless your business has really good feedback cycles between developers and other teams, developers may not even be fully aware of how coding mistakes they made led to breaches in production environments. They may also be inclined to assume that security incidents are mostly caused by infrastructure or entitlement configuration issues, not coding flaws. (In reality, all of these problems can lead to breaches.)

So, the first step toward encouraging security awareness among developers is helping them understand how the specific work they do contributes to overall security. You could do this by, for instance, requiring developers to participate in security incident post-mortems. You could also have them review major cybersecurity incidents at other businesses to examine the role that coding issues played in them. Even in situations where the root cause of a breach was not an application problem, weak application security practices could have exacerbated the breach, and developers should be aware of risks like that.

2. Better security tooling

Developers should also be empowered with tools that make it as easy as possible for them to write secure code, as well as identify security risks that may linger within their code.

That may seem obvious, but the fact is that, when businesses think about which security tools to invest in, their minds tend to focus first and foremost on ones that help secure production environments — like Security Incident and Event Management (SIEM) platforms. Those tools are useful for ITOps and security teams, but they don't do much to help developers improve application security. Even container image and binary code scanners are of only limited use to developers because they don't catch vulnerabilities until after the coding process is complete.

So, business leaders should make sure to invest in security tools for developers, too, such as Software Composition Analysis (SCA) and Dynamic Application Security Testing (DAST) tools. These types of solutions can help developers detect security problems during the software development process, rather than waiting until the staging and deployment phases to find flaws. They may also reveal security flaws that arise from poor coding practices (like insufficient data input validation), which standard vulnerability scanners (which can mostly only identify publicly disclosed vulnerabilities) may miss.

3. Motivation for developers

Finally, developers should have strong incentives to care about security. It should be clear what's in it for them to focus on security as a top priority during the development process.

The main developer benefit that businesses should highlight for this purpose is that writing secure code from the get-go reduces the number of mistakes that developers need to fix later, if security problems are discovered after an application release has been built. So, by paying more attention to security, developers can ultimately make their own lives easier because they will have fewer bugs to fix down the line.

Businesses might also consider reducing the pressure they place on their developers to churn out new code quickly. Today's coders are told to release early and often, and there are good reasons for wanting to do that. But release velocity should never come at the expense of security. For that reason, business leaders must let developers slow down the development process a bit if it helps them improve security. And developers should be celebrated and rewarded for achieving strong security outcomes, just as they are lauded for sustaining rapid release cycles.

Conclusion

If developers don't care about security as much as they ideally would, it's not really their fault. They haven't always received the education, tools, and incentives to make security a No. 1 priority.

Fortunately, that's easy enough to change — and any business that wants to make DevSecOps more than just a buzzword should make the necessary changes so developers actually care about security.