How to convince developers to fix their security vulnerabilities?

Ask any security specialist about their biggest frustration. Most of them will bring up their cynicism about finding the same vulnerabilities every year while developers ignore them (the vulnerabilities AND the security analysts).

This sentiment is the source of one of my biggest career disappointments. A few years ago, our offensive security team's morale was down because they got stuck managing administrative controls such as disaster recovery. I took on these tasks, going over my capacity, to allow them more time to hack.

A few weeks after, a pentester quit nevertheless. That left me floored, as I felt motivated by "saving the team"! Turns out the problem was deeper. That individual's issues were with his constant arguments with developers over his findings. I won't put words in his mouth, but the way I interpreted it, his mental state reminded me of how I sometimes feel arguing with my 3-year-old.

How can we build a better relationship? While I can't claim to have figured this out, let me share some common quarrel topics I've encountered while discussing vulnerability management with developers and how I typically approach them.

Disclaimers

"This is disrupting my quarterly objective"

Is this valid: Sometimes

What the developer is really saying: "I understand the flaw, but both my manager and my bonuses are tied to an immediate result, whereas security is all about a potential scenario."

How you should answer: "My quarterly objective is to convince you to fix this." I'm only halfway kidding. In the end, you must remember that quarterly objectives come from a finite mindset. These targets are arbitrary. Threat actors don't care about these. We know they do care about attacking while people are off. So try to work around their "finite" problem by mapping to your own "infinite" calendar. Also, any development team must keep maintenance time in their sprints. If they are compromising on maintenance to reach their targets, then it's time to escalate.

"I need demonstrable proof this is exploitable!"

Is this valid: No

What the developer is really saying: "The fix is doing a boring thing on a codebase I don't enjoy using and I'd rather do anything else than do this, so I'm going to fight back for the hell of it."

How you should answer: "You're spending more time arguing than it would have taken to fix the issue." This is the one scenario that I feel the developers are acting in bad faith. Asking for a full demonstration is likely to cost more to the organization than anything. On the spot, you are not likely to get a positive interaction. From a more political perspective, I recommend ensuring "upstream" to establish your credibility so they'll think again before asking for a proof-of-concept, knowing you are legit.

"I'll add it to the backlog"

Is this valid: Sometimes

What the developer is really saying: "This system has so many issues I'll never get to it anyway. We've got 6 years of bugs to catch up on."

How you should answer: "Alright, we track all vulnerabilities in a central repository. I'll monitor it and your team's overall trends. Let's set up some type of monthly catch-up with someone in your team so we can identify the most urgent wins and I'll make sure to advocate for you whenever I have discussions with engineering managers and directors."

The backlog is where issues go to purgatory. Building a process to hold someone accountable for their backlog is your only hope of getting it prioritized.

"We're deprecating this thing next month anyway, can it wait."

Is this valid: Yes

What the developer is really saying: "I'm deprecating this thing next month anyway, can it wait?"

How you should answer: "Based on what I've seen previously in the organization, deprecation of similar systems took over 6 months. I would go for 30 days, but by my estimates, we are still going to have this legacy system by this time next year. I can extend it to 30 days tops, but if it's more I'll be back with more pressure."

People always underestimate how hard it is to pull the plug on a system, especially if it still brings in money.

"We would need to warn all our partners/customers before we change this application!"

Is this valid: Yes

What the developer is really saying: "This security issue puts me on the spot and I'm almost certain to look bad here by doing a breaking change on an unstable system."

How you should answer: "Yes, we've got access to change management skills in the security team. Let me put you in touch with someone who can establish a timeline and objectives. They'll be the face of it so you won't be stuck on these endless phone calls."

Here's the thing: the concern is entirely valid, but by bringing up the change management person, I'm trying to call their bluff a little bit too, if they are using the "breaking change" scenario to scare me off.

"We would have to fork the lib"

Is this valid: Yes

What the developer is really saying: "Forking is a huge pain in the butt and I don't want this responsibility."

How you should answer: "Indeed. Don't fork. Can you plan to replace this dependency in the short to mid-term instead?"

Forking an open-source project requires considerable maintenance efforts. The whole reason developers use third-party libraries is to not re-write code that has been already reviewed, tested, and is being maintained. Forking puts them in the position of becoming the reviewers, testers, and maintainers. Alright, I said it: I am afraid of forks.

"We are already working on that other security thing you brought up not two weeks ago!"

Is this valid: Sometimes

What the developer is really saying: "I understand what you need but security is one area of concern amongst many competing issues we must deal with."

How you should answer: "Let's look at your issues and I can prioritize with you."

Yes, it's purely a complaint. You can't make security sexy. Sometimes, all you can do is acknowledge how much boring stuff you are bringing to the table, remind the people about the core values of integrity and professionalism, and hope this inspires them enough to accept the task.

"All we seem to do is security stuff, we need to innovate!"

Is this valid: Not really

What the developer is really saying: "Security is a maintenance task, but as a developer, I thrive on solving unknown problems and discovering new solutions. I need to do challenging and creative work."

How you should answer: "This security flaw is probably due to someone innovating too fast. How about adding security design for the next project?"

I admit, this is a tad passive-aggressive, but so is the complaint. I don't see developers as being entitled to innovation, and maintenance is over 90% of the cost of any product. Management is aware of the cost structure. Security can become an "ice breaker" to bring the topic of "you know, development is sometimes a boring job" to younger developers.

"Only internal access. Employees signed a code of ethics"

Is this valid: No

What the developer is really saying: "I trust me and my people to not exploit this vulnerability! Anyway, we've already got access to the system."

How you should answer: "So have you heard about phishing?"

While it's true that malicious insiders account for less than 4% of security incidents, the majority of real breaches involve a level of impersonation. Internal vulnerabilities can be useful for privilege escalation or persistence.

"I know I built this but this is no longer a project"

Is this valid: F— no

What the developer is really saying: "I'm stuck in an organization that is using project management methodologies from 20 years ago. Help me out here."

How you should answer: "Can you do me a favour this one is really bad?"

DevOps was created to address this issue of "having people work on projects instead of products". Essentially: developers would build the software and, once "finished", hand it off to operations. Operations would deal with all the bugs and angry customers, while the developers moved to another project.

If a developer tells you they are not "assigned to the project" anymore, run. This means you are stuck in the past. Developers don't own their products. You will only get things done by circumventing the mess that the official channels are.