How Not to Roll Out a Security Tool: A Tale of Broken PRs and Regret

No ratings

Presented at BSides Bristol 2026 by

James

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.