Security wants to probe a running staging build of the public parks reservation portal the way an external attacker would. Which test fits?
Select an answer to reveal the explanation.
Short Explanation
DAST is the road test—you run the car and see what rattles under real traffic-like conditions. Pointing it at staging of a public portal finds runtime issues source review alone can miss. Civic sites need that outside-in look before citizens pile on.
Full Explanation
Dynamic application security testing (DAST) exercises a running application from the outside, roughly the way an external attacker would probe HTTP endpoints, sessions, and inputs. Pointing DAST at a staging build of the public parks reservation portal finds runtime issues—misconfigurations, auth gaps, injection reflected only at runtime—that static review may miss. Staging preserves production-like behavior without aiming hostile scans at live reservation data.
Manual review of procurement invoices for the hosting contract is financial/procurement oversight, not application security testing of a running portal.
Counting lines of code to estimate residual risk is a weak proxy metric. LOC does not identify exploitable flaws or validate staging defenses; volume is not vulnerability.
Static linting of CSS color variables only addresses presentation consistency, not security properties of authentication, session handling, or input validation on a reservation system.
Exam caveat: DAST requires a running instance and black-box style probing; do not confuse it with SAST, SCA, or non-security reviews. Operational check: schedule authenticated and unauthenticated DAST against municipal staging before releases, synchronize findings to the backlog by severity, exclude production unless carefully controlled, and verify that staging mirrors relevant security headers and auth modes so results are meaningful.