Which statement correctly places static analysis for DEVCOR task 4.3 versus application security mitigations?
Select an answer to reveal the explanation.
Short Explanation
4.3 asks why the scanner sits on the assembly line—in CI—before the crate ships. How you harden the app against OWASP issues is a different station (4.10), not a live exploit demo.
Full Explanation
Static analysis for DEVCOR task 4.3 belongs in the CI pipeline as a control before promote; OWASP-style application security mitigations in the app are a separate task. Place the scanner on the assembly line so known patterns fail the build before the civic artifact ships. Hardening request handling, output encoding, and related mitigations inside the application is complementary work with its own objective—not a substitute for, or definition of, the 4.3 CI control.
Requiring a live XSS exploit demonstration against production Webex spaces confuses offensive proof-of-concept theater with a pipeline quality control and risks real municipal systems. Forcing candidates to pick and administer a specific SAST vendor SKU as the only correct answer invents a product-administration skill the task does not demand. Claiming static analysis replaces the need for any tests or quality gates in CI overstates its role—it is one control among tests and promote policies.
Exam caveat: know where static analysis sits (CI, before promote) versus app-layer mitigations; do not conflate the two tasks or require a named commercial console. Operational check: verify the pipeline job runs analysis pre-promote, confirm high-severity findings can fail the build, and keep OWASP mitigations tracked as application controls rather than as the sole definition of 4.3.