Engineers patched a CVE on the water-billing API hosts. What should they do to confirm remediation?
Select an answer to reveal the explanation.
Short Explanation
Patching without a follow-up scan is like locking the door and never checking the latch. Re-scan to prove the CVE is actually gone—health checks and hopeful ticket closes do not count.
Full Explanation
Remediation is not complete until verification shows the weakness is gone. After engineers patch a CVE on water-billing API hosts, they should re-scan those hosts and confirm the vulnerability is no longer detected before treating the CVE as closed. Verification protects billing availability and citizen payment data from "fixed in paperwork only" failures.
Closing the ticket based on the change request alone skips proof. Disabling the scanner permanently so the finding cannot return hides regressions. Assuming success if HTTP health checks still pass only proves the process is up, not that the CVE is remediated.
Exam caveat: verification usually means authenticated re-scan or targeted check for the specific CVE/version, not generic uptime monitoring. Keep evidence for audit.
Operational check: run a post-change vulnerability scan against the billing hosts, attach clear/fail evidence to the ticket, reopen if the CVE persists, and update the patch baseline. Include verification as a required gate in the municipal vuln workflow.
Keep the pre-patch and post-patch scan artifacts with the water-billing change record so finance and security leadership can see verification evidence during audits, not merely a closed ticket timestamp.