When DevSecOps Fails

The talk starts from a pattern the speaker has seen across many consulting engagements: security teams bolt several scanners onto a CI/CD pipeline, the pipeline grows from minutes to many hours, false positives break builds, and developers stop trusting the security group. She frames DevSecOps as a cultural change rather than a set of tools, and argues that the common failures are predictable.

The middle of the talk gives concrete fixes. Teams should only fail builds for reasons they can defend, and should tune a new tool outside the pipeline until its results are reliable. Long scans can run out of band on a schedule, with the pipeline checking a pass or fail result. Only a fast subset of tests belongs in CI, and recorded browser sessions can focus a dynamic scanner on the features that changed. Newer pattern-matching scanners can be quicker than deep analysis when a team must cover many applications. Security also belongs earlier in the lifecycle, through requirements, threat modelling, security unit tests, secure coding training and peer review. Triage rules, realistic service level agreements, and management support help teams actually fix what is found.

In the closing section and Q&A, the speaker suggests scaling security champions by prioritising the most sensitive applications and calculating how much time the security staff really has. For a fundamental flaw that cannot be fixed quickly, she proposes a web application firewall or runtime protection as a stopgap. The main takeaway is to start small, communicate expectations, and keep the pipeline a place developers trust.