Vulnerability Management

A clean external scan, an open port and a 9.3 severity score all look like answers, yet each one answers a narrower question than the one an analyst usually brings to it. The clean scan speaks only for what the scanner could reach, the open port proves that something is listening rather than that anything is broken, and a Common Vulnerability Scoring System (CVSS) Base score rates how severe the flaw is in itself, assuming a reasonable worst case across environments (FIRST CVSS v4.0 specification), not the risk to your organization. That single habit runs through all of Vulnerability Management, which at 26% of the exam is the second-largest of the four CySA+ domains (CompTIA CySA+ V4): name the question an output was built to answer, and never let it answer a bigger one. An answer option that treats a scan, a score or a change ticket as proof of something it never measured is the trap this habit catches.

The four subtopics follow a vulnerability from discovery to decision, and each one answers a single question. Implement appropriate vulnerability scanning methods answers What could the scan see?: it builds the target list from an asset inventory and chooses each scan along four scan dimensions, namely viewpoint (internal or external), access (credentialed or non-credentialed), deployment (agent-based or agentless) and interaction (active or passive). Analyze vulnerability assessment output answers What does this output prove? by sorting tool output into five evidence types: reconnaissance lead, identification evidence, vulnerability evidence, exploitability evidence and defensive evidence. Prioritize and mitigate vulnerabilities answers What goes first, and did the fix work? in five stages: validate that a finding is real, read three signals (CVSS for technical severity, the Exploit Prediction Scoring System (EPSS) for the probability of exploitation in the next 30 days, and the CISA Known Exploited Vulnerabilities (KEV) catalog for confirmed exploitation in the wild), add the asset's value and how reachable the vulnerable function is, choose a response, and verify it. Explain vulnerability risk, controls, and governance answers How is the risk judged and governed?: it classifies controls by type and by function, compares the risk left after treatment with what the organization is willing to accept, chooses among the four risk management strategies (accept, transfer, avoid, mitigate), and covers the policy, service-level objectives (SLOs, measurable remediation time targets), exceptions, application security testing and third-party software risk that keep those decisions consistent.

When two answers both seem to work, prefer the one that demands evidence for its exact claim: confirm a check actually ran before reading silence as safety, validate a finding (confirm it exists) before ranking it, and verify a fix (confirm it took effect, by a rescan or direct inspection) before closing it, because NIST's software vulnerability management life cycle makes verifying the response and continuously monitoring it explicit steps (NIST SP 800-40 Rev. 4). Keep the status words honest too: NIST SP 800-40 Rev. 4's mitigate covers both removing a weakness (for example by patching) and reducing its risk while the weakness remains behind a compensating control (a control used in place of the fix to reduce exposure); as finding statuses these pages call the first outcome remediated and the second mitigated, whose remaining risk is tracked rather than treated as gone. A finding left unfixed on purpose needs an exception, which is a documented, approved decision for a stated period that is tracked and reviewed, not a quiet delay. Above every finding sits the same test: the risk left after treatment, called residual risk (NIST glossary), is compared with the organization's risk appetite, the types and amount of risk it is willing to accept (NIST glossary), and applying a control does not by itself make that remaining risk acceptable.