Articles
SAST vs DAST Interview Questions: Coverage Gaps, Finding Triage, and CI Gates
Compare SAST and DAST interview questions through authenticated coverage gaps, three finding triage decisions, and an owned CI gate.
“Our static scan is green, so can we skip the authenticated application scan?” A strong SAST-versus-DAST interview answer asks what each scanner actually observed. Source analysis can follow some risky data flows before deployment, while a dynamic scan can exercise reachable behavior in a running environment. Neither proves the absence of vulnerabilities. The useful skill is mapping one risk across code, deployment, authentication, and a release decision.
This guide uses an original account-export feature and a three-finding triage exercise. Evidence boundary: OWASP, GitHub Code Scanning, and ZAP documentation support tool capabilities and defaults. The feature, scoring decisions, and CI policy below are editorial examples; no candidate report is used for process claims.
What each method can see
Static application security testing, or SAST, inspects source or compiled artifacts without running the target application as a user would. Techniques include pattern matching and data-flow or taint analysis. OWASP's static-code-analysis overview says these tools can scale across a codebase and point analysts toward risky code, but they may generate false positives, miss runtime configuration, and struggle to prove that every reported path is exploitable. A SAST result is a hypothesis with evidence, not a verified attack.
Dynamic application security testing, or DAST, sends traffic to a running application and observes responses and behavior. It can see behavior produced by the deployed stack, including some headers, redirects, configuration, and reachable input paths. Its view depends on which URLs, methods, states, and identities the scanner reaches. A public-only scan cannot establish that an authenticated administrator export is safe. A DAST alert can also be mistaken or incomplete: response behavior may suggest a vulnerability without identifying the exact code path.
The methods are complementary, but do not draw a simplistic Venn diagram where their union equals complete coverage. Some risks need manual code review, dependency analysis, architecture review, authorization tests, or business-logic tests. A dependency with a vulnerable library version is usually evaluated through software-composition analysis rather than source-flow SAST alone. An insecure tenant permission rule may require role-specific integration tests; a scanner that never uses two tenant identities cannot infer it from a single happy-path response.
Worked feature: an account export endpoint
Imagine GET /accounts/{accountId}/export?format=csv behind login. The handler reads accountId, authorizes access, queries rows, writes a CSV stream, and sets a download header. Staging has both a standard user and an administrator. A reverse proxy adds security headers in production but not in a developer's local server.
The first review question is not “Which tool is better?” It is “Which trust boundary can each tool observe?” A SAST query might follow accountId into a database query and flag string concatenation, or point to a missing authorization call if its rules understand the framework. It may miss an authorization rule implemented in a runtime policy service. A DAST scan with one ordinary account can verify the endpoint's response to that account's own export and perhaps obvious input handling. To test cross-tenant authorization, it needs at least two seeded accounts and an assertion that account A cannot export account B. A crawler that only logs in as admin may never see the denial path.
| Risk or signal | SAST evidence to seek | DAST or other evidence to seek |
|---|---|---|
| Input reaches SQL construction | Source-to-query flow and sanitizer context | Non-destructive staging response tests; query logs if available |
| Account ID bypasses tenant check | Authorization call path and policy integration | Two-identity negative authorization test |
| Missing response header | Source/proxy configuration if present | Actual staging/production response headers |
| Vulnerable CSV library version | Dependency inventory, not just SAST | Version/advisory review; DAST may not expose it |
| Unsafe export business rule | Code/requirements review | Role-specific scenario assertions |
The table is a coverage map. It does not say a particular SAST or DAST product will detect each row. Rule packs, framework support, authentication setup, staging fidelity, and scan depth decide what is observable. In an interview, say what would falsify each conclusion: a source path reaching a sink without an effective guard, or an authenticated request receiving another tenant's data.
A green scan can mean no coverage
Before trusting a green SAST job, inspect which repositories, branches, languages, generated files, and build variants were analyzed. A job that analyzed only JavaScript while the export handler is Kotlin says little about that handler. Check whether the analysis completed or skipped files after build failure. Count newly analyzed files and known test rules if available. A green status can mean “no alerts in the analyzed scope,” not “the whole system is secure.”
For DAST, inspect the target environment, authenticated session, crawl coverage, endpoint inventory, roles used, scan duration, and whether the scanner stayed logged in. ZAP's Automation Framework supports environment, authentication, spidering, and active-scan jobs. A baseline/passive scan is not equivalent to an authenticated active scan; scan mode affects what requests are generated. If the login expired after one minute, a report full of HTTP 302 responses may mostly describe the login page. Log reached routes and response classes, and seed deterministic test accounts.
Scan safety matters. Run active testing only against authorized, isolated environments, with test data and guardrails for state-changing operations. An export endpoint may be read-only, but a broad scanner can discover delete or payment endpoints. Define scope, rate, credentials, and cleanup. These are operational prerequisites for meaningful coverage, not a reason to skip dynamic testing altogether.
Triage three findings without worshiping severity labels
Suppose the pull request introduces three signals: (1) SAST reports high-severity SQL injection at the export query; (2) DAST reports a missing security header in staging; (3) a role-specific test shows user A can download user B's export. Begin with the third: it is a demonstrated cross-tenant authorization failure in the assumed exercise, with direct confidentiality impact. Block release, reproduce with stable test identities, locate the ownership check, fix it, and add a negative regression test. This is a decision from the exercise's evidence, not a universal rule that “DAST beats SAST.”
For the SQL-injection alert, trace source to sink and inspect whether the actual query is parameterized. If the concatenation occurs only in a safe identifier mapping, document that specific reason and a test; if untrusted text reaches executable SQL, fix it and block. A generic “false positive” disposition with no code path or owner is weak. OWASP explicitly discusses static-analysis false positives and false negatives; triage needs a concrete proof, not a tool popularity contest.
For the missing header, compare staging with the intended production proxy and the threat model. If the production-only proxy reliably adds the header, a staging DAST result may be an environment-fidelity issue; verify production-equivalent configuration in a safe read-only check and fix staging parity or document a scoped exception. If the header is absent in production, treat it as a real finding with severity based on the actual policy and exposure. Do not waive it merely because “the proxy team owns it.” Ownership changes who fixes it, not whether users are protected.
Notice how findings can correlate. A SAST query and a DAST error may point to the same root cause; do not count them as two separate risks for prioritization. Conversely, one green tool does not cancel a finding from another. Record a finding ID, affected endpoint and version, evidence, environment, owner, severity rationale, remediation, retest, and expiration if an exception is granted. That makes the release decision auditable.
Design a CI gate that helps instead of freezing delivery
A useful gate distinguishes new high-confidence findings from legacy backlog, and scanner failures from clean results. For the exercise, block a pull request when a verified cross-tenant test fails, a new high/critical SAST alert has no approved disposition, or the scan did not complete for the affected service. Run a bounded authenticated DAST suite against staging before release, with a stricter block for reproduced high-impact findings. Schedule broader scans outside the fastest PR loop and feed their results into tracked remediation. This is an editorial policy proposal, not a GitHub or OWASP default.
GitHub's code-scanning documentation says code-scanning alerts can appear as PR checks, and branch protection can make the check required. Its documented default failure levels for the code-scanning results check include error, critical, and high, with configurable thresholds. Do not overgeneralize that behavior to all SAST vendors or to DAST. A team's gate must define what “new,” “high,” and “scan complete” mean for its own tools and branch policy.
An exception record should contain the exact finding fingerprint or endpoint, reason, evidence, compensating control, owner, approval, expiration date, and retest trigger. Avoid a permanent global suppression of an entire rule family because one instance is noisy. When a finding is later reintroduced in a different path, the old exception must not hide it. Expired exceptions should fail or re-enter triage rather than silently remain accepted.
The gate also needs a failure mode. If the DAST staging environment is down, a green release button would be misleading; decide whether to hold, use a limited emergency path with explicit owner, or rely on a recent equivalent run. Document the trade-off. An unreliable gate that fails for irrelevant noise every day encourages bypasses; tune rules and scan scope without deleting the evidence you need.
How do you measure coverage and improvement?
Report scanner execution separately from vulnerability counts. SAST metrics can include analyzed code and languages, rule-pack version, completion rate, new alerts, confirmed findings, and time to disposition. DAST metrics can include authenticated routes reached, roles tested, response status distribution, scan mode, elapsed time, and confirmed findings. A drop from ten alerts to zero is not progress if the scanner stopped authenticating or the build excluded the service.
For the account-export feature, define an explicit coverage objective: both user and admin flows are reachable; a second tenant's export returns denial; CSV content and headers are checked; the handler's database construction is analyzed; dependency versions are inventoried; the production-equivalent proxy behavior is observed. This small feature-level map is more defensible than claiming “80% security coverage” from a single aggregate. It also tells reviewers which evidence is missing.
Retest the fix at the same boundary that showed failure. A SQL query change gets a unit/integration regression plus renewed SAST analysis. A missing production header gets a response assertion against a production-equivalent path. A cross-tenant failure gets a two-identity negative test. A scanner alert that disappears after a code change is encouraging, but if the path is no longer scanned, disappearance is not proof of remediation.
Interview follow-ups worth rehearsing
Can SAST find authentication bugs? Some rules can identify suspicious missing checks or flows, but OWASP notes that access-control issues can be difficult to find automatically. Review policy semantics and write role-specific tests.
Can DAST prove there is no SQL injection? No. A scan can test reachable cases in its environment and report evidence. Unreached endpoints, missing roles, payload coverage, and WAF behavior limit the conclusion.
Where does dependency scanning fit? It checks known component versions and advisories, a separate evidence stream. Neither source-flow SAST nor black-box DAST reliably replaces a software bill of materials and dependency review.
What should block a merge? Define a policy by newness, severity, confidence, affected scope, and scanner completeness. A reproduced authorization failure blocks in the exercise. A disputed static alert needs owned, evidenced triage rather than automatic dismissal.
How do you handle a false positive? Show the source path or runtime behavior that makes it non-exploitable, record the exact fingerprint and conditions, limit the exception, and retest when code or configuration changes.