CompTIA Security+ SY0-801 Vulnerability Management: Scanning, Prioritization, Remediation and Disclosure

Vulnerability management is a repeating cycle of five tasks: identify weaknesses, prioritize them, remediate them, verify the fix and report the results. It never finishes, because new systems, new code and newly published flaws keep arriving. CompTIA Security+ objective 4.3 is a "given a scenario, perform" objective, so it asks which task comes next, which method fits a gap or who should act.

Two rules run through the whole cycle. First, a finding is tracked against an asset with an accountable owner, so it can be followed from discovery to closure. Second, a finding is closed only when verification shows the weakness is gone. A finding that is reduced by a control, accepted by the business or simply "worked on" stays open in the record. Scoring and prioritization sources such as CVSS and CVE are covered in objective 2.1; this lesson covers what the operations team does with the findings.

Scanning is the main identification method, and the right configuration depends on what you want to see. Three independent choices shape every scan: whether it logs in, where it runs from and how aggressive its checks are.

Combine the choices to model a specific threat. An unauthenticated attacker inside the building is modelled by a non-credentialed internal scan: a credentialed scan would show more than that attacker can see, and an external scan would show less, because perimeter filtering hides internal services. A credentialed scan is the one that reliably reports missing operating system patches and insecure local settings, because those facts live on the host, not on the wire.

If scans have crashed or rebooted fragile devices, the answer is to switch to non-intrusive checks, not to stop assessing the devices. Dropping them from assessment leaves their weaknesses unknown; the fix is to change what the scan does to them. Note also that a port scan is not a vulnerability scan: it lists open ports and services but does not assess them for flaws. Scanner tooling itself (agents versus agentless, SCAP, benchmarks) is covered under alerting and monitoring in objective 4.4.

A scanner finding is evidence, not proof, so it must be validated before the team acts on it when there is reason to doubt it. A false positive is a reported flaw that is not actually present; a false negative is a real flaw the scan missed. False positives waste remediation effort and erode owners' trust in the reports; false negatives leave real risk unseen.

The classic false-positive cause is version-based (banner) detection. A non-credentialed scan often cannot test a flaw directly, so it reads the version a service advertises (for example in a web server or SSH banner) and assumes every flaw known for that version is present. Linux and other distributions frequently backport security fixes: they patch the flaw into the old version they ship and keep the original upstream version string. The banner therefore still looks vulnerable after the fix is installed.

The way to settle the question is an authenticated (credentialed) check, which reads the installed package release and its changelog or fix list rather than the advertised version. Then act on the result:

• If the installed package contains the fix, document the finding as a false positive with that evidence, and tune or suppress that check for the host if the scanner supports it.
• If the package does not contain the fix, the finding is a true positive and moves to prioritization and remediation.

The principle is to act on validated evidence, not on the symptom the scanner reads. Changes made only to satisfy the scanner fix nothing, and changes made before validation risk breaking a supported system for a flaw that may not exist. A finding the evidence shows is absent is a false positive and is closed with that evidence; risk-handling tools are for flaws that are real.

A scanner can only assess what is in its scope and what it is designed to look at. IPAM and CSPM close the two biggest gaps: hosts the scanner does not know about and cloud settings a host scanner cannot see.

IP address management (IPAM)

IPAM is the central record of address space: which subnets exist, which addresses are allocated or leased (including DHCP leases) and what they are assigned to. As an identification source it answers "what is actually on the network?" Comparing IPAM data with the scan target list exposes addresses in use that are never scanned, which happens whenever a target list was built by hand and has drifted. Sources that describe only part of the network, or describe it as it used to be, cannot replace IPAM as the record of which addresses are actually in use.

When IPAM reveals unknown hosts, the first step is to bring them into scan scope: scanning tells the team what they are and how exposed they are, and the asset inventory can then be updated. Assessment comes before any decision to block, remove or accept a host, because none of those choices can be made sensibly about a system nobody has examined. IPAM also exposes a tracking problem. Servers that receive new addresses when rebuilt look like new hosts, so their old findings appear "fixed" and reappear elsewhere. The fix is to take scan targets from IPAM and track findings by asset (hostname, agent ID or inventory record), not by IP address.

Cloud security posture management (CSPM)

CSPM continuously checks the configuration of cloud accounts against benchmarks such as the CIS benchmarks and the organization's own policies. It reads control-plane settings through the cloud providers' APIs, across many accounts and often several providers, and flags risks such as storage that is publicly readable, logging that is turned off, overly broad identity permissions or unencrypted resources.

These are settings of the cloud service, not of any virtual machine, so a host vulnerability scan, however frequent and credentialed, does not see them. A clean VM scan and a months-old public storage bucket can exist side by side. CSPM is about how cloud resources are configured, which sets it apart from tools that govern how users reach cloud services or that filter traffic and protect individual hosts.

Cloud resources are often created by infrastructure as code (IaC). If a template still declares a risky setting, a fix made by hand in the console, or by an automatic CSPM remediation applied to the running resource, is reverted at the next deployment and the finding returns. Remediate IaC-managed findings in the template, then let the next CSPM check confirm the fix. Suppressing the rule is not remediation.

Source code review is the identification method in which a person reads the code before it is released to find security flaws. It examines source, not a running system, which separates it from dynamic analysis, penetration testing and vulnerability scanning, all of which work against deployed software.

Its distinctive value is finding flaws that depend on business logic and authorization rules that no tool can infer from the code alone. Examples include:

• An endpoint that checks the user is signed in but never checks that the user owns the record being requested (a broken object-level authorization flaw).
• A discount, approval or payment step that can be skipped by calling a later step directly.
• A role check applied to one route but missing from another that does the same thing.

Nothing in such code is syntactically wrong, so a pattern-based static analysis tool scanning the whole codebase with current rules has nothing to flag. A reviewer who knows that users must only read their own records sees the omission. That is why manual review complements automated tools rather than duplicating them: tools are fast and consistent at known patterns, reviewers catch missing rules. Static analysis and secrets scanning as preventive controls in the development pipeline are covered in objective 4.1.

Prioritization decides the order of remediation, and the rule is that real risk in this environment, not the raw rating, sets the order. A base severity score describes a flaw in a generic environment. Severity assessment adjusts it with three kinds of context:

Context can therefore make a medium flaw on an internet-facing payment server more urgent than a critical flaw on an isolated lab server. Context changes urgency, never whether the flaw gets fixed. A compensating control such as a vendor WAF rule that blocks known exploit requests reduces likelihood, so the finding can be ranked below unprotected criticals, but the flaw is still present and signature rules can be evaded. The finding stays open, tracked to the real fix; it is not closed as remediated and it is not a false positive. Facts about the record itself, such as when it was logged, say nothing about risk.

Penetration test report review

A penetration test report is a prioritization input because it shows what an attacker actually achieved. Two principles follow:

• Proof beats inference. A scanner infers that a flaw may exist; a tester who extracted data through it has proved the flaw is real and exploitable. A finding the scanner rated low-confidence, or that a developer calls a false positive, is prioritized as exploitable once the report shows exploitation. Demonstrated exploitation is the strongest evidence available and overrides the scanner's confidence rating.
• Attack chains outrank isolated scores. Scanners rate each finding alone. A report that shows several medium findings combined into domain administrator access describes far more damage than a critical flaw on an isolated test server. Remediating one link that breaks the chain removes the demonstrated path quickly; the remaining links follow.

Reports are written for two audiences. The executive summary gives leadership and the board the overall risk and its business impact in non-technical language. The technical findings give engineers the affected systems, reproduction steps, evidence and remediation advice. The methodology section documents how the test was performed, and raw tool output is supporting evidence. Penetration test types belong to objective 5.5 and rules of engagement to 5.3.

Remediation removes a vulnerability or, when that is impossible for now, reduces its risk to an accepted level under an approved, time-limited exception. Choose the strongest option the constraints allow:

• Patch or update: the normal fix when the vendor provides one.
• Configuration change: fixes flaws that are settings, such as a weak protocol or a public storage policy.
• Disable or remove the vulnerable component: if the flaw sits in a feature or module the organization does not use, turning it off closes the attack surface without affecting users. Apply the patch when it arrives and verify.
• Upgrade or replace: required when a product is end of support and no fixes will come.

Compensating controls when a patch is not possible

Some systems cannot be patched: an unsupported operating system on equipment whose vendor will not certify an upgrade, or a legacy application awaiting replacement. The aim is then to reduce exposure until the real fix. The standard answer is isolation and segmentation: place the system in its own internal segment and allow only the traffic it genuinely needs. The point is to shrink who can reach the system, so the segment must not be one designed to accept outside traffic, and measures that only detect the flaw again leave its exposure unchanged.

Write the allowed flows precisely. Suppose an unsupported database server must accept connections only from one application server. The rule permits the database port with the application server as source and the database server as destination, followed by a deny for all other traffic to the database server. Check each element: the source is the client that opens the connection, the destination is the protected system, the port is the one service it needs, and the final rule denies everything else. Segmentation and firewalls as mitigating controls are covered in depth in objective 4.1.

Exceptions

An exception records a decision to live with a known, unremediated vulnerability for a defined period. A valid exception has four properties:

When an exception expires, the risk goes back to the owner for a fresh decision. If the controls still work and the fix has a new date, the owner approves a renewed exception with a new expiry. An expired exception is never extended automatically or made open-ended: each renewal is a new, dated decision by the accountable owner. Risk acceptance as a governance concept belongs to objective 5.2; here it is the operational record of a finding.

Verification confirms that remediation actually removed the weakness, and it is the step that allows a finding to be closed. A closed change ticket proves that work was done, not that the flaw is gone. Use the method that matches how the flaw was found:

A common trap is that installed is not the same as running. A kernel update takes effect only after a reboot, and a library or service update often needs the service restarted. Package inventory may show the new kernel on every server while a credentialed rescan still reports the flaw on those that have not rebooted, because the scanner sees the kernel actually running. A problem with the tool would affect every host alike, so when only some hosts disagree with the inventory, look for what is different about those hosts.

For penetration test findings, management usually wants assurance that the attack path no longer works, not only that each change was made. Records of what was changed show activity, and a single-step check does not reproduce a multi-step path; only a retest of the same exploits does.

Internal reporting turns findings into action and oversight, and each audience needs a different report. The test is whether the report is scoped to the reader and carries the detail the reader needs.

A report that suits one audience usually fails another: summaries lack the detail an owner needs to act, unfiltered exports bury each owner's items among everyone else's, and charts show direction without saying what to change. Owners need both scope and detail.

The key speed metric is mean time to remediate (MTTR): the average time from a finding's discovery to its verified closure. Plotted per period, it shows whether teams are fixing flaws faster or slower. Backlog size and activity counts describe how much there is and how much was done, not how fast flaws are closed. Note that the SY0-801 acronym list expands MTTR as mean time to repair, a recovery metric; in vulnerability reporting the same letters usually mean mean time to remediate, so read the context. Organizations commonly set remediation deadlines by severity and report findings that pass them.

External reporting covers flaws that cross the organization's boundary in either direction: outsiders reporting flaws in the organization's systems, and the organization reporting flaws it finds in other people's products. Objective 4.3 names two mechanisms, bounty programs and responsible disclosure policies.

A bounty's scope must exclude anything the organization cannot authorize testing of, such as systems a third-party provider hosts and operates. Other program terms govern rewards and confidentiality; only the scope decides which targets researchers may test. A company that wants a reporting channel and legal reassurance without paying anyone publishes a VDP; adding rewards turns it into a bounty.

To help researchers and tools find the reporting contact, publish a security.txt file at /.well-known/security.txt, defined in RFC 9116. It requires a Contact field and an Expires field and can point to the disclosure policy with a Policy field. It is unrelated to robots.txt and sitemap.xml, which serve search engines.

Responsible (coordinated) disclosure

Responsible disclosure, also called coordinated vulnerability disclosure, means reporting a flaw privately to the party that can fix it and publishing details only after a fix is released or an agreed deadline passes. Full disclosure skips the private step and publishes immediately, which helps attackers before defenders can act.

The same rule applies when the organization is the finder. A previously unknown flaw in a commercial appliance or an open-source library should be reported privately to the vendor or project maintainers, through their security contact or private advisory channel. Anything made public before a fix exists tips off attackers, delay leaves the flaw open, and a fix kept inside the company leaves every other user of the product exposed. Contain the risk internally while the vendor works on the fix.

If the vendor stops responding and the agreed deadline has passed, escalate to a coordinator such as CERT/CC or a national CSIRT, which can press the vendor, publish an advisory with workarounds and set a disclosure date. Escalation keeps disclosure coordinated; going public without a fix or guidance only helps attackers. The disclosure policy as a governance document is part of objective 5.1; the reporting task itself belongs here.