City development is shipping a custom permitting app and wants coverage for insecure code, runtime flaws, and risky third-party libraries. Which approach best combines application security testing for vulnerability management?

Application security testing for a custom municipal permitting app must cover three complementary identification planes. Static analysis (SAST) examines source or bytecode for insecure patterns before deploy—injection sinks, weak crypto, hard-coded secrets—catching blueprint defects while developers can still fix them cheaply. Dynamic testing (DAST) exercises the running application as an attacker would, finding auth flaws, session issues, and runtime misconfigurations that only appear when the stack is live. Continuous package and software-composition monitoring watches third-party libraries for disclosed CVEs and abandoned components so a vulnerable transitive dependency does not ride into production unnoticed. Together they form a durable vulnerability-management identification strategy for custom city code.

Annual physical lock audits of developer offices address facility access, not insecure code, runtime flaws, or risky libraries. A single firewall allow-list review is network exposure hygiene; it cannot replace application testing inside the permitting service. Disabling dependency updates freezes known-bad packages in place and blocks security fixes, increasing rather than reducing library risk.

Exam caveat: CompTIA expects you to map SAST, DAST, and SCA/package monitoring to different stages and artifact types—do not treat “appsec testing” as one undifferentiated scan. Authorization and non-production targeting still apply for aggressive dynamic tests against citizen systems.

Operational check: wire SAST into the CI pipeline, schedule authenticated DAST against staging that mirrors production auth flows, and fail builds or open tickets when critical dependency CVEs appear, with owners assigned before the next permitting release.