"Shift left" is one of the most abused phrases in security. In ten SSDLC rollouts across the last three years, we've seen the same three patterns work consistently — and the same three anti-patterns quietly kill momentum. Here's the pattern library.
Patterns that work
1. One security review gate, not five
Teams that succeed have *one* gate: a threat-model-style review before design lock. Tools run continuously, but the *human* gate is once per feature.
Teams that fail have: a design review, a pre-commit security review, a pre-deploy security review, and a post-deploy sign-off. The friction compounds. The team routes around it.
2. SAST findings land in the author's IDE
When a SAST finding shows up in the PR comments 48 hours after the author forgot about it, the finding dies. When it shows up inline in the editor as the author types, the finding gets fixed.
Every successful program we've seen has IDE-integrated SAST. The commit-hook tier is table stakes. The PR-comment tier is noise without action.
3. Security champions with real time allocation
Programs that work budget 20% of a designated engineer's time for security-champion duties. Programs that fail say "also be a security champion" to the senior engineer who is already over-allocated.
The 20% isn't optional. Without it, the champion role is a fiction.
Anti-patterns that kill rollouts
1. The magic tool rollout
"We bought a tool. Now we're secure." We've seen Snyk, Semgrep, CodeQL, and Checkmarx each described this way. The tool doesn't care whether anyone reads its output. The program does.
A SAST rollout without tuning generates 10,000 findings, 95% of which are noise. Engineering develops immunity. You now have a worse situation than before.
2. Security as a veto
When security gets to block a release, two things happen: security blocks some releases, and engineering stops talking to security. The second consequence is the expensive one.
Security's leverage should be: "I've read this, here's what I found, here's my confidence level." Not: "I will stop your release if I'm unhappy."
3. Metrics theater
"We ran X scans this quarter." Nobody cares. The metric that matters is: median time from finding discovered to finding fixed, by severity. Every other metric is theater.
If your security dashboard doesn't show that number trending down over time, your program isn't working.
The rollout shape that works
Month 1: threat modeling gate on one team, one feature. No tools yet.
Month 2: bring in SAST, tune aggressively for that one team. Accept 80% reduction in findings before anything lands in PR review.
Month 3: security champion from that team. 20% allocation. Real time.
Month 4: second team. Same pattern. The first team is your case study.
Month 6: measure mean time to fix by severity. Publish it.
Month 9: third team, fourth team. By now the pattern library exists.
Month 12: every team. The program runs because it's part of how engineering works, not because security enforces it.
What to stop doing
- Running security town halls.
- Publishing "security policy" documents nobody reads.
- Buying tools before tuning the ones you have.
- Counting scans.
- Blocking releases.
What to start doing is the inverse: fewer gates, tighter feedback loops, real engineering time budgeted, one number that matters.
No marketing fluff. Unsubscribe anytime.