Every engineering org I've worked with has, at some point, announced a "shift-left security" initiative. And at almost every one of them, the initiative looked the same: add a SAST scanner to the CI pipeline, send developers a link to the OWASP Top 10, declare victory.
Six months later the scanner output is noise, developers have learned to suppress alerts, and the security team is still reviewing the same class of vulnerabilities that the scanner was supposed to catch.
Here's what's actually going wrong — and what I've found works.
The tool-first trap
SAST tools are genuinely useful. But dropping a Semgrep or Snyk Code rule set into a pipeline without context is like handing a junior developer a linter and calling it a code review.
The problem is the feedback loop. A scanner that surfaces 300 findings in a single PR teaches developers one thing: ignore the scanner. Security debt grows; trust erodes. The pipeline feels like a tax, not a safeguard.
The fix isn't a better scanner. It's tuning with developers, not at them.
At Atlassian I spent the first three weeks of our SAST rollout pairing with engineers to go through the initial finding set rule by rule. We suppressed anything we couldn't fix in under a sprint. We wrote custom rules for patterns unique to our codebase. The resulting baseline was 40 findings, not 400 — all actionable, all with documented remediation paths.
Result: developers started treating the scanner like a useful colleague rather than an obstacle.
Threat modelling before code, not after
Most organisations bring security in at code review or QA. By then the blast radius of any design-level vulnerability is enormous — refactoring an authentication flow or an access control model post-implementation costs 10x what it would have in a design session.
My preferred format is a 60-minute threat model at the start of any feature that touches:
- Authentication / authorisation boundaries
- Data ingress from external sources
- Inter-service communication
- Storage of sensitive data
You don't need a formal methodology. A whiteboard, a dataflow diagram, and four questions suffice:
- What are we building?
- What could go wrong?
- What do we do about it?
- Did we do it?
The output is a short doc, a handful of security acceptance criteria added to the ticket, and — critically — shared ownership between security and the feature team.
CI/CD security is about gates, not walls
A common mistake is treating security gates as blocking hard stops. Every pipeline failure that stops a release without a clear path to resolution is a future policy exception. Enough exceptions and the gate becomes symbolic.
What works better is a tiered model:
- Block: Only on findings with a known exploit, high confidence, in code that ships to production. This tier should be small and rarely triggered.
- Warn: Medium-confidence findings, dependency vulnerabilities with no fix yet, policy drift. Logged, tracked, reviewed in the next sprint.
- Inform: Low-confidence findings, informational notes, metric baselines. Visible in dashboards, not in PR comments.
This keeps the pipeline fast, keeps developer trust high, and makes the rare hard block credible rather than routine.
The metric that actually matters
Security teams often measure vulnerabilities found. That's a lagging indicator of tool activity.
The number I care about is mean time from vulnerability introduction to remediation. If a critical finding takes three months to fix after discovery, the pipeline isn't working regardless of how many issues were caught. If it takes three days, you've built something real.
Track it per severity, per team, per product area. The outliers will show you exactly where the friction is — whether it's unclear ownership, missing remediation guidance, or a specific team that needs a different kind of engagement.
Shifting security left only works when security is a feature of the development experience, not a checkpoint at the end of it. The tooling is table stakes. The real work is building the feedback loops, the shared vocabulary, and the trust that turns security from a tax into a multiplier.
If you're building or rebuilding a DevSecOps programme and want to think through the approach, book time on Topmate — happy to dig in.