We all struggle with ensuring developers consistently follow good security practices in their code. Long gone are the days when basic linting and a quick PR check to make sure no secrets were committed were “good enough.” Today’s threat landscape is broader, more sophisticated, and constantly evolving—which means we have to be far more intentional and vigilant about security.
Historically, security was something we worried about after code was already in production. Penetration tests would run. OWASP scans would surface findings. Tickets would be created and added to the backlog. From there, those issues were prioritized—often against shiny new features—and more often than not, security fixes slowly drifted deeper into the backlog. Maybe one or two would get addressed here and there.
Meanwhile, Information Security teams were (rightfully) frustrated. They needed those fixes in place. Engineering felt pressure from product timelines. Months would go by, risk would remain, and everyone involved would feel stuck.
This is exactly where the idea of shifting security left comes in.
Easier said than done.
On paper, every CIO, CISO, and CTO agrees: “Yes, we should move security earlier in the lifecycle.” But commitment is the real test. Are we willing to delay a release to fix issues up front? Are we pragmatic enough to acknowledge that years of technical debt exist—and that we can’t fix everything all at once?
So how do we make shifting left both achievable and palatable?
The key is this: while we need to introduce guardrails earlier in the SDLC, we can’t slam the brakes on delivery from day one. Gating everything immediately is a recipe for friction and resistance. Instead, we need to observe, analyze, learn, and teach before we enforce.
This post isn’t about which specific tools to use—though I’ll mention what we use and why. It’s also not about how to install or configure those tools; the documentation generally has that covered. This is really about the cultural shift, the mindset change, and—most importantly—accountability.
A High-Level View of a Shift-Left CI/CD Pipeline
Here’s what this looks like in practice.
1. Pull Request Validation
When a pull request is opened or updated, we run a build and validate the changes using static code analysis (for example, SonarCloud). If any issues are introduced by the change, the PR is rejected.
The critical detail here is scope. We only analyze what changed, not the entire main branch. If a developer modifies three lines of code, those three lines are what get evaluated.
2. Software Composition Analysis (SCA)
During the same PR phase, we run an SCA scan to detect vulnerabilities in newly introduced dependencies. Again, this is scoped to changes, not the entire codebase.
3. Standard Build Process
Once the PR is reviewed, approved, and merged, the application flows through the normal build pipeline.
4. Container Image Scanning
If the build produces a container image, we scan it using a container security tool (e.g., Qualys, Snyk). The image must meet an agreed-upon vulnerability threshold before it’s allowed to be pushed to the container registry.
5. Deployment and Dynamic Testing
After passing all prior checks, the application is deployed via CD. At this stage, we run dynamic application security testing (DAST)—for example, using OWASP ZAP. We define clear thresholds and fail the release if high or critical vulnerabilities are detected.
One Important Caveat: Pragmatism Matters
There will be cases where a finding is low risk or contextually acceptable. In those situations, we need an override mechanism—but it must be intentional and accountable.
- Explicit
- Time-bound
- Approved by senior leadership or a clearly designated authority
What About the Existing Codebase?
Shifting left doesn’t magically fix years of existing issues. For legacy code, we run full scans on a regular cadence (weekly, for example) and generate reports. But reports alone don’t reduce risk—because reports don’t fix anything.
What does work is a structured program: regular review sessions, joint prioritization, and a commitment that each sprint addresses at least one security NFR.
The Outcome
When these practices are applied consistently, the results show up quickly: fewer vulnerabilities, faster remediation, reduced business risk, and less friction between Engineering and Security.
Most importantly, security stops being “someone else’s problem” and becomes a shared responsibility—built into how software is delivered.