Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.

What is the difference between SAST, DAST, and SCA?

Last verified

SAST reads source without running it. DAST exercises a running application. SCA inventories third-party components and their known vulnerabilities. They find different classes of defect and belong in layers, not as substitutes. This page is not legal advice.

SAST versus DAST versus SCA, last verified 10 September 2026 against OWASP WSTG, ASVS, and Source Code Review Guide, NIST SP 800-218 (SSDF), and NIST SP 800-115. Those texts are guidance or community standards, not a statute that names these three acronyms as YOUR duty. Not legal advice.

Layered testing, not one tool

Audience: an engineering leader building an application-security testing program. This page is not legal advice. Kind of text: OWASP WSTG, ASVS, and the Source Code Review Guide are community standards (industry best practice). NIST SP 800-218 (SSDF) and NIST SP 800-115 are US guidance, not a determination that they apply to YOU. A contract or framework may require “application security testing” without naming SAST, DAST, or SCA. ShipReady Metrics recommendation: run all three layers plus an independent pen test when a driver exists.

Comparison table — what it tests, when, strengths, limits

Last verified 10 September 2026. Not a product ranking. Not legal advice.

SAST vs DAST vs SCA (industry best practice; not a legal requirement; not legal advice)
LayerWhat it testsWhen in the SDLCStrengthsLimits
SAST (static application security testing)Source, bytecode, or binaries at rest — injection sinks, authz mistakes, unsafe APIs.Commit / pull request / nightly on the repo.Early, maps to a file and line, cheap to rerun.No runtime or environment view. Framework noise. Does not prove exploitability.
DAST (dynamic application security testing)A running app or API — authn/authz, session, injection via HTTP.Preview, staging, or a dedicated test environment after deploy.Sees the assembled system. Finds config and runtime issues SAST misses.Coverage depends on crawl and credentials. Blind to unused code paths.
SCA (software composition analysis)Declared and transitive dependencies — known CVEs, license families.Lockfile change, CI, and continuous ingest.Catches inherited risk you did not write. Feeds an SBOM story.CVE match is not exploitability. Reachability and blast radius still need work.

Layered-defense diagram (described)

Picture three rings around the same service. Inner ring: SAST on every change to first-party code. Middle ring: SCA on the lockfile and SBOM so transitive npm (or equivalent) is visible. Outer ring: DAST against a running preview. Outside the rings: a scoped independent pen test at the cadence your driver requires. Continuous monitoring (NIST SP 800-137 is related guidance) sits beside the rings; it does not erase the need for a point-in-time human test when a contract or program says so.

OWASP ASVS levels and WSTG techniques are how you choose depth, not a finding that YOU must reach a named ASVS level. NIST SSDF (SP 800-218) groups practices as PW (produce well-secured software) and RV (respond to vulnerabilities) — guidance, not YOUR mandate.

What to do now

Operational steps. Last verified 10 September 2026. Not legal advice.

  • Turn on SAST, DAST, and SCA as three named controls, not one “scanner” ticket.
  • Triage with KEV, EPSS, and CVSS. A raw CVE list is not a program.
  • Keep an SBOM and watch transitive blast radius. Open the SBOM blast-radius guide on this site.
  • If a pen-test driver exists, brief the tester on what SAST/DAST/SCA already covers so they spend time on chaining, not duplicate noise.

Checklist

Question list, not YOUR file. Not legal advice.

  • Is SAST running on first-party code in CI?
  • Is DAST pointed at a running, credentialed environment that resembles production?
  • Is SCA covering transitive dependencies, not only direct ones?
  • Are findings deduplicated across sources before they become tickets?

Where this shows up in ShipReady Metrics

First-party SAST and DAST exist in-product. Dependency / SCA ingest includes Dependabot-style signals, cross-source dedup, and transitive-npm blast radius. This product does not replace an independent pen test and does not determine that a framework applies to YOU.

Primary sources (last verified 10 September 2026)

OWASP Web Security Testing Guide, Application Security Verification Standard, and Source Code Review Guide are community standards. NIST SP 800-218 (SSDF) and NIST SP 800-115 are guidance. None of those texts is a determination that YOU must run a named tool. Not legal advice.

Frequently asked questions