CVEs aren't the problem. When you find them is.
CVEs in code land at the worst possible moment — after the build has shipped.
If your team has ever lost a sprint to emergency dependency upgrades, this is for you.
The Recurring CVE-Fix Loop Paradox
Stage 1: Denial
The PR scanner flags a vulnerable package. The warning is non-blocking. The PR merges. The warning joins a pile no one reads.
Stage 2: Acceptance
Weeks later, PSIRT files a ticket.
Stage 3: Crisis
The fix gets squeezed into a sprint nobody planned for it.
The gap isn't a missing tool — the PR scan tool is already in place. The gap is where and when the feedback shows up.
By the time PSIRT shows up, the developer has moved on — and reloading the context costs more than writing the code did.
Why the Loop, loops...
Shifting security left sounds clean on a slide. In practice, teams hit real friction:
| Friction | What it looks like in the real world |
|---|---|
| Sprint velocity vs. security depth | PRs merged is the scoreboard. Security gates feel like drag. |
| Threats don't pause | New CVEs drop daily. Weekly scans are already stale. |
| Tool fatigue | More scanners, more dashboards, more alerts nobody reads. |
| Transitive dependencies | Your direct deps are clean. The CVE is three levels down. |
| Cultural inertia | "Security team's problem" thinking parks it at the end of the pipeline. |
Breaking the Loop
Security that lasts moves with developers, not against them.
The strongest setups don't just catch vulnerabilities — they stop them from showing up.
Developers catch issues while they're still typing. Vulnerabilities never make it past the laptop. Releases go out quieter.
What is Shift-Left Security?
Shift-left security is pulling security decisions earlier, closer to the code, closer to the people building it.
The traditional development cycle follows a familiar path:
Security usually shows up after the build. The code has moved on. The fix becomes a fire drill.
Shift-left flips that timeline. Checks live in planning and coding, so vulnerabilities surface while the developer still has full context.
It's not about more tools. It's about feedback in the right place — the editor, the terminal, the PR. Inline findings get acted on, because they respect the developer's flow.
Implementing Shift-Left: Catch It at the Keyboard
The earlier a CVE is caught, the cheaper it is to fix.
Best case: vulnerable code never gets committed. The catch happens locally, in seconds.
Here's what "good" looks like:
1. At the dev machine
Local CVE scanner before push. IDE plugins flag risky code as it's written. Pre-commit hooks catch the res
2. At the PR
Bots scan every change. CI fails when a CVE lands in a called code path.
3. For dormant repos
Automation opens fix PRs the moment a CVE drops.
You can't wait for weekly scans or quarterly reviews. By then the code has moved on, the developer has moved on, and the fix is a context-switch, not a quick edit.
Shift Left All the Way...
Security shouldn't sit at one checkpoint — it belongs at every phase.
Planning — Surface risks during sprint planning so they shape the design, not the patch.
Coding — Catch vulnerabilities while the developer still has full context.
Building — Hook static analysis and dependency scans into the build. Issues surface before review, not after deploy.
Deploying — Lock down the CI/CD pipeline itself.
Running — Monitor in production. Feed findings back into earlier phases so the next iteration ships safer.
When security moves left, fire drills move out.
Fewer surprise CVEs. Fewer rushed fixes. Just code that ships with quiet confidence.
Wrestled with this loop — or broken out of it? Drop a note in the comments.
Points to Ponder
- Shift-left isn't more scans — it's earlier feedback. Editor: minutes. PSIRT report: a sprint.
- Security belongs at every stage, not just one checkpoint.
- Run a CVE scanner locally and in CI. Catch issues before they leave the laptop.
- Automate updates for dormant repos. Auto-PRs keep stale code from rotting.
- Make merge gates real. Warnings that don't block become noise.
- Culture beats tooling. Checking for CVEs should be as routine as running tests.
Top comments (1)
“Warnings that don’t block become noise” — probably the most accurate line in the article. 👏🏻👏🏻👏🏻