James
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.
Session
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.