Shift-Left Security (DevSecOps)
debt(d7/e7/b7/t7)
Closest to 'only careful code review or runtime testing' (d7), because the *absence* of shift-left security — i.e., security only tested at staging or production — is invisible in day-to-day development. The detection_hints note the code pattern is 'No SAST tool in CI pipeline; security only tested in staging or production.' Tools like semgrep, phpstan, psalm, and snyk can catch issues once added, but the organisational/process gap itself is not flagged by any automated tool — it requires deliberate audit or review to notice. Slightly better than d9 because a CI pipeline review or a failed deployment gate can surface it before production.
Closest to 'cross-cutting refactor across the codebase' (e7), because the quick_fix suggests adding SAST tools to CI as a starting point, but the common_mistakes reveal the full remediation spans tooling (IDE plugins, CI gates, dependency scanners), developer training, and cultural change — all cross-cutting concerns. It is not architectural rework (e9), but it is well beyond a single-component fix, touching every team workflow, build pipeline, and development practice.
Closest to 'strong gravitational pull' (e7 → b7), because shift-left security applies across all contexts (web, api, cli) and affects every development phase — design, coding, CI, review, and release. The common_mistakes and misconception confirm that without it, every downstream decision about what gets shipped is shaped (or mis-shaped) by the absence of embedded security practices. It doesn't quite reach b9 (rewrite-or-live-with-it) but every change stream is influenced by whether or not this practice is in place.
Closest to 'serious trap (contradicts how a similar concept works elsewhere)' (t7), because the misconception is explicit: developers naturally interpret 'shift-left security' as 'run a pentest earlier,' which is a point-in-time activity, not the embedded, continuous, multi-phase practice the term actually means. This contradiction between the intuitive interpretation (move one activity left) and the correct interpretation (change the entire culture and process) is a well-documented gotcha that most teams fall into, making it a serious cognitive trap.
Also Known As
TL;DR
Explanation
Shift-left security moves security from a release-time gate (pen test, audit) to an integral part of every development phase: threat modelling during design, SAST in the IDE and CI pipeline, dependency scanning on every commit, security-focused code review, and developer security training. DevSecOps embeds security tooling directly in the CI/CD pipeline so vulnerabilities are caught within minutes of introduction rather than weeks later. The cost of fixing a vulnerability found at design time is orders of magnitude lower than one found in production.
Common Misconception
Why It Matters
Common Mistakes
- Security review only at release — vulnerabilities are found when they are most expensive to fix.
- Developers with no security training — they cannot identify issues even with the right tools.
- Static analysis tools not in developer IDE — feedback only comes in CI, not during writing.
- Treating shift-left as 'run a scanner' without changing the development culture.
Code Examples
# Traditional (shifted right) security pipeline:
# Code → Build → Test → Stage → Pentest → Fix → Release
# Pentest finds SQLi → 3 weeks to fix → missed release window
# Shift-left pipeline:
# Code (IDE lint) → PR (SAST scan) → Build → Test (DAST) → Release
# SQLi caught by SAST in PR → fixed in 10 minutes# Shift left = find vulnerabilities earlier (much cheaper to fix)
# Level 1 — Developer (IDE / pre-commit hook)
$ vendor/bin/phpstan analyse --level=6
$ vendor/bin/psalm --taint-analysis # tracks XSS, SQLi data flows
# Level 2 — CI (every PR)
$ composer audit # known CVEs in dependencies
$ semgrep --config=p/php-security src/ # SAST patterns
# Level 3 — Staging (pre-deploy)
$ docker run owasp/zap2docker-stable zap-baseline.py -t https://staging.yourapp.com
# Level 4 — Production
# Bug bounty, annual penetration test, anomaly monitoring
# Rule of thumb:
# Dev fix: minutes | QA fix: hours | Prod fix: days + incident response