SAST/DAST Interview Questions

SAST analyzes source code or bytecode without running the application — a white-box technique usable as soon as code exists, able to point to an exact file and line — while DAST tests an actually running application from the outside by sending real requests, the way an attacker would, without needing any source code access. Because they observe the system from opposite vantage points, they catch different classes of flaw, which is why mature pipelines run both rather than substituting one for the other.

SAST analyzes source code, bytecode, or binaries without executing the application to find security vulnerabilities early in development. In CI/CD it typically runs on every commit or pull request so issues surface before code is merged.

False. DAST tests a running application from the outside, the same way an attacker would — sending real HTTP requests and analyzing the responses — so it needs a reachable, deployed instance but no visibility into the source code at all. SAST is the opposite: it analyzes source or bytecode directly and never needs the app to be running.

True. Semgrep rules are written in a pattern syntax that closely resembles the target language's own code, with metavariables standing in for the parts that vary, so an engineer can write and tune custom rules without learning a separate query language. CodeQL instead requires learning QL, a purpose-built declarative query language, which is more powerful for deep cross-file analysis but a steeper barrier to a team's first custom rule.

Shifting security testing earlier in the SDLC (e.g., running SAST on every pull request in CI) so vulnerabilities are found at the developer's desk — close to when the code is written — rather than waiting for a late-stage or post-deployment scan. The goal is faster, cheaper feedback: fixing a flaw minutes after writing it costs far less than catching it in production.

In DAST, Passive scanning analyzes HTTP requests and responses as they occur naturally between the client and the application, without injecting any test payloads or probes into the target. Because it never sends modified traffic, it is safe to run against production systems.

In DAST, Active scanning sends crafted attack payloads to the target application to probe for vulnerabilities such as SQL injection and cross-site scripting, whereas Passive scanning only inspects existing traffic without sending any additional or modified requests.

A DAST scanner operates against a live, running instance of an application and treats it as a black box, meaning it has no access to the source code, internal structure, or design documents of the target.

CodeQL's core analysis approach compiles the codebase into a queryable relational database representing its structure and data flow, then runs semantic QL queries against that database to trace whether untrusted input can reach a dangerous operation across function and file boundaries. That database-and-query model gives it real semantic understanding rather than superficial text matching, at the cost of needing a build step first, which makes it slower to run than a lightweight pattern-matching scanner.

OWASP ZAP's passive scanning only analyzes traffic it has already observed through its proxy or spider — flagging things like a missing security header — without sending any additional requests, while active scanning deliberately sends crafted attack payloads such as SQL injection or XSS strings at discovered endpoints and can modify server-side data. That intrusiveness is exactly why active scanning should never be pointed at a production environment without explicit authorization.

Gating a CI pipeline only on critical/high-severity SAST findings, rather than failing on any finding, is a legitimate choice because blocking on every low-severity finding trains developers to bypass or ignore the gate once it stops feeling actionable, and because blocking merges only on high-confidence, exploitable findings preserves developer trust in the tool, which is what sustains its long-term adoption. Lower-severity findings still reach a backlog for scheduled triage rather than being lost. SAST tools do not produce zero false positives, and no universal compliance mandate requires a hard build failure on every finding regardless of severity.

SAST's genuine strengths relative to DAST are pointing to the exact file and line responsible for a flagged issue, running on a pull request before the application is ever deployed or fully built, and being able to flag a vulnerable code path even in functionality not reachable through the app's exposed UI or API — since it examines all the code, not just what's externally discoverable. Directly observing a runtime issue like a missing security header is a DAST strength instead, since SAST has no running server to inspect, and SAST is not reliably lower in false positives than DAST — both generate them, and the ratio depends on tuning.

Shift-left means moving security testing — SAST, dependency/secrets scanning — as early as possible in the development lifecycle: into the IDE or the pull request, rather than waiting for a DAST scan or pentest against a fully deployed system late in the release cycle. The payoff is that a flaw found on a PR is far cheaper to fix than one found in staging or production, both in engineering time and in how fresh the author's mental model of the code still is. The tradeoff is coverage and confidence: static tools running against incomplete, freshly-written, not-yet-integrated code lack full runtime context, so they tend to surface more false positives and lower-confidence findings than a DAST scan or pentest run against the assembled, running system — which means shifting left only pays off if the team also invests in triage capacity, or the noise trains developers to ignore the gate.

IAST instruments the running application itself — typically via an agent inside the app server or language runtime — and observes real code execution as the app is exercised, whether by QA's functional tests, a DAST scanner driving traffic, or a human clicking through it. That gives it SAST's visibility into the exact vulnerable code path, combined with DAST's advantage of watching an actually running system with real data flowing through it, which tends to produce fewer false positives than SAST alone since a finding is only raised when the flagged code path is confirmed to have actually executed.

A pull-request SAST pipeline runs in a fixed order: a commit triggers the pipeline, the code is built if the scanner needs a compiled analysis database, the SAST engine scans and produces raw findings, those findings are triaged against severity thresholds and an accepted baseline, and finally the pipeline gate passes or fails the merge based on the triaged results. Triage has to sit between the raw scan and the gate — otherwise the gate would be re-litigating already-accepted findings on every single pull request.

Line 1 — suppressing the SAST finding with a nosemgrep comment instead of fixing the underlying string-interpolated query on line 2 leaves the SQL injection vulnerability in the shipped code; a suppression comment silences the tool, it doesn't change what the database executes

Line 3 — zap-baseline.py is invoked with no authentication or login sequence configured, so ZAP's spider and scanner can only ever discover and test the handful of pages available before login, and never touch the authenticated application surface where nearly all real functionality lives

Taint analysis tracks the flow of untrusted data — a 'source', like an HTTP request parameter, form field, or file upload — through a program's execution paths, checking whether that data can reach a dangerous operation — a 'sink', like a raw SQL query, a shell exec call, or an eval — without first passing through a sanitizer or validator on the way. Because it reasons about whether a real, reachable path actually connects a genuine source to a genuine sink, it rules out the classic false positive that plain pattern matching produces: flagging every call to a risky-looking function (any execute(), any exec()) even when the argument passed in that specific call site is a hardcoded constant that user input can never reach.

True. SAST analyzes source code directly and can gate the pipeline at the commit or build stage, while DAST requires a deployed, running application to probe live endpoints, so DAST cannot serve as a pre-build gate and typically runs after deployment to a staging environment.

I would design a scan orchestrator with four subsystems: a traffic observer, a crawl engine, a scan policy engine, and a finding correlator.

(1) Passive vs Active Decision: The platform ingests traffic passively via a proxy sidecar or CI replay harness. For every target, passive scanning runs first — it analyzes observed request/response pairs for issues detectable without injection: missing security headers, verbose error messages, cookie attribute problems, sensitive data exposure, TLS misconfigurations. Active scanning is enabled only for pre-prod environments registered in the platform with an explicit opt-in flag. The policy engine checks environment metadata: if the target is tagged 'production', only passive scanning is permitted. If tagged 'staging' or 'qa', active scanning is authorized but subject to safety controls. The rationale: passive covers observed traffic surface area efficiently and safely; active is required to probe parameter values and injection vectors that normal traffic never exercises.

(2) Active Scan Safety: The active scanner enforces several controls. First, an HTTP method allowlist — by default only GET and HEAD are used for active probing; POST/PUT/DELETE require per-endpoint opt-in. Second, an exclusion list of destructive or sensitive endpoints (payment, account deletion, admin reset) that are never actively scanned. Third, every active payload includes a canary marker (e.g., a unique prefix like 'dastscan-<uuid>') so any data written by the scan can be identified and cleaned up post-scan. Fourth, a configurable rate limiter caps requests per second per target to avoid overload. Fifth, for pre-prod environments, the orchestrator triggers a database snapshot before the scan and a restore after, guaranteeing that any data mutations are rolled back. For environments where snapshot/restore is not feasible, the scanner is restricted to read-only method allowlist.

(3) Authentication & Session Management: Each target registers an authentication profile specifying either a scripted login flow (sequence of HTTP requests to obtain a session cookie/token) or a static bearer token with a refresh mechanism. The scanner maintains a cookie jar per scan session. Before each batch of requests, a session health check pings a known authenticated endpoint; if it returns 401 or redirects to login, the orchestrator re-runs the login script to obtain a fresh session. For multi-role coverage, the platform runs parallel scan sessions under different roles (anonymous, standard user, admin), each with its own auth profile. Token expiry is handled by a background refresh timer that proactively re-authenticates before the token's stated expiry, and reactively on session health check failure.

(4) Finding Correlation: All findings — passive and active — are normalized into a common schema: {endpoint, HTTP method, parameter, vulnerability_class, evidence, confidence, source: passive|active}. The correlator groups findings by (endpoint, parameter, vulnerability_class). When a passive finding and an active finding map to the same group, they are merged into a single finding with combined evidence and a higher confidence score. For example, passive scanning might flag a missing Content-Security-Policy header on /search, and active scanning might confirm a reflected XSS in the 'q' parameter on the same endpoint — these merge into one XSS finding with both the header-gap signal and the injection proof. Findings that cannot be correlated remain standalone. A deduplication hash based on the group key prevents the same issue from being reported multiple times across scan runs; only the most recent evidence is retained.

I would build the crawler on top of a headless browser (Playwright/Puppeteer controlling Chromium) with four components: a DOM explorer, a network interceptor, a state tracker, and a coverage evaluator.

(1) SPA Crawl Strategy: The crawler loads each seed URL in the headless browser, waits for network idle, then begins DOM exploration. A MutationObserver watches for DOM changes as the crawler interacts with the page. The crawler extracts candidate interactive elements (anchors, buttons, inputs with onchange handlers, elements with role=button or onclick) from the rendered DOM — not from raw HTML, since SPA content is injected by JavaScript. For each candidate, the crawler clicks or triggers the element and observes the result: a DOM diff reveals new content, a URL change (via History API pushState or hashchange) reveals a new route. Each new route is added to the crawl frontier. The crawler explicitly handles both hash-based routing (#/products) and History API routing by listening to popstate and hashchange events. Traditional static-HTML crawlers that parse href attributes fail here because SPA navigation is triggered by JavaScript event handlers, not anchor hrefs.

(2) API Endpoint Discovery & Fuzzing: The crawler enables Chrome DevTools Protocol (CDP) Network domain to intercept all XHR and fetch requests the SPA makes. Each intercepted request is logged with its URL, method, headers, and body. The network interceptor builds a catalog of discovered API endpoints. For REST endpoints, the catalog records observed parameters (query params, path params, JSON body fields) and the crawler fuzzes each parameter with injection payloads (XSS, SQLi, SSRF, path traversal markers). For GraphQL, the crawler first attempts schema introspection (querying __schema). If introspection is disabled, it parses observed query/mutation bodies to extract operation names, field selections, and variable types, then uses this to construct modified queries with injected payloads in variables and inline arguments. Discovered API calls are replayed directly via HTTP (outside the browser) for faster fuzzing, while the browser context is reserved for crawl-time discovery.

(3) Application State Management: The state tracker maintains a graph of application states. A state is defined by the current route plus salient application data (e.g., items in cart, current wizard step). When the crawler performs an action (e.g., 'Add to Cart'), it records a state transition: (route-A, action) → (route-B, cart=[item1]). The crawler uses this graph to explore deeper states by chaining actions: navigating to a product page → adding to cart → proceeding to checkout → entering shipping info. Form fields are auto-filled with heuristic values (text fields get a canary string, numeric fields get a safe integer, selects get their first option). When the crawler reaches a dead-end (no new interactive elements or routes), it backtracks to a prior state and tries an unexplored action from that state. If backtracking is not possible in the current browser session (e.g., state is irrevocably changed), the crawler resets by reloading the seed URL and replaying the action chain to return to the desired state.

(4) Coverage & Termination: The coverage evaluator tracks four metrics: (a) unique routes visited (normalized URL paths), (b) unique API endpoints discovered (method + normalized path), (c) interactive DOM elements triggered vs total discovered, and (d) unique parameters fuzzed. The crawler terminates a seed URL's exploration when it hits a coverage plateau — defined as N consecutive crawl steps (default 50) with zero increase in any of the four metrics — or when a configurable budget is exhausted (default: 15 minutes or 5,000 requests per seed). The plateau heuristic is critical because SPAs can have effectively infinite interaction paths (e.g., infinite scroll, dynamic filters), so a pure budget limit may waste time on low-value exploration. The coverage metrics are also used to prioritize the frontier: seed URLs and routes with higher estimated unexplored interactive elements are crawled first.

The SDLC ordering from earliest to latest is: IDE real-time analysis → pre-commit scanning → CI SAST gate → container image scanning → DAST against staging → manual pentesting. Each activity requires an artifact produced by the prior stage—source being written, staged changes, pushed source, a built image, a running deployment, and a production-like environment respectively.

Use incremental/differential scanning combined with baseline suppression. Incremental (diff-based) scanning analyzes only files changed in the pull request relative to the merge-base, reducing scan time to seconds. Baseline suppression (also called baseline gating or findings baseline) stores the set of known pre-existing findings in a baseline file; the gate then only fails on NEW critical findings introduced by the diff — pre-existing ones are suppressed. To guarantee full coverage, a scheduled nightly full scan of the entire monorepo runs the SAST tool without diff mode and without baseline suppression, feeding any newly discovered findings back into the baseline or triggering alerts. This way: (1) PR gates are fast and actionable (only new, critical, diff-scoped findings block merge), and (2) the nightly full scan ensures the entire codebase is periodically covered so no critical finding persists undetected long-term.

In a shift-left pipeline, the six security gates fire in this order: pre-commit SAST on staged source → PR-level SCA on the resolved dependency tree → post-build container image scan → Kubernetes admission controller verifying the signed image → DAST against the deployed staging app → IAST under live production traffic. Each gate depends on an artifact (source, lockfile, built image, signed image, running app, production traffic) produced by the preceding stage.

Statements (a), (b), and (d) are true. SAST scans source code directly, so it finds hardcoded secrets never transmitted on the wire, which DAST cannot see. DAST actively injects payloads to confirm exploitable reflected XSS, whereas SAST only flags suspicious taint flows. DAST also detects runtime misconfigurations like missing security headers without source access. Statement (c) is false because path explosion and undecidability prevent SAST from achieving full path coverage—real tools approximate and prune.