A weekly vulnerability scan of the city's permitting API hosts reports several outdated application libraries. Which vulnerability-management activity does that report represent?
Select an answer to reveal the explanation.
Short Explanation
The weekly scan is the neighborhood watch spotting cracked windows—it finds the outdated libraries. Finding them is identification; fixing, accepting, or proving them gone comes later.
Full Explanation
Vulnerability management begins with identification: discovering weaknesses present on assets. A weekly scan of the city’s permitting API hosts that reports outdated application libraries is performing identification—it surfaces findings for later prioritization and remediation, not automatic repair. Accurate identification is how municipal security learns what libraries place citizen APIs at risk.
Remediation would be patching or mitigating those libraries, which listing alone does not do. Risk acceptance requires deliberate documented decision, not merely having a weekly schedule. Verification confirms a fix worked, typically via re-scan after remediation—not the initial discovery report.
Exam caveat: know the lifecycle order—identify, assess/prioritize, remediate/mitigate/accept, verify. Scanners identify; they do not by themselves remediate.
Operational check: ingest the scan into the tracking system with asset owners, classify library findings, assign due dates by severity/exposure, and keep the raw report as evidence of identification date for metrics such as time-to-remediate on the permitting service.
For city vulnerability metrics, stamp each permitting-API finding with discovery source and first-seen date so time-to-remediate calculations remain honest, and ensure owners acknowledge identification tickets even when remediation will land in a later change window.