Vulnerability management, end to end

Objective 4.3 is a scenario objective: you are put in the middle of the vulnerability management cycle and asked what to do next -- find, prioritise, fix, prove the fix, report. It is one objective out of twenty-seven in SY0-801, so this is one lesson rather than four. Our CompTIA CySA+ CS0-004 course takes the same ground considerably further, because CS0-004 examines it as a whole domain; SY0-801 does not, and this lesson is scoped to what SY0-801 asks.

Why this matters

Vulnerability management is a cycle, and the exam tests the cycle rather than the scanner. Candidates who revise "run a scanner" lose marks on the questions that actually appear: where the scanner's blind spots are, what to fix first, what to do when a patch cannot go in, how to prove a fix held, and how outsiders should tell you about a flaw they found.

The most commonly missed idea is that the output of a scan is not a work list. It is raw material that has to be validated, prioritised against business context, and turned into decisions.

One boundary to know: threat feeds, CVE identifiers and CVSS scoring are now taught as characteristics of a vulnerability in lesson 9. This lesson uses them; it does not re-teach them.

The lesson

Finding vulnerabilities: scanning, address management, cloud posture management and code review

Identification has several methods, and they are complementary rather than alternatives. Each sees something the others miss.

• Vulnerability scanning -- automated, broad, regular. Credentialed (authenticated) scans log in and read installed versions and configuration, so they are far more accurate; non-credentialed scans see only what is exposed and approximate an outside attacker's view. Use credentialed scans for coverage and non-credentialed scans to understand exposure.
• IP address management (IPAM) -- the system that records which addresses and subnets are allocated, to what, and through DHCP and DNS. Its value here is scope. A scanner only tests the ranges it is given, so a subnet missing from the scan configuration is a blind spot that produces a clean report. Comparing IPAM records with what actually answers on the network finds both unscanned ranges and devices nobody registered.
• Cloud security posture management (CSPM) -- tooling that continuously reads cloud account configuration through the provider's APIs and compares it with policy: storage left publicly readable, security groups open to the whole internet, logging switched off, keys never rotated. Most cloud weaknesses are misconfigurations rather than missing patches, and a traditional network scan does not see them at all.
• Source code review -- reading the code, by people, by static analysis tools, or both. It finds flaws a scanner cannot reach because they are in logic, not in a version number: missing authorisation checks, unsafe handling of input, secrets written into the source. It is cheapest early, before the code ships.

The point to carry: no single method finds everything, and the gaps are predictable. Scanners miss what is outside their scope and what is a logic flaw; CSPM sees configuration, not code; code review sees code, not how it was deployed.

Prioritising by severity, and reading a penetration test report for what to fix first

A severity assessment starts from the published score and then adds the context the score cannot contain. CVSS describes the vulnerability in the abstract; your priority depends on your environment:

• Exposure -- internet-facing, or on an isolated internal segment?
• Asset criticality and data classification -- what does the host do and what does it hold?
• Active exploitation -- is working exploit code public, and is it being used? A medium-severity flaw under active exploitation outranks a critical one that nobody has managed to exploit.
• Controls already in place that reduce the chance of exploitation.

The exam's expected reasoning: an internet-facing, actively exploited, medium-severity finding is more urgent than an internal critical with no known exploit.

A penetration test report is a different kind of input, and V8 names its review as part of prioritisation. A scanner says a weakness is present; a tester shows whether it is exploitable here, and often how several findings the scanner rated low were chained into something serious -- a weak password on one host, reused on a second, which held a route to the database. Reading the report well means:

• start with the attack paths the testers demonstrated, because those are proven, not theoretical;
• fix the link that breaks the most chains first, which is often not the highest individual rating;
• note the root causes -- a missing baseline, a process gap -- and send them to whoever owns the process, not only the host;
• check the scope and dates: a report describes what was tested, when, and nothing else.

Remediation, and the compensating control for when a patch cannot go in

Patching is the default answer and not the only legitimate one.

• Patching -- removes the vulnerability. It goes through change management (lesson 5), and the fix should land in the golden image or baseline as well, or the next rebuild brings the flaw back.
• Configuration change -- disabling the vulnerable feature, closing the port, tightening the setting. Often faster than a patch.
• Segmentation -- reducing who can reach the vulnerable system at all.
• Compensating controls -- a different control that addresses the same risk when the fix itself is impossible: virtual patching with a WAF or IPS rule, tighter access control, extra monitoring on that host.

The scenario the exam likes: a medical device, controller or legacy server cannot be patched because the vendor no longer supports it, or because patching would void certification. The answer is to isolate it, restrict access to the few systems that need it, monitor it closely, and record the decision with an owner and a review date. When nothing can be done, the remaining risk is accepted formally by someone with the authority to accept it, through the risk process in lesson 43. Formal exceptions and the cost of risk transfer belong to that lesson; here the point is that an unpatchable system is still managed, not ignored.

Verification: rescanning, and proving the fix held

Remediation is a claim until it is verified, and this is the stage skipped most often.

• Rescanning is the direct check: run the scan again and confirm the finding is gone. This catches the patch that was downloaded and not applied, applied and not rebooted, or applied to one of three hosts in a cluster.
• Confirming the root cause is the human step: did the fix address the underlying problem, or only the symptom the scanner looks for? Changing a version banner makes a finding disappear and fixes nothing.
• Retesting an exploited path from a penetration test confirms the chain is actually broken.

Two failure modes worth naming. A finding that disappears because the host stopped responding to the scanner reads exactly like a fix -- so a drop in findings should always be checked against a stable asset count. And a finding that reappears after a rebuild means the golden image was never updated; the same work is being repeated every month, and the fix belongs in the baseline.

Reporting inside and out, bounties and disclosure policies, and where CySA+ goes further

Internal reporting turns findings into something the organisation acts on, and different audiences need different reports:

• Technical teams need the finding, the affected hosts, the fix, and the deadline.
• Management needs trend and exposure: how many criticals are open, how long they stay open (mean time to remediate), whether the backlog is growing, and which business areas carry the risk.
• Auditors and regulators need evidence the process runs as documented -- scan frequency, coverage, remediation deadlines met.

The useful metrics are about flow, not stock. A total of open vulnerabilities rises when scanning coverage improves, which is a good thing reported as a bad one.

External reporting runs the other way: how people outside the organisation tell you about a flaw they found.

• A responsible (coordinated) disclosure policy publishes how to report a vulnerability, what the organisation commits to in return -- acknowledgement, a fix timeline, credit -- and that good-faith researchers who follow the rules will not be pursued. Without one, a researcher who finds a flaw has no safe route, and some go public instead. Many organisations also publish a security.txt file on their website so the contact point is easy to find.
• A bug bounty programme goes further and pays for valid reports, within a defined scope and rules of engagement. Its value is many skilled people testing continuously; its cost is triage volume and the need for a team that can respond quickly.

Both depend on the internal process working: a report that arrives and then sits unanswered for months damages trust faster than having no programme.

Where this stops for SY0-801. The exam tests the cycle, the identification methods, the prioritisation reasoning and the reporting routes above. CS0-004 -- CySA+ -- examines the same material as a substantial share of a whole exam, adding scanner configuration and tuning, deeper scoring work, threat intelligence integration and detailed attack-surface analysis. If you want that depth it is a different certification, and our CySA+ course covers it. For SY0-801, this lesson is the scope.

What to take into the exam

• Scanning finds what is in scope; IPAM shows whether the scope is complete; CSPM finds cloud misconfiguration; code review finds logic flaws.
• Prioritise by exposure, asset criticality and active exploitation -- not by the severity column alone.
• A pen test report proves exploitability and chains; break the chain that the most paths depend on.
• When a patch cannot go in, isolate, compensate, monitor and record an owner.
• Rescan to verify, and check that a drop in findings is not a host that stopped answering.
• A disclosure policy gives outsiders a safe route to report; a bounty pays them for it.