Lesson 1 of 9 · 18m
Security as a Feedback Loop, Not a Gate
The real model behind 'shift left': detection latency drives fix cost, and a finding that arrives in minutes teaches — one that arrives in a quarterly PDF teaches nothing.
The worst security programs I've inherited all had the same shape: a security team that ran a scan once a quarter, exported 4,000 findings to a PDF, and emailed it to engineering. Engineering triaged it like spam — because it was. The tools weren't the problem; the feedback loop was broken. A finding that lands three months after the code was written costs ten times as much to fix and teaches nobody anything.
Detection latency is the whole game
Every security finding has a cost curve attached to when it's caught:
- Editor / pre-commit (seconds). The author still has the code in their head. Fixing a flagged secret here costs a minute and a muttered apology.
- Pull request / CI (minutes). The change is open and under review. A blocking check here is annoying but cheap — the author is right there.
- Production / pen test (months). Now the fix needs a ticket, a deploy, maybe a migration or customer disclosure. Same bug, a hundred times the cost.
"Shift left" just means moving each control as early in that sequence as it can reliably run. Not everything fits — a DAST scan needs a running app — but everything that can move earlier should.
Gates vs coaches
A gate that fires on noise teaches developers to route around the pipeline; a coach that explains why something matters teaches them to write less vulnerable code next sprint. The practical difference is usually one config line:
# coach mode: findings land as PR annotations, nobody's build dies
- name: Semgrep
run: semgrep ci --sarif --output semgrep.sarif
- name: Upload results
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: semgrep.sarifSARIF is the detail worth noticing — it's the lingua franca that lets ten different scanners feed one findings view instead of ten dashboards nobody opens.
What "good" looks like
A healthy program isn't "zero findings." It's: every finding lands in front of the person who can fix it, within minutes of the mistake, with enough context to act. Everything in this course is a means to that one sentence.
Field notes
- Count findings developers saw inside their own workflow, not findings a dashboard stored. Those are different numbers and only one of them matters.
- The annual pen test still matters — it finds what tools can't. But it's a depth check, not a detection strategy.
- "Fail the build" is a privilege you spend. Spend it only on findings you'd wake someone up for.