Shift-Left Security for DevOps

CI/CD pipelines names a stage called "security scan" the same way it names one called "integration test" — Testing in the Pipeline filled in the second box; this page fills in the first. It is deliberately not a tour of how a taint-tracking engine walks a control-flow graph or how a security team builds a threat model line by line — that is a full discipline with its own course on this platform, DevSecOps, and its SAST, DAST & SCA page goes there in depth. What you need here is narrower and more useful day to day: enough to wire the three scanning gates into a pipeline yourself, enough to decide what should actually block a merge versus just leave a comment, and enough to know precisely which findings are yours to close right now and which ones need a security engineer's judgment before you touch them — so a routine dependency bump doesn't sit in a queue waiting on a specialist who was never actually needed.

Shift-left security: the idea, and where it came from

☺ Like you're 10: Catch a security mistake while you're still typing it instead of finding out about it months later, after it's live and someone else already found it first.

"Shift left" is a timeline word before it's a security word — it means moving the point where a problem can be caught earlier along the pipeline you already read left to right in CI/CD pipelines. Testing in the Pipeline already applied that idea to correctness: pre-commit hooks, PR-time unit and contract tests, a thin end-to-end tip. Security is the same move applied to a different question. For a long time the industry's default was a security review bolted onto the very end — a penetration test scheduled the week before launch, a security team that showed up as a late, adversarial gate nobody could plan around. The "Rugged DevOps" push of the early 2010s, and the maturity models that followed it like OWASP SAMM and BSIMM, argued for the same shift testing had already made: run the checks continuously, starting at commit time, owned by the team shipping the code — and save a security specialist's actual expertise for the judgment calls that need it, not for rubber-stamping every merge.

The economic argument is the same shape as the one for catching a bug early in general, with one twist that makes it sharper: a correctness bug found late costs you a debugging session, but a security bug found late may already have been found by someone else first, and exploited before your own team even knew it existed. That asymmetry — the cost of "found late" includes a window where an attacker had it and you didn't — is why security shift-left gets treated as urgent rather than merely tidy, even though the mechanics below look almost identical to the testing pipeline you already know.

SAST, DAST, and SCA — the three gates, at DevOps-engineer depth

☺ Like you're 10: Read the code before it runs, attack it once it's actually running, and check the ingredients you didn't cook yourself — three different questions, three different points in the pipeline.

Three scanning categories cover three different blind spots, and the depth you need as a DevOps engineer is what each one needs to run and roughly where it earns its keep — not how its detection engine is built inside. SAST (Static Application Security Testing) reads your source code without executing it, looking for dangerous patterns — unsanitized input reaching a query, a hardcoded key, a path to eval() — which means it needs nothing but your source tree and can run on every commit or pull request. DAST (Dynamic Application Security Testing) attacks a real, running instance of your app from the outside the way an external attacker would, which means it needs a live deployed target and typically runs later, against staging, after a build has already cleared the earlier gates. SCA (Software Composition Analysis) checks the dependencies you pulled in rather than wrote — your lockfile or manifest against a vulnerability database — which needs only that manifest and runs alongside SAST, at PR time.

That's genuinely most of what you need to hold in your head about the three categories themselves. Understanding them deeply enough to write a brand-new detection rule, tune a taint-analysis engine's false-positive rate, or actually run a professional penetration test is specialist territory — the DevSecOps course's own SAST, DAST & SCA page goes there. What follows is what you actually do with these three gates as the person who owns the pipeline they run inside.

Wiring the gates into a real pipeline

☺ Like you're 10: Copy three short steps into your build file and you've quietly given every pull request two security checks and every staging deploy a third — no security degree required.

Concretely, this is a handful of steps added to a workflow file you already own. SAST and SCA are cheap enough to run in parallel with your unit tests at PR time rather than after them, so they don't add to how long a contributor waits on a green check; DAST is too slow and needs a real target, so it belongs in its own workflow, triggered once a staging deploy actually exists, not on every commit.

# .github/workflows/security.yml — the three gates, GitHub Actions flavored
name: security

on:
  pull_request:
  workflow_run:
    workflows: ["deploy-staging"]
    types: [completed]

jobs:
  sast-and-sca:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: SAST — Semgrep
        run: semgrep ci --config=auto --error         # nonzero exit fails the check
      - name: SCA — Trivy filesystem scan
        run: trivy fs --scanners vuln --exit-code 1 --severity CRITICAL,HIGH .

  dast:
    if: github.event.workflow_run.conclusion == 'success'
    runs-on: ubuntu-latest
    steps:
      - name: DAST — OWASP ZAP baseline scan
        run: |
          docker run -t zaproxy/zap-stable zap-baseline.py \
            -t https://staging.internal.example.com -r zap-report.html
        # nonzero exit on FAIL-level alerts; report is archived as a build artifact

Both jobs are ordinary GitHub Actions steps, which is the whole point — nothing here needs a security team's involvement to stand up, only to tune once it's running. Cache the scanner's rule set and vulnerability database between runs (Semgrep's registry, Trivy's CVE DB) or PR checks slow down for a reason that has nothing to do with your code, which is exactly the kind of self-inflicted friction that gets a gate quietly disabled six months later.

The same shape scans infrastructure code, not just application code — Checkov, tfsec, and Trivy's own config scanner apply the identical PR-time pattern to a Terraform plan: catch a security group open to 0.0.0.0/0 or an unencrypted storage bucket before terraform apply ever runs, not after a resource is already live. That's a shift-left gate too; it just checks HCL instead of application source. See Configuration Management & IaC for the IaC pipeline it slots into and Compliance as Code & Policy Enforcement for writing the policies behind it at real depth — and DevSecOps' IaC Security & Policy as Code if you need the specialist layer underneath that.

Gate design: what blocks a merge, and taming the noise

☺ Like you're 10: Decide in advance which alarms are loud enough to stop the whole line and which ones just get written down — because an alarm that goes off for everything teaches everyone to stop listening to it.

Once the three gates are wired in, the lever a DevOps engineer actually owns is severity threshold and blocking behavior — not the detection rules themselves. Trivy's --severity CRITICAL,HIGH --exit-code 1 and Semgrep's --error flag are exactly this knob: they decide which findings are serious enough to fail the build versus which ones merely annotate the PR and let it through. Set the threshold too loose and nothing meaningful ever blocks; set it too tight — block on every MEDIUM and LOW finding out of the box — and you get exactly the alert-fatigue failure this course already covered for flaky tests, applied to security: engineers learn to click past a red check without reading it, right before the one time it was catching something real.

A workable default most teams converge on: block the merge on CRITICAL/HIGH from SAST and SCA, since those are cheap enough to fix or triage within the PR itself; run DAST as a required check before a prod promotion rather than before every staging deploy, since it's slower and staging is exactly where you want to find its output before anyone downstream does. Everything below that threshold still shows up — as a PR comment, a dashboard entry, a ticket — it just doesn't hold up the person trying to ship.

What's yours to fix, and what to hand to security

☺ Like you're 10: Some bins you sort yourself, no questions asked. Others go straight to someone with a badge — and knowing which bin a problem belongs in is most of the actual job.

This is the question the rest of this page has been building toward, and it's the one a DevOps engineer answers dozens of times a month without ever opening a ticket for most of them. The default posture is simple: if the fix is routine and well-understood, do it and move on; if there's real ambiguity about exploitability, blast radius, or compliance exposure, escalate rather than guess. Guessing wrong in either direction is worse than a short wait — shipping a "harmless" fix that just moves the vulnerability somewhere else is at least as bad as sitting on a real one.

Where this page stops, and the DevSecOps course starts

☺ Like you're 10: You now know enough to run the three gates and sort what they find — designing the rules, the threat models, and the compliance program behind them is somebody else's whole job, and this is the door to it.

On purpose, this page never opened: how a SAST engine builds a taint trace across function boundaries, how a professional penetration test differs from an automated DAST scan, how to run a structured threat-modeling session, what a secure SDLC governance program looks like end to end, or how to build a security champions program inside engineering teams. Those are real disciplines with real depth, and the platform's DevSecOps course covers them properly — start with what DevSecOps actually changes, go deeper on the three gates themselves in SAST, DAST & SCA, and see Secure SDLC and Threat Modeling for the design-level work no scanner can do for you.

What you've got from this page instead is the piece that actually determines a number this course keeps circling back to: change failure rate, one of the DORA metrics. A gate that catches a real vulnerability before it merges is a deploy that doesn't fail in a way that pages someone at 2 a.m. — and knowing which findings to close yourself, right now, is what keeps that gate fast enough that nobody's tempted to route around it. For the provenance and SBOM side of this — proving exactly what shipped, not just scanning it before it did — see Supply-Chain Security & SBOM.