Shifting Left: Catching Vulnerabilities in the CI/CD Pipeline

Shifting left means finding vulnerabilities while code is being written and built, not after it reaches production. In practice, that means running a set of automated checks in your CI/CD pipeline: static analysis (SAST), dependency scanning (SCA), secrets scanning, infrastructure-as-code (IaC) scanning and container image scanning on every change, with dynamic testing (DAST) against a staging environment. The scanners are the easy part. What makes it work is a gating policy that blocks only on findings that are both serious and exploitable, a fast developer experience, and clear ownership of every finding.

Why shift vulnerability detection left?

A flaw caught in a pull request is fixed by the developer who just wrote it, while the context is fresh, in a change nobody has deployed yet. The same flaw found in production needs triage, a ticket, a scheduled fix, a release and often an emergency change window.

Shifting left also catches problems that production scanning handles poorly. A hardcoded credential or an overly permissive cloud storage policy is much better stopped before it's deployed than discovered afterwards.

It doesn't replace production scanning. New vulnerabilities are disclosed in software that's already running, and configuration drifts after deployment. Pipeline checks reduce what reaches production; they don't guarantee production is clean.

Which security scans belong in a CI/CD pipeline?

Each scanner type finds a different class of problem, and they run at different speeds. That determines where each one fits.

Static application security testing (SAST)

SAST analyzes source code without running it, looking for patterns such as untrusted input reaching a database query or a shell command. It's usually the noisiest scanner in the pipeline, so tuning matters more here than anywhere else. Start with a focused, high-confidence rule set and expand once developers trust the results.

Software composition analysis (SCA)

SCA inventories your open-source dependencies and matches them against vulnerability data. Run it on pull requests to catch new vulnerable dependencies, and on a schedule against your main branch, because new vulnerabilities appear in packages you already use. Generating an SBOM at build time gives you a record you can recheck later without rebuilding.

Secrets scanning

Secrets scanning looks for API keys, tokens, private keys and passwords committed to code. Stolen credentials are one of the most direct paths into cloud accounts and internal systems, which makes this one of the highest-value checks you can add.

Run it as early as possible: in a pre-commit hook or at push time, so the secret never lands in shared history. When one does get committed, removing it from the code isn't enough. Revoke and rotate it, because anyone with access to the repository history may already have it.

Infrastructure-as-code (IaC) scanning

IaC scanners check Terraform, cloud templates, Kubernetes manifests and Helm charts for risky configuration before anything is provisioned. Typical findings include storage buckets open to the public, security groups allowing administrative ports from anywhere, unencrypted databases and containers running as privileged.

An exposed storage bucket often comes down to one wrong setting in a template, and IaC scanning is the cheapest place to catch it. Pair it with policy as code, so the same rules apply in the pipeline and in the cloud account.

Container image scanning

Scan each image after it's built and before it's pushed, covering both operating system packages and application libraries. Often most image findings come from the base image, so standardizing on a small set of minimal, regularly rebuilt base images cuts the volume more than any amount of triage. Keep rescanning images in your registry as new vulnerabilities are published.

Dynamic application security testing (DAST) in staging

DAST tests the running application from the outside, the way an attacker would. It finds problems that only exist at runtime, such as missing security headers, broken access control on specific routes, and injection flaws that static analysis couldn't confirm.

Because DAST is slow and needs a deployed application, run it against staging after each deployment or nightly, not on every pull request. Use authenticated scans so it can reach pages behind a login. Avoid pointing aggressive DAST scans at production without agreement from the application owner.

How should you set gating policies?

A gate is a rule that decides whether a pipeline passes. Gates are where shift-left programs usually succeed or fail. Too loose, and nothing changes. Too strict, and developers route around the pipeline.

A policy that works well for many organizations is simple: block on critical and exploitable, warn on the rest.

Block the build when a new finding is:

• Critical severity, and
• Exploitable in practice, meaning it's listed in CISA's Known Exploited Vulnerabilities catalog, has a high EPSS score or is reachable from your code, and
• Fixable, with an upgrade or code change available.

Also block any verified live secret, whatever its other attributes. Once developers trust the gate, you can extend blocking to high-severity findings that meet the same conditions.

Warn, but don't block, when a finding is:

• Medium or low severity
• Critical but not reachable, or with no fix available yet
• In test code, examples or documentation

A few supporting rules make this workable:

• Gate on new findings only. Compare against a baseline so developers aren't blocked by issues that predate their change. Track existing findings separately with their own remediation targets.
• Allow exceptions with an owner and an expiry date. Some findings will be accepted risks. Record why and revisit them.
• Keep a break-glass path. An urgent production fix shouldn't be blocked by an unrelated medium finding. Log the override and review it afterwards.
• Apply the same policy everywhere. If one team's pipeline blocks and another's doesn't, the policy loses credibility.

What makes a good developer experience?

Developers will use security tooling that is fast, accurate and shows up where they already work. They'll avoid tooling that isn't.

• Put results in the pull request. Inline comments on the changed lines beat a link to a separate dashboard.
• Keep pull request checks fast. Run incremental scans on changed code, and move slow scans to scheduled or post-merge jobs.
• Explain the fix. Each finding should say what's wrong, why it matters and what to change, including the fixed dependency version where relevant.
• Offer local checks. IDE plugins and pre-commit hooks catch issues before a push.
• Keep results consistent. The same finding shouldn't appear in the pull request, disappear in CI and reappear in the registry scan.

How do you avoid alert fatigue and overblocking?

Alert fatigue sets in when most findings turn out to be noise. Developers stop reading results, bulk-suppress warnings or push to have the gate removed. Overblocking is its sharper cousin: builds fail often enough that teams lose delivery time and look for ways around the pipeline.

Watch for the warning signs:

• A rising number of overrides or suppressions
• Findings that sit open with no response
• Complaints that the pipeline is "always red"
• Teams disabling scanners in their own pipeline configuration

To prevent both, roll out new scanners in monitor-only mode first, measure what they would have blocked, and tune before enforcing. Retire rules that mostly produce false positives. Review the gating policy every quarter with input from engineering, not just security.

Who owns shift-left findings?

A finding without an owner doesn't get fixed. Decide ownership before turning on enforcement.

• Application teams own findings in their code, dependencies and service-specific configuration. Route findings using repository ownership files or a service catalog.
• The platform team owns shared base images, pipeline templates and common IaC modules. A vulnerable base image is one fix for them, not fifty for application teams.
• The security team owns the policy, scanner tuning, exception approvals and reporting. It helps teams fix issues but shouldn't be the fixer by default.

Set remediation targets by severity and exploitability, and report on them per team. Time to fix and the size of the existing backlog tell you more than the raw number of findings.

Frequently asked questions

Should security scans block pull requests?

Some should. Block on new critical findings that are exploitable and fixable, and on verified secrets. Everything else should warn. Blocking on every finding tends to produce overrides and workarounds rather than fixes.

Which scanner should we add first?

Secrets scanning and SCA are usually the best starting points. Both are fast, comparatively easy to tune, and address common, high-impact problems. Add IaC and container scanning next, then SAST and DAST as you build tuning capacity.

How do we handle findings in code that already exists?

Baseline them so they don't block new work, then treat them as a separate backlog with its own targets. Prioritize internet-facing services and exploitable findings first.

Does shifting left mean we can stop scanning production?

No. New vulnerabilities are disclosed in software you've already deployed, and runtime configuration changes. Pipeline scanning and production scanning cover different gaps.

Next steps

1. Inventory the security checks already in your pipelines and note where each one runs.
2. Add secrets scanning and SCA to every repository, starting in monitor-only mode.
3. Write a one-page gating policy: block on critical and exploitable, warn on the rest, gate on new findings only.
4. Put results in pull requests and move slow scans out of the pull request path.
5. Assign ownership for application, platform and policy findings before enforcing.
6. Review overrides, false positives and time to fix each quarter, and tune accordingly.