DevSecOps: SAST, DAST, SCA, and Shifting Security Left

The pen-test-at-the-end problem

Here is how security used to work: you build for six months, then a security team runs a scan the week before launch and hands you a 200-page PDF. Half the findings are real, half are noise, and all of them are now urgent. You ship late, or you ship with known holes. Shifting security left means moving those checks earlier, onto the commit, onto the pull request, so problems surface when they are cheap to fix instead of when they are a release blocker.

The trap most teams fall into is treating 'security scanning' as one thing. It is not. There are five distinct tools here, each looking at your software through a different lens, each blind to what the others catch. Turn them all on blindly and you drown. Understand what each sees and you build a layered net with very few gaps.

Layers, like airport security

DevSecOps is not a tool you buy. It is the practice of making security a property of your pipeline instead of a gate at the end of it.

No single airport check catches everything, and nobody pretends one does. Each layer looks for a different class of threat, and the security comes from stacking them. Application security scanning works the same way.

Where each scanner runs in the pipeline

Timing is the whole game. A scanner that needs running code cannot run on a raw commit, and a scanner that only reads source cannot tell you how the deployed app behaves. Map each tool to the moment it has the information it needs.

1. 1

   Commit, secret scan

   gitleaks runs on the diff (ideally a pre-commit hook plus a CI check). Catches an AWS key or token before it ever lands in history, where rotation becomes the only fix.

2. 2

   Pull request, SAST + SCA

   On every PR, run static analysis on the changed code and a dependency scan on the lockfile. This is the cheapest place to block a problem because the author is right there with context.

3. 3

   Build, generate the SBOM

   Once dependencies resolve, emit a software bill of materials. It is the manifest you will query later when the next Log4Shell drops.

4. 4

   Image, scan the artifact

   Scan the built container for OS-package CVEs and bad config. Your code can be clean while the base image ships a vulnerable libc.

5. 5

   Deploy to staging, DAST

   With a running instance, fire dynamic probes at it: injection, auth bypass, misconfigured headers. This is the only layer that sees the app the way an attacker does.

6. 6

   Promote, gated on results

   Production only gets what cleared every prior gate at the severity threshold you set.

SAST vs DAST vs SCA vs IAST

The four big scanner families differ on one axis above all: do they read your code, or do they watch it run? That single distinction decides what they can possibly find and how noisy they tend to be.

The build-time vs runtime trade-off

Build-time scanners (SAST, SCA, secret scanning) are cheap, run in seconds to minutes, and fire on every PR, so you fix things while the code is fresh. Their weakness is that they reason about code in the abstract. SAST will flag a SQL concatenation it cannot prove is reachable; SCA will flag a CVE in a library function you never import. That gap between 'theoretically dangerous' and 'actually exploitable' is where false positives live.

Runtime scanners (DAST, IAST) have the opposite profile. Because they exercise a real instance, a finding is almost always real, there is much less to argue about. But they are slow, they need a deployed environment, and they are blind to any path your tests or crawler never hit. A DAST scan that never logs in will never test your authenticated endpoints.

• Want fast feedback and broad coverage? Lean on build-time SAST/SCA at the PR gate.
• Want high-confidence, low-noise findings? Lean on runtime DAST/IAST in staging.
• Want both without the wait? Run build-time on every PR (blocking), runtime nightly or pre-release (reporting, then blocking once tuned).

A real GitHub Actions pipeline

Here is a working workflow that wires in four layers: Semgrep for SAST, Trivy for SCA and image scanning, gitleaks for secrets, and Syft for the SBOM. It runs on every pull request. Note the GitHub Actions expression syntax and how each job is scoped to one concern.

name: security

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read
  security-events: write   # lets us upload SARIF to the Security tab

jobs:
  secrets:
    name: Secret scan (gitleaks)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0     # gitleaks needs full history to scan the diff
      - uses: gitleaks/gitleaks-action@v2
        env:
          GITLEAKS_VERSION: latest

  sast:
    name: SAST (semgrep)
    runs-on: ubuntu-latest
    container: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4
      - name: Run semgrep
        run: |
          semgrep ci \
            --config=p/default \
            --config=p/owasp-top-ten \
            --sarif --output=semgrep.sarif
        env:
          SEMGREP_RULES: p/ci
      - name: Upload findings
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: semgrep.sarif

  sca:
    name: SCA (trivy fs)
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan dependencies
        uses: aquasecurity/trivy-action@0.24.0
        with:
          scan-type: fs
          scanners: vuln
          severity: HIGH,CRITICAL     # only these fail the build
          exit-code: '1'
          ignore-unfixed: true        # skip CVEs with no patch yet

  image:
    name: Build + image scan + SBOM
    runs-on: ubuntu-latest
    needs: [sast, sca, secrets]
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t app:${{ github.sha }} .
      - name: Scan image (trivy)
        uses: aquasecurity/trivy-action@0.24.0
        with:
          image-ref: app:${{ github.sha }}
          severity: HIGH,CRITICAL
          exit-code: '1'
          ignore-unfixed: true
      - name: Generate SBOM (syft)
        uses: anchore/sbom-action@v0
        with:
          image: app:${{ github.sha }}
          format: cyclonedx-json
          output-file: sbom.cdx.json
      - name: Publish SBOM artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom.cdx.json

The image job declares needs: [sast, sca, secrets], so the build only happens after the cheap source-level checks pass, fail fast, fail cheap. Findings upload as SARIF so they show up inline on the PR and in the repo Security tab, not just buried in log output.

SBOMs: knowing what you shipped

A software bill of materials is an inventory of every component in your build, direct and transitive dependencies, versions, licenses, hashes. The syft step above emits one in CycloneDX format. It feels like bureaucracy until the next zero-day lands.

When Log4Shell hit, the teams that survived the night were the ones who could answer 'are we affected, and where?' in minutes by grepping their SBOMs, instead of spending days manually auditing every service. The SBOM is what turns 'a critical CVE was just published in libfoo' from a fire drill into a query.

# Generate an SBOM from a local image
syft app:latest -o cyclonedx-json > sbom.cdx.json

# Later: is log4j-core anywhere in what we shipped?
grep -i 'log4j-core' sbom.cdx.json

# Re-scan a stored SBOM against today's CVE feed, 
# no rebuild needed, just the manifest
grype sbom:./sbom.cdx.json --fail-on critical

Secret scanning: the cheapest, highest-ROI check

Of the five, secret scanning has the best effort-to-payoff ratio. A single leaked AWS key in git history can cost you a five-figure crypto-mining bill overnight. gitleaks and trufflehog scan diffs (and full history) for the regex and entropy signatures of credentials.

Run it in two places: a pre-commit hook so the secret never leaves the laptop, and a CI check as a backstop for anyone who skips the hook. The critical thing to understand, once a secret is committed, deleting it in a later commit does not help. It is in history forever. The only real fix is to rotate the credential. Catching it before the push is the whole point.

For the deeper playbook on managing credentials inside pipelines themselves, see secrets in CI/CD pipelines.

Common mistakes that cost hours

1. Failing the build on every severity. Block on HIGH/CRITICAL; report the rest. Day one of failing on LOW is the day developers stop reading the output.
2. Not setting `ignore-unfixed`. Failing on CVEs with no available patch gives developers a red X they literally cannot fix. That is pure alert fatigue.
3. Treating SAST as proof of safety. SAST cannot see runtime config, secrets injection, or whether a flagged path is even reachable. Clean SAST is not a clean app.
4. Skipping image scanning because the code is clean. Your base image ships an OS with its own CVEs. Scan the artifact, not just the source.
5. Running DAST without authenticating. An unauthenticated crawl never reaches your logged-in endpoints, the highest-value attack surface goes completely untested.
6. Bolting on scanners with no triage owner. A scanner with nobody assigned to its findings is theater. Route results to the PR author and define who decides what gets waived.
7. Ignoring the SBOM until a zero-day hits. Generate and store it on every build. The night Log4Shell drops is not the night to start.

Takeaways

Where to go next

You have the layered model and a working pipeline. The next step is hands-on: tune the gates against a real project, then go deeper on the two layers that scanners only partially cover, your dependencies and your container images.

• Build the pipeline yourself in the CI/CD lab: /labs/cicd.
• Go deeper on dependencies and SBOMs in securing the software supply chain.
• Tune image scanning and base-image hardening in container image security scanning.
• Lock down pipeline credentials with secrets in CI/CD pipelines.