Why your Sec and Dev teams are butting heads

Why won’t Dev and Ops teams engage with your security program? Perhaps they’re sticking their heads in the sand, wilfully creating security holes. Uncaring. Perhaps they don’t understand the threat landscape, or they’d be taking this a lot more seriously!

Perhaps.

Or. Maybe the security team needs to take more responsibility. Perhaps it’s a much bigger issue than technologies or threat landscapes, or wilful ignorance.

Delivery teams can see how passionate you are, but often they don’t buy in. The primary reason is that you’re not telling a compelling story!

What’s in it for them, what’s their part in this story?

Do they know how seriously this risk is seen by the business? You may need Senior Leadership to lay some groundwork here. Without a tone-from-the-top which prioritises security initiatives, who can blame the dev teams for trying to put out all the other ‘fires’ in the business.

This is an extension of the buy-in objection. Companies hire smart engineers and tech leaders who generally want the best for the business. They should be asking serious questions of you as to why this ‘security priority’ is a ‘business priority’ and why it rises to the top of the priority list.

It’s possible they lack perspective, but let’s face it – not every dollar invested in security initiatives provides a meaningful ROI. Some possibilities:

• You haven’t presented or requested the cost of the proposed control.
• There’s no obvious qualitative proposal showing risk vs reward proposed.
• You haven’t explicitly addressed the opportunity cost. No one has ‘free time’.
• You haven’t asked them, “what needs to be dropped to achieve this?”

You’ll often encounter low motivation, even when teams have understood why the project is important. I’ve observed the following:

• The teams feel their security efforts to date were not recognised, or it feels like a drop in the infinite ocean of outstanding compliance actions.
• You didn’t learn and consider the baseline metrics of the teams, such as how long it takes to complete a patching cycle, what their shipping cadence is etc.
• Imposing an impossible timelines without prior engagement kills your credibility with the delivery team, and erodes your influence.

Often the dev team doesn’t feel like a respected equal partner. This could be because:

• They think you’re talking down to them or use a lot of insider jargon.
  • The reverse is sadly very true. There’s a whole lot of ‘othering’ between tech teams.
• You are viewed as a perfectionist rather than a pragmatist.
  • You often say ‘no’, but don’t engage to help find other potential solutions.
  • You insist on the ‘letter of the law’ even when it doesn’t make sense for the use case. Dogmatic statements like ‘it’s industry standard’ don’t build strong relationships.

• You didn’t have a clear, realistic or agreed outcome.
• Are you measuring progress against clear deliverables. I see yellow flags anytime I hear ‘poor engagement’ instead of ‘failure to deliver’.

And you need to communicate on a regular basis thereafter. Some more anti-patterns here:

• You didn’t keep them in the loop, but just assumed they had it completed.
• Your request was likely pre-empted by another high priority mission.
  • Your commitment ‘fell-off’ the priority list.
  • Did you have executive sponsorship. You know, the big stick?
  • Another VP wielded their big stick to get their priorities approved before yours.
  • Maybe they know about your project – maybe not.