Continuous Exploitation

An Exploration of
Software Supply Chain Security

Navigate this page by searching for a date or topic, Or just enjoy scrolling.

Post 1 — 2/15/24
Why “Shift Left” is Useless Without a Real Security Strategy

Everyone says “Shift Left.” Few actually do it right.

If you’ve spent more than five minutes in DevSecOps, you’ve heard the phrase “Shift Left” thrown around like it’s the cure for all security woes. The idea is simple: move security earlier in the development process so vulnerabilities get caught before they hit production. Sounds great. The problem? Most companies aren’t actually shifting security left—they’re just shifting the blame.

They add a SAST scanner to their CI/CD pipeline, generate a Software Bill of Materials (SBOM) to look responsible, and call it a day. Then, when a breach inevitably happens, they act surprised, wondering how their “security-first” approach failed. The answer is obvious: they were never actually shifting security left. They were just throwing tools at the problem and hoping for the best.

In theory, shifting left was about baking security into development from day one. Security testing should happen at the design phase, not just when an app is about to be pushed to production. Developers should write secure code by default instead of waiting for security teams to dump a vulnerability report on their desk. Security tools should integrate seamlessly into workflows without breaking builds or burying engineers in useless alerts.

But what actually happens in most companies? They dump massive vulnerability reports on developers with no clear priority or remediation guidance. They introduce security gates that slow down deployments but don’t provide real solutions. And when DevOps teams push back, security shrugs and says, “Not our problem.” This isn’t shifting left—it’s shifting responsibility without support.

Too many companies treat security as a compliance checkbox instead of a way to reduce real risk. They track vulnerability counts instead of fix rates, focus on meeting audit requirements instead of improving security posture, and buy expensive tools that no one actually uses properly.

On paper, everything looks great. They’ve got reports, dashboards, and a shiny DevSecOps initiative. But in reality? Vulnerabilities pile up in backlogs, unresolved. Security tooling sits in “monitor mode,” alerting without enforcement. And when an exploit finally happens, leadership starts scrambling, asking, “Why weren’t we prepared?”

If security is going to work, it needs to be part of the development process in a way that makes sense. Developers don’t have time to manually run security scans or sift through endless PDFs. Security should be automated, integrated, and invisible until it actually needs attention. If it disrupts workflow unnecessarily, developers will either ignore it or find ways to work around it, which completely defeats the purpose.

Security controls should operate in the background, catching issues before they become problems. Pre-commit hooks should flag secrets before they ever hit a repo, preventing sensitive credentials from slipping into source control. Static analysis tools need to provide actionable feedback—not just dump an overwhelming list of vulnerabilities that developers don’t know how to prioritize. Dependency scanning should be proactive, identifying risks early in development rather than showing up as an emergency blocker hours before release.

More importantly, fixing security issues has to be a priority, not an afterthought. A critical vulnerability that sits in a backlog for 90 days is just as bad as leaving the front door unlocked for attackers. Companies need clear remediation timelines to ensure security isn’t just about detection but also fast resolution. Critical vulnerabilities should be patched within 24 hours to minimize exposure. High-severity issues should be addressed within a week at most. Lower-priority vulnerabilities shouldn’t just be ignored—they should be assessed based on actual exploitability rather than arbitrary severity scores.

If your vulnerabilities are sitting untouched for months, your security process isn’t shifted left—it’s just broken.

Security Training: Stop Wasting Everyone’s Time

Security training in most organizations is useless. No one wants to sit through a four-hour PowerPoint on SQL injection. Developers need training that actually helps them in the moment. Hands-on labs, Capture The Flag (CTF) exercises, and real-world security challenges are the way to go.

The best approach? Teach security at the moment a mistake happens. If a developer pushes a vulnerable commit, don’t just throw an error—explain why it’s a problem and suggest a fix. Code reviews should include security discussions, so developers build good habits instead of treating security like an annoying afterthought.

Building on the Work of Others

I’m not the first to call out how “Shift Left” without strategy is just security theater. Plenty of people in the industry are already working on making security workable instead of performative.

These experts back up what I’ve seen firsthand: moving security earlier in the pipeline doesn’t work unless it actually leads to faster, automated fixes. If all you’re doing is detecting problems earlier but not fixing them faster, you’re just shifting failure left.