Developers report that a high-severity finding on the utility billing API is fixed. What should happen before the finding is closed?
Select an answer to reveal the explanation.
Short Explanation
“We fixed it” is a claim until someone rechecks the lock. Re-test, then close. Trust-me emails, quiet severity drops, or archival sleight-of-hand are not verification.
Full Explanation
The reporting lifecycle requires verification that remediation actually resolved the issue before closure. When developers report that a high-severity finding on the utility billing API is fixed, re-testing—by security, an independent tester, or an agreed verification procedure—provides evidence of remediation effectiveness. Closing only after that confirmation prevents premature closure based on assertion and protects billing integrity and customer data.
Closing immediately based on the developer’s email alone accepts an unverified claim as fact. Lowering the severity silently without verification manipulates risk ratings instead of proving the fix. Transferring the ticket to an archive folder with no technical check is administrative sleight-of-hand that leaves the vulnerability potentially live.
Exam caveat: Remediation verification / re-testing is a standard step in assessment reporting and finding lifecycle management. ‘Developer said it’s fixed’ is a classic insufficient-closure distractor.
Operational check: Define re-test criteria for billing API findings, re-run the original exploit path or equivalent checks in a controlled environment, record pass/fail evidence on the ticket, only then close, and reopen automatically if the issue regresses in later scans.