Developers Hate Stop Signs, Not Security

How’s the relationship between your engineering and security teams? If things could be better (maybe a lot better), you’re not alone.

Why do so many developers have an almost reflexive antagonism toward security alerts? Here’s some food for thought:

• A typical software organization with an AppSec team must respond to approximately 120,000 security alerts every year.
• 86% of DevSecOps respondents in a recent survey said security negatively impacts development speed.
• 91% of developers get security training, but 70% of development teams skip security steps.
• Only 29% of developers prioritize writing vulnerability-free code.

Developers get bonuses and promotions when they’re productive—and security alerts are a roadblock. When you’re trying to win a race, it’s hard to love a stop sign.

The Priority Tug-of-War

Speaking with developers about the issue, I’ve come to realize that a huge amount of the resentment toward security practitioners and alerts has to do with fundamental imbalances between security and engineering departments.

A major security flaw could be the most important item on your to-do list (because you’ll be the one dealing with the fallout if there’s a breach), but to the developer responsible for writing the code, fixing it feels like an annoying and unwelcome housekeeping task.

That’s one part of the imbalance: priorities and consequences.

Then there’s the skewed amount of effort required from each stakeholder. From security’s perspective, triaging the issue and sending it to the right developer may take only moments. In many cases, these alerts are totally automated. The developer, on the other hand, may need to work for hours to implement a fix.

So if it’s security’s priority—and security’s neck on the line if something goes wrong—why are the developers the ones spending all their time on fixes? On the security team, of course, we know many answers to that question (starting with: there’s 100x more developers than there are security guys, and we don’t know their code the way they do!). But these arguments fall on deaf ears.

What if developers deprioritize security because it just feels unfair?

Level the Playing Field With Automated Fixes

As a result of the fundamental imbalances I’ve described above, security and engineering departments both feel resentful—and everyone’s convinced they’re getting the worst end of the deal. Security feels like developers ignore alerts and don’t understand why security controls are important, while developers see security as a nuisance that doesn’t understand why developer productivity is important.

Now, let’s really think big: what if you could bring balance to this broken state of affairs?

That’s what automating fixes is all about. If it takes developers only a few moments to fix their code, security no longer needs to ask them to spend hours on remediation. Instead, you can get into a groove of super-fast fix cycles that make developer teams happier, more productive, and much less likely to ignore the next alert they see.

As AI-based tooling accelerates fixes, the developer side of the AppSec equation can finally benefit from security tools that lessen their work rather than add to it — and that’s something everyone can celebrate.