Cybersecurity glossary

What is Static Application Security Testing (SAST)?

Learn what SAST is, how static code analysis finds application security flaws, where it fits in DevSecOps, and how it differs from DAST and IAST.

DevSecOps and supply chainUpdated August 11, 2026
Also known asStatic code security analysisSource code security scanningStatic security testing

Definition

Static Application Security Testing (SAST) is security analysis of source code, bytecode, or binaries without running the application, usually to identify insecure patterns and dataflow risks early in development.

Why SAST matters

Many security bugs are introduced as ordinary code: unsafe string concatenation, missing authorization checks, weak cryptography, hardcoded credentials, dangerous deserialization, or untrusted input flowing into a sensitive sink. Developers can fix these issues fastest when the code is still under review.

Static Application Security Testing (SAST) gives teams early code-aware feedback. It is especially useful for patterns and data flows that can be detected before the application is deployed, tested manually, or exposed to users.

What SAST can inspect

Source patterns

Rules identify dangerous APIs, unsafe framework usage, weak crypto choices, and banned functions.

Data flows

Taint analysis traces untrusted input toward sinks such as SQL queries, commands, files, templates, or redirects.

Changed code

Pull-request scans focus reviewer attention on newly introduced risk while context is fresh.

Policy rules

Organizations can encode secure coding standards and framework-specific guardrails.

How SAST fits into delivery

1

Select rules by stack

Enable language, framework, and risk-specific rules that match the application instead of scanning with every rule available.

2

Run early scans

Scan in IDEs, pull requests, and CI so developers receive findings near the change that introduced them.

3

Review evidence

Use traces, sources, sinks, code snippets, and rule explanations to separate real issues from noise.

4

Fix with context

Prefer secure patterns, framework controls, validation, parameterization, encoding, and authorization checks.

5

Gate selectively

Block high-confidence new findings while routing low-confidence or inherited findings through triage.

6

Pair with runtime tests

Use DAST, IAST, manual testing, and monitoring for behavior SAST cannot prove statically.

SAST, DAST, and IAST compared

MethodAnalyzesStrongest when
SASTSource code, bytecode, binaries, patterns, and possible data flows without running the appDevelopers need early code-level feedback in review or CI
DASTA running web app or API from the outside using requests and responsesTeams need evidence of deployed behavior, configuration, and exploitable runtime responses
IASTA running app with instrumentation during tests or DAST trafficTeams want runtime proof with internal code-path context
Manual reviewDesign intent, business logic, authorization meaning, and chained abuseRisk depends on context that automated tools do not understand

SAST implementation checklist

  • Enable language and framework rules that match the repositories being scanned.
  • Start with changed-code findings so developers are not overwhelmed by inherited backlog.
  • Tune or suppress noisy rules with clear rationale and periodic review.
  • Require evidence such as dataflow traces, vulnerable sinks, and realistic exploit paths for severe findings.
  • Provide secure code examples and preferred libraries in remediation guidance.
  • Separate security bugs from style lint so teams understand why a finding matters.
  • Track remediation time, false-positive rate, and repeat issue types to improve the rule set.
  • Pair SAST with SCA, DAST, IAST, and manual review for broader coverage.

The practical takeaway

SAST is strongest when it gives developers specific, timely code feedback before risky patterns ship. It belongs early in the SSDLC, especially in pull-request and CI workflows.

Do not ask SAST to prove everything. Use it for static code and dataflow insight, then use DAST, IAST, and human review to validate runtime behavior and business context.

Related security terms

Frequently asked questions

What is SAST in simple terms?

SAST scans code without running the application and looks for security weaknesses such as unsafe input handling, injection paths, hardcoded secrets, or insecure APIs.

How is SAST different from DAST?

SAST analyzes code before execution. DAST probes a running application from the outside, so it can see deployed behavior but usually has less code-level detail.

How is SAST different from IAST?

SAST is static and does not require test traffic. IAST instruments a running app during tests, giving runtime proof for code paths that execute.

When should SAST run?

Run fast SAST checks in pull requests and CI, with deeper scans scheduled or triggered for high-risk services, major releases, or codebase-wide policy review.

Does SAST find all vulnerabilities?

No. It can miss runtime configuration, authorization logic, environment-specific issues, and flaws that require business context or deployed behavior.

Why do SAST tools create false positives?

Static tools reason from code patterns and possible data flows. Without runtime context, they may flag paths that are unreachable, sanitized elsewhere, or not exploitable.

How can teams make SAST useful for developers?

Tune rules, show changed-code findings first, include precise dataflow evidence, provide fix examples, and avoid blocking on low-confidence legacy backlog.

References

Explore authoritative guidance and frameworks related to static application security testing (sast).

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary