SAST, DAST & SCA

No single scanner sees the whole application. Static analysis reads your code without running it, dynamic analysis attacks your app while it's running, and composition analysis checks the code you didn't write yourself. This page defines each category precisely, places each one at the pipeline stage where it actually earns its keep, and covers the triage problem that determines whether any of them survive contact with a real team.

SAST: reading the code without running it

Static Application Security Testing analyzes source code, bytecode, or binaries without executing them. A SAST engine builds an abstract syntax tree or control-flow graph from your code and pattern-matches against known-dangerous constructs: string concatenation flowing into a SQL query, unsanitized input reaching an eval() call, a hardcoded cryptographic key, a path that lets user input reach a shell command. Tools like Semgrep, CodeQL, SonarQube, and Checkmarx all work this way, differing mainly in how deep their data-flow analysis goes and how much of a real interprocedural taint trace they can follow versus a shallow single-file pattern match.

The defining advantage is timing. Because SAST needs nothing more than the source tree, it can run in an editor as you type, as a pre-commit hook, or as a required check on every pull request in CI/CD — the same shift-left principle covered on what DevSecOps actually changes. A vulnerability caught at PR time costs a few minutes of the author's attention; the same class of bug caught in production after an incident costs an on-call rotation and a postmortem. IBM's Systems Sciences Institute research on defect cost, cited across the industry for two decades, put the ratio at roughly 6x more expensive to fix a defect found in testing than in design, and orders of magnitude more once it's in production — SAST is the tool built specifically to exploit that curve by catching the bug before it's ever committed.

The tradeoff is exactly what you'd expect from analyzing code in isolation: SAST cannot see how your application behaves once it's deployed behind a real reverse proxy, talking to a real database with real permissions, under a real authentication flow. It also cannot reason about business logic — a SAST tool will not flag "this endpoint lets a normal user cancel someone else's order" because nothing about that pattern looks syntactically wrong. That gap is exactly what dynamic testing is for.

DAST: attacking a running instance from the outside

Dynamic Application Security Testing takes the opposite approach: it treats the application as a black box and attacks it the way an external adversary would, with no access to source code. A DAST scanner — OWASP ZAP and Burp Suite's automated scanner are the two you'll see most — crawls the running application's routes, then throws malformed and malicious input at every form field, header, and parameter it finds: SQL injection payloads, XSS strings, path traversal sequences, malformed authentication tokens. It watches the actual HTTP responses, status codes, and rendered output for evidence the attack worked.

Because it needs a live, deployed target, DAST typically runs later in the pipeline than SAST — against a staging or pre-production environment after a build has already passed unit tests and SAST gates, not on every commit. This is also where DAST earns its keep: it catches an entire category of runtime and configuration issues that are invisible to source-code analysis, because they don't exist in the source code at all. Missing security headers (no Content-Security-Policy, no X-Frame-Options), a misconfigured TLS setup, a session cookie missing the Secure or HttpOnly flag, an authentication bypass that only shows up when two middleware layers interact at runtime — none of these are visible by reading any single file, but all of them are visible the moment you actually attack the running system.

The cost of that realism is speed and precision. A DAST scan against a nontrivial application can take anywhere from twenty minutes to several hours, versus SAST's seconds-to-minutes on a diff, and a DAST finding tells you a symptom ("this endpoint returned a 500 with a stack trace for this payload") rather than a source location — someone still has to trace the response back to the vulnerable line of code.

SCA: the code you didn't write is still your code

Software Composition Analysis scans your project's third-party and open-source dependencies — everything pulled in via package.json, requirements.txt, go.mod, a container base image, and similar manifests — against databases of known vulnerabilities, principally the CVE database and the broader National Vulnerability Database, cross-referenced through machine-readable feeds like OSV. Tools in this category include Snyk, Dependabot, OWASP Dependency-Check, and Trivy (which extends into container and IaC scanning covered on container and supply chain security).

SCA earns a category of its own, distinct from SAST, because of a simple fact about how modern software is actually built: a typical production codebase is majority third-party code. Industry composition studies (Synopsys's annual OSSRA report is the most-cited) have consistently found that 70-90%+ of the code in a typical commercial application by line count comes from open-source dependencies, not code the team wrote. A SAST scanner analyzing your own source files is, by construction, only looking at a minority of what actually ships. SCA closes that gap by asking a narrower but different question than "is this code written well" — it asks "is this exact version of this exact library on a known-vulnerable list," and increasingly also builds and checks a Software Bill of Materials (SBOM) so the org can answer "are we affected by CVE-2024-XXXXX" in minutes rather than days when the next Log4Shell-scale disclosure lands.

SCA's practical failure mode is different from SAST's or DAST's: a CVE match doesn't tell you whether the vulnerable code path in that dependency is actually reachable from your application, so a naive SCA setup can report "critical" on a library whose vulnerable function you never call. More mature tools attempt reachability analysis to filter for exactly this, but plenty of SCA output in the wild is still severity-ranked by the dependency's CVSS score alone, with no attempt to correlate that against your own call graph.

# .ci/pipeline.yml — three scan categories at three different stages
stages:
  - build
  - test
  - scan
  - deploy-staging
  - dast
  - deploy-prod

sast-scan:
  stage: scan
  # runs on every commit/PR — needs only the source tree, no running app
  script:
    - semgrep ci --config=auto --error
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

dependency-scan:
  stage: scan
  # runs alongside SAST — needs only the manifest/lockfile, no running app
  script:
    - trivy fs --scanners vuln --exit-code 1 --severity CRITICAL,HIGH .
  artifacts:
    reports:
      dependency_scanning: sbom.json

dast-scan:
  stage: dast
  # runs after deploy-staging — needs a live, reachable target
  needs: ["deploy-staging"]
  script:
    - zap-baseline.py -t https://staging.internal.example.com -r zap-report.html
  artifacts:
    paths: [zap-report.html]

Putting the three together in one pipeline

The three categories are complementary, not redundant, precisely because each one's blind spot is a different one's strength. SAST is fast and early but code-only and blind to runtime behavior. DAST is realistic and catches configuration and runtime issues but is slow and gives you a symptom, not a source line. SCA covers the majority-share of your codebase that SAST never touches — the dependencies — but needs reachability analysis to avoid drowning teams in irrelevant CVEs. A mature pipeline runs SAST and SCA together at PR time, gated as required checks before merge, and runs DAST later against a deployed staging environment, gated before promotion to production — matching each tool's cost and realism to how early or late it can practically run, which is also why the ordering in the YAML above puts sast-scan and dependency-scan in the same early stage and dast-scan after a staging deploy exists to attack. None of the three replaces threat modeling — they find implementation and dependency flaws in things you built or pulled in, not design-level gaps in what you decided to build in the first place.