SAST and DAST: testing the code and the running application

Objective 3.1 in this course covers vulnerability scans — authenticated, unauthenticated, SAST and DAST. CompTIA names both acronyms in its own scope bullet, so both are examinable by name.

Why this matters

These two are examined as a pair because they are complements, and the exam tests whether you know which finds what. The short version: SAST reads the code without running it; DAST runs the application without reading it — and each is structurally blind to what the other sees.

The lesson

Static analysis, and the false positives it is famous for

SAST parses source (or bytecode) and traces how data flows through it, looking for untrusted input reaching somewhere dangerous — a query, a command, a file path, a rendered page.

What it is good at:

• Coverage of paths that are hard to reach at runtime. Error handlers, rarely-used branches, code behind a feature flag.
• Pointing at the exact line, which makes remediation concrete.
• Running before deployment, when fixing is cheapest.

Its famous weakness is the false-positive rate, and the reason is structural: it sees code, not context. A flow that looks dangerous may be unreachable, or the input may already be constrained upstream in a way the analyser cannot prove, or a sanitiser it does not recognise may be doing the job. So it reports the possibility and leaves the judgement.

It also cannot see anything that is not in the code it read: the configuration it is deployed with, the libraries resolved at build time, the reverse proxy in front of it.

Dynamic analysis against a running instance

DAST attacks a running application from outside. It crawls, submits input, watches responses, and reports behaviour that indicates a flaw.

Its strengths are the mirror image:

• What it reports actually happened. A reflected payload is evidence, not inference, so the false-positive rate is lower.
• It tests the deployed reality — the real configuration, the real server, the real middleware — rather than the source in isolation.
• It needs no source, so it works on third-party applications.

Its weaknesses are also mirrored. Coverage is bounded by what it can reach: pages behind authentication it cannot perform, multi-step workflows it cannot complete, anything driven by client-side rendering it does not execute properly. And it is intrusive — it submits data, so it can create records, send mail, or change state. Which is why DAST against production carries the availability and data-integrity risks from lesson 8 and belongs in the scope explicitly.

What each one structurally cannot find

The exam-useful summary, and the honest one:

SAST cannot find:

• Configuration and deployment flaws, since they are not in the code
• Anything in a component whose source it does not have
• Whether a flaw is genuinely reachable in production
• Flaws that emerge from how components interact at runtime

DAST cannot find:

• Anything behind a wall it cannot get through
• Flaws in code paths it never triggered
• Issues with no externally observable signal
• Anything in a workflow too complex for it to drive

Neither reliably finds the logic flaws from lesson 15, because both are looking for patterns and a logic flaw is the application correctly doing the wrong thing. That gap is the tester's.

This is also why "we run both and they're clean" is not a complete answer, and being able to say so precisely is worth more to a client than either scan.

Where they fit in a build pipeline

Clients increasingly run these continuously, and a tester is often asked to comment on the arrangement rather than to run them.

• SAST belongs early — on commit or pull request, where a developer sees the result while the code is fresh. Its cost is developer attention, so tuning matters: a SAST gate with a high false-positive rate gets disabled, and a disabled gate is worse than none because everyone believes it is running.
• DAST belongs later, against a deployed environment — staging, ideally configured like production.
• Dependency scanning sits alongside both and often finds more real issues than either, since most applications are mostly other people's code.

The thing worth checking, and reporting on: is anyone acting on the output? A pipeline generating thousands of unreviewed findings is a compliance artefact, not a control, and saying so plainly is usually more valuable than another finding.

Triaging a SAST report without drowning

A first SAST run on a real codebase produces an unusable number of findings. Making that tractable is the skill.

A workable order:

1. Group by rule, not by occurrence. Two hundred findings are often four rules. Judge the rule once.
2. Start where untrusted input enters. Findings whose source is a genuine external input are worth more than findings whose "source" is internal.
3. Confirm reachability. Is the code path callable by anyone who matters? This is where SAST hands over to human judgement.
4. Corroborate with DAST. A SAST finding confirmed by a dynamic test is a finding you can report with evidence, which is lesson 18's standard.
5. Record dismissals with reasons. "Not exploitable because input is constrained at the controller" is a durable decision; silently ignoring it means re-triaging the same finding next run, forever.

And the same rule as everywhere in this domain: do not report a SAST hit as a vulnerability without demonstrating it. It is a lead. Lesson 18 is about what turns a lead into a finding.

What to take into the exam

• SAST reads code without running it; DAST runs the application without reading it. Know which finds what.
• SAST: good coverage of hard-to-reach paths, exact line, high false positives, blind to configuration and deployment.
• DAST: evidence rather than inference, tests deployed reality, bounded by what it can reach, and intrusive.
• Neither finds logic flaws; that is the tester's job.
• SAST early in the pipeline, DAST against a deployed environment — and a gate nobody acts on is a compliance artefact, not a control.