What does shift-left security mean?
Shift-left security means running security activities earlier in the development timeline, which is drawn left to right from design to production. A flaw found in a pull request costs the author a few minutes. The same flaw found by a pentest or an attacker costs a release, an incident and sometimes a disclosure.
The phrase comes from testing, not security. Larry Smith used "shift-left testing" in a September 2001 article in Dr. Dobb's Journal, arguing that QA should work alongside developers from the specification stage and that tests should be written and automated earlier. The security community borrowed the idea as DevOps spread: if developers ship many times a day, a security review at the end of a quarterly release cycle no longer exists to catch anything.
What actually moves left?
Five kinds of checks move earliest, because they can run on code or design documents without a deployed application.
- Threat modeling at design time. Before code exists, the team lists what the feature trusts, who can reach it, and what goes wrong if a check is missing. This catches the class of bug that no scanner finds later, such as a business logic vulnerability baked into the spec.
- Static analysis in the pull request. SAST tools read the diff and flag tainted input reaching a dangerous call, such as a request parameter concatenated into SQL.
- Dependency checks (SCA). Software composition analysis compares the lockfile against advisory databases and flags a newly added package with a known CVE.
- Secrets scanning. A pre-commit hook or push-time check stops an API key before it lands in history. See secrets detection.
- Infrastructure-as-code scanning. Terraform, Kubernetes manifests and Helm charts are checked for public storage buckets, open security groups and privileged containers before anything is provisioned.
The OWASP DevSecOps Guideline lists the same set for a pipeline: secrets scanning, SAST, SCA, IaC scanning, then DAST and infrastructure checks later in the flow. NIST's Secure Software Development Framework frames it as practices, notably PW.7 (review and analyze human-readable code) and PW.8 (test executable code), without prescribing tools.
What does a shift-left check look like in a pull request?
A typical setup runs fast checks on every pull request and blocks the merge only on high-confidence findings. Here is a GitHub Actions example with open-source tools named as examples of each category:
# .github/workflows/pr-security.yml
name: PR security checks
on: pull_request
permissions:
contents: read
jobs:
checks:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
# Tools are assumed to be installed in the runner image
# Secrets: scan only the commits in this PR
- run: gitleaks git --log-opts="origin/${{ github.base_ref }}..HEAD"
# SAST: report only findings introduced since the base branch
- run: semgrep scan --config p/default --baseline-commit origin/${{ github.base_ref }} --error
# SCA: fail on known-vulnerable dependencies in the lockfile
- run: osv-scanner --lockfile=package-lock.json
# IaC: check Terraform in the infra/ folder
- run: checkov -d infra/ --compactTwo details make this usable. First, scan the diff: a developer who adds ten lines should see findings about those ten lines, not 400 pre-existing ones. Second, the workflow runs on pull_request with read-only permissions, so a malicious contribution cannot use the security job itself as a foothold (see CI/CD pipeline security).
The developer then sees a comment on the changed line, such as "user input from req.query.sort flows into db.query()", and fixes it before review.
What are the common critiques of shift-left?
The main critique is that shift-left often shifts the work onto developers without shifting the expertise. Three problems come up repeatedly.
- Alert fatigue. A scanner that posts dozens of low-confidence findings on every pull request teaches developers to click past it. Once that habit forms, the one real finding gets ignored too. Tuning rules, blocking only on high-severity, high-confidence results, and suppressing pre-existing findings matter more than adding another tool.
- Early checks cannot see runtime. Authorization bugs, broken multi-tenant isolation, misconfigured cloud identity and chained attacks only exist in a running system. A green pull request says nothing about them.
- Ownership gets blurry. "Developers own security now" can quietly become "nobody triages the backlog." Someone still has to decide which findings are real and which rules to keep.
These critiques are why the OWASP DevSecOps Guideline promotes a shift-left culture that is increasingly "shift-everywhere": keep the cheap checks early, and keep testing the deployed application with DAST, secure code review of risky changes, and penetration testing. The blog post on continuous penetration testing vs annual pentests covers the right-hand end of that timeline.
Shift-left vs shift-right
Shift-right means testing and observing in production: runtime protection, monitoring, canary releases, bug bounties and pentests against live systems. The two are complements. Shift-left is cheaper per finding and catches known patterns; shift-right finds what only appears with real data, real configuration and real users.
[ Sources ]
Written by Parameter · Last reviewed
