How Not to Roll Out a Security Tool: A Tale of Broken PRs and Regret
In DevSecOps, we all love a vendor shootout. Which scanner has the best coverage? Which dashboard is the slickest? Which tool flags the most CVEs?
But the truth is that rolling out a security tool is 20% getting the invoice paid and 80% communication and desperately trying not to break everyone’s builds. Get that 80% wrong, and you don’t get security. You just get developers figuring out how to bypass you.
This talk is a post-mortem of an easy mistake from early in my career. I dropped a shiny new software composition analysis (SCA) tool straight into our CI/CD pipeline before I’d tuned the noise, agreed on a rollout model, or given developers a sensible way to respond. For a few newer microservices, it was an inconvenience that could be fixed, but for our core legacy monolith? It was a self-inflicted denial-of-service on delivery.
PRs backed up. Releases stalled. Trust evaporated, and security instantly became the dreaded “Department of No.” Ultimately, I had to turn the tool off for the monolith so we could get releases out the door.
The lesson was brutal but simple: I hadn’t secured the pipeline. I had just trained the engineering team to route around me.
We’ll break down exactly what went wrong and how to fix it. We’ll look at how to roll out tooling without the fallout, how to separate visibility from enforcement, and how to introduce blocking controls that engineers actually respect.
This is a pragmatic, trench-level DevSecOps talk about the massive gap between buying a security tool and actually changing engineering behaviour.
I’ll be walking through my own botched rollout of an SCA tool into CI/CD. It’s a story of how default blocking rules, noisy findings, and legacy tech debt combined to create massive delivery friction instead of any actual risk reduction.
We aren't going to blame the vendor, and we aren't going to blame developers for "not caring about security." Instead, we'll dissect what the rollout got wrong systematically:
- Confusing visibility with control.
- Turning on blocking before earning developer trust.
- Treating a 10-year-old monolith the same as a greenfield microservice.
- Throwing contextless findings over the fence without remediation support.
We'll then pivot to a rollout pattern that actually works in production. We’ll cover how to start in audit mode, baseline your existing risk, aggressively tune out the noise, and establish clear ownership. Most importantly, we'll talk about building a paved road - where you only block on high-confidence issues and have an exception process ready before the engineers actually need it.
You’ll walk away with a battle-tested blueprint for dropping security controls into a pipeline without nuking your delivery flow or alienating your entire engineering department.
James Elliott builds security that ships, not security that says no. As a DevSecOps Engineering Manager, he spent his formative years breaking and fixing production pipelines as a developer and sysadmin. Having seen both sides of the friction between security teams and engineering, he now focuses on the human element of DevSecOps: tuning out the noise, separating visibility from enforcement, and proving that a 70% control a team actually runs beats a 100% control they route around. When he isn't untangling legacy monoliths, he can usually be found touring far and wide on his motorcycle.