The setup most teams run
A typical mid-size engineering organization has both a SAST tool in the CI pipeline and a DAST scanner pointed at a staging environment. They report to the same security dashboard. They both generate findings. And in practice, engineers engage seriously with one of them and mostly ignore the other.
Usually the ignored one is DAST. This article isn't an argument against dynamic analysis — it's an attempt to explain why the split happens and what to do about it. Understanding the structural differences between static and dynamic analysis determines how you compose them, not which one to eliminate.
What SAST actually does
Static application security testing operates on source code, bytecode, or compiled binaries without executing the program. The analysis constructs an abstract syntax tree (AST) from the code, then applies pattern matching, dataflow analysis, and taint tracking against that representation.
Taint analysis is where SAST earns its keep for injection-class vulnerabilities. A taint source is any value entering the program from an untrusted boundary — an HTTP request parameter, a database query result that gets re-serialized, an environment variable read at startup. A taint sink is any function where that value would cause harm if unsanitized: cursor.execute() for SQL injection (CWE-89), innerHTML assignment or document.write() for cross-site scripting (CWE-79), os.path.join() combined with user input for path traversal (CWE-22).
The engine traces dataflow paths between sources and sinks across function call boundaries. If a value can flow from source to sink without passing through a recognized sanitizer or validator, the scanner flags it. This is why SAST finds SQLi in code that hasn't run yet — the finding is a property of the code structure, not of runtime behavior.
The limitation is the flip side of that strength: SAST cannot observe runtime context. It doesn't know which code paths are actually reachable, what values environment variables take in production, or how an authentication middleware that sits outside the scanned repository interacts with the endpoints it's protecting. This produces false positives — findings that are structurally correct but contextually irrelevant — and false negatives when the vulnerable logic spans runtime configuration that the scanner never sees.
What DAST actually does
Dynamic application security testing sends actual HTTP requests to a running application and observes the responses. A DAST scanner exercises the application the same way an attacker would: probe for reflected XSS by injecting payloads into query parameters, test for SSRF (CWE-918) by attempting to make the application fetch internal endpoints, check for authentication bypass by replaying requests with modified session tokens.
The key advantage is that DAST sees the system as it actually behaves. It discovers issues that only manifest at runtime: misconfigured CORS policies, session fixation vulnerabilities in auth flows, insecure direct object reference (IDOR) patterns where authorization checks live in the application logic rather than the data layer. These are real vulnerabilities that SAST cannot find because they require observing running behavior, not reading source.
DAST's limitation is integration latency. To run DAST meaningfully, you need a deployed environment — typically staging — with representative data and service connectivity. That's rarely available during the development loop where most code changes happen. The result is that DAST findings arrive after the fact: after a feature is merged, after it's deployed, often after it's been running for days. The cost to fix a finding at that point is 4-6x higher than at code review time, by consistently reported estimates from NIST's research on defect cost amplification.
Where each one fits in the development lifecycle
This is the structural answer. SAST belongs in the pull request. It has no runtime dependency, it runs in seconds to minutes on changed files, and it produces findings that directly reference lines of code the author is still actively working on. The feedback loop is tight. A CWE-89 finding on line 47 of user_service.py is actionable today, before the branch merges.
DAST belongs in a scheduled scan against staging or pre-production, or as a targeted probe during QA cycles before major releases. It doesn't belong in a PR check gate — not because the findings are less valuable, but because the prerequisites (running app, populated database, service dependencies) aren't available in the PR context. Blocking a merge on a DAST scan that takes 45 minutes and requires a separate deploy step is a workflow antipattern that erodes team trust in the security program.
Consider a realistic scenario: a growing payments platform running a Python/FastAPI backend. They added SAST to the PR pipeline and set DAST to run nightly against a staging environment. The SAST scanner catches a taint analysis finding in a new search endpoint — user-supplied input flowing unsanitized into an ORM raw query call, a CWE-89 risk — while the PR is still open. The fix takes 20 minutes. The same endpoint also has a broken authentication check that only manifests when a specific session state exists at runtime; DAST catches it in the nightly scan, two days after merge. Both findings matter. Neither tool would have caught the other's finding.
The recall/precision tradeoff you're actually managing
Security teams often frame tool selection as a precision question: "which tool has fewer false positives?" This is the wrong frame. The relevant dimensions are recall and precision relative to where in the lifecycle you need the finding.
SAST precision varies significantly by rule category and language. Taint-tracking rules for CWE-89 (SQL injection) in strongly-typed languages like Java or Go tend to have high precision because type information constrains the dataflow paths the engine must consider. The same rules applied to Python or JavaScript codebases see more false positives because dynamic typing means the engine must be conservative about what paths are possible — and conservative means flagging more than it should.
DAST precision, conversely, is very high for the specific paths it exercises — a confirmed DAST finding is almost always a real vulnerability — but recall is limited by crawler coverage. If the DAST scanner never discovers a protected admin endpoint because it requires a specific authentication flow, that endpoint is invisible to it regardless of what vulnerabilities it contains.
The operational implication: tune SAST aggressively for the language and framework you're using. A rule that fires on every ORM call regardless of whether the input is tainted is not a security control; it's alert fatigue. The false positive rate for SAST in practice should be below 15-20% to remain actionable — above that threshold, engineers start treating every finding as noise and the tool loses effectiveness.
What this means for teams that "only have bandwidth for one"
We're not saying DAST is optional for mature security programs. At sufficient scale and risk tolerance — regulated industries, external-facing products handling sensitive data — you need both, running at different cadences.
But for a growing engineering team that hasn't yet built security into the review workflow at all, SAST integrated into the PR process delivers earlier and more actionable coverage than a DAST scanner running against staging once a week. The reason isn't that SAST is technically superior; it's that the feedback loop is tight enough to actually change developer behavior. A finding that appears in the same interface where code review happens — as an inline comment on the diff — gets addressed. A finding that appears in a separate security dashboard, attributed to a commit from three weeks ago, often doesn't.
The goal of an effective AppSec program is to make security findings arrive where the code still exists as a local concern. SAST, integrated properly into code review, does that by design. DAST becomes the complement — the runtime verification layer that catches what static analysis structurally cannot. Neither is sufficient alone. The sequencing question is about where to start.
SARIF and toolchain integration
One practical note worth covering: both SAST and DAST tools increasingly emit findings in SARIF (Static Analysis Results Interchange Format), the JSON-based schema defined by OASIS that GitHub's code scanning API accepts natively. When both tools export SARIF, findings from both can appear in a unified view — either in the GitHub Security tab or in a SIEM that accepts SARIF input.
This matters for triage workflow. If SAST findings in a PR and DAST findings from a nightly scan both surface in the same interface, the mental model for the team is simpler: security findings live in one place, and the source (static vs. dynamic) is a metadata tag, not a separate product to check. The GitHub Checks API allows SAST tools to post findings directly to the PR diff view, creating the inline comment experience that keeps static findings in the review context where they're most actionable.
The baseline scan concept is also relevant when integrating both tools. Most SAST tools support a suppression file or baseline that tracks known-accepted findings, preventing them from surfacing again in future scans. Without this, every scan re-flags the same findings and the signal-to-noise ratio degrades. DAST tools have an analogous concept in their scope and exclusion configuration. Maintaining both baselines is ongoing operational work — not a one-time setup.
