Chapter 2: Vulnerability Management

Vulnerability management is the discipline that keeps an organization's weaknesses from becoming an

attacker's opportunities. It is not a single tool or a single scan. It is a continuous program: discover what you

own, find the weaknesses in it, decide which weaknesses matter most, fix them, prove they are fixed, and report

the results. A candidate who understands only how to run a scanner will fail this domain. The exam tests

whether you can run the whole program - choosing the right scan type, reading the output honestly, prioritizing

by risk rather than by severity score alone, and handling the messy realities of exceptions, zero-days, and assets

you cannot patch.

This chapter covers Domain 2 of the CySA+ CS0-004 exam, which carries 26% of the exam weight. That makes it

the second-largest domain, and it is the domain where careful reading matters most: many questions present a

scan result or a business constraint and ask what the analyst should do next, not what a term means.

2.1 The vulnerability management lifecycle

A vulnerability management program runs in a cycle, not a straight line. New assets appear, new vulnerabilities

are published daily, patches change the picture, and yesterday's clean scan is today's exposure. The cycle has six

stages:

1. Discover. Maintain an accurate asset inventory. You cannot scan what you do not know exists, and

shadow IT - servers, cloud workloads, and test systems nobody registered - is where the worst findings

hide.

2. Assess. Run scans and other assessments to find weaknesses in the inventoried assets.

3. Prioritize. Rank findings by risk, not by raw count or raw severity score.

4. Remediate. Fix, mitigate, or formally accept each finding within its deadline.

5. Verify. Rescan or otherwise prove the fix worked. A ticket marked "done" is not proof.

6. Report. Communicate status, trends, and exceptions to the audiences that own the risk.

Why asset inventory comes first

Every vulnerability management failure story starts the same way: an asset nobody knew about. At

CertCrack.com, for example, the security team once discovered a forgotten test server still running an old web

framework - it had never been scanned because it had never been inventoried. The fix was not a better scanner.

It was a discovery process: network sweeps, cloud account enumeration, and reconciliation against the

configuration management database.

Discovery methods include active network scanning, passive traffic observation, cloud provider APIs that list

resources, and agent enrollment reports that reveal which hosts have never checked in. The exam expects you

to know that an accurate inventory is a prerequisite, not an afterthought.

Figure: the vulnerability management lifecycle

2.2 Vulnerability scanning methods

Scanning is the assessment stage of the lifecycle, and the exam tests the differences between scan types in

detail. The wrong scan type produces misleading results, and the exam loves scenarios where the analyst chose

the wrong one.

2.2.1 Credentialed versus non-credentialed scans

A credentialed scan logs in to each target with supplied credentials - typically a dedicated read-only service

account - and inspects the system from the inside: installed software versions, patch levels, configuration

settings, local user accounts, and registry or file contents. A non-credentialed scan, sometimes called a

network-based or unauthenticated scan, probes the target from the outside only: open ports, banners, and

responses to crafted requests, without logging in.

Access Logs in with a service account No login; external probing only

Accuracy Higher; confirms installed versions and patches Lower; relies on banners and behavior

False positives Fewer More, especially where banners are misleading

Coverage Sees local configuration and missing patches Sees only what is network-visible

Risk Credentials must be protected; a compromised scan account is a target Minimal credential risk

Best for Regular internal assessments, compliance evidence External perimeter checks, assets you cannot log in to

2.2.2 Agent-based versus agentless scanning

Agent-based scanning installs a small software agent on each host. The agent collects vulnerability data locally

and reports it to the central console, on a schedule or continuously. Agentless scanning performs all work from

a central scanner over the network, with no software on the target.

Agents shine where network scanning struggles: laptops that are rarely on the corporate network, cloud

workloads that appear and disappear, and hosts behind network address translation. An agent on a laptop

reports in whenever the laptop connects, even from a coffee shop. Agentless scanning is simpler to deploy -

nothing to install or maintain on endpoints - but it can only assess hosts that are reachable from the scanner at

scan time.

Deployme nt Agent installed on every host No endpoint software

Reach Works off-network and on ephemeral hosts Only hosts reachable at scan time

Maintena nce Agent updates and troubleshooting Scanner maintenance only

Maintena nce Agent updates and troubleshooting Scanner maintenance only

Frequency Continuous or frequent reporting Typically scheduled scan windows

Weakness Agents can fail, go stale, or be uninstalled Blind to hosts that are offline during the scan

2.2.3 Network, web, cloud, and container scans

Different asset types need different scan types, and the exam tests whether you match the tool to the target.

• Network vulnerability scans probe hosts for open ports, services, operating system weaknesses, and

missing patches. They are the default scan type for servers and workstations.

• Web application scans test running applications for flaws such as injection, broken authentication,

cross-site scripting, and insecure configuration. A network scan cannot find a SQL injection flaw; it takes a

web scan that actually exercises the application's inputs. Dynamic testing sends requests to the live

application, while static testing examines source code before deployment - both belong in a mature

program, and the exam may ask which fits a given stage.

• Cloud scans assess cloud configurations, not just hosts: public storage buckets, overly permissive identity

policies, unencrypted databases, and misconfigured security groups. A traditional network scan of a cloud

workload misses the control plane entirely.

• Container scans inspect container images for vulnerable packages and misconfigurations before

deployment, and running containers afterward. The key exam point is timing: scan the image in the

pipeline, before it reaches production, because fixing a base image is far cheaper than patching a hundred

running containers built from it.

2.2.4 Scheduling, scope, and safe scanning

Scanning is not free of risk. An aggressive scan can crash fragile services, flood a small network link, or trigger

intrusion detection alerts across the organization. Good programs manage this with:

• Scan windows. Run intensive scans during maintenance windows or low-traffic periods, and coordinate

with system owners so a scan is never a surprise.

• Scope definition. Define exactly which addresses, cloud accounts, and applications are in scope, and

exclude sensitive systems explicitly. Scanning a system you do not own, such as a vendor's hosted service,

can violate contracts and even the law.

• Scan credentials and throttling. Limit concurrent checks against fragile hosts, and use scan policies

tuned for the target type rather than maximum intensity everywhere.

• Notification. Tell the SOC and the network team a scan is running, so scan traffic is not mistaken for an

attack - and so real attack traffic during a scan window is not dismissed as scanner noise.

2.2.5 Operational technology and passive constraints

Operational technology (OT) - the systems that run factories, power grids, and building controls - breaks normal

scanning assumptions. Many OT devices run old, unpatchable firmware, cannot tolerate unexpected traffic, and

control physical processes where a crash has safety consequences. Active scanning of OT networks can disrupt

production or, in the worst case, endanger people.

For OT and other fragile environments, the standard approach is passive monitoring: observe traffic without

sending probes, analyze network flows and protocol behavior, and infer vulnerabilities from observed versions

and known device fingerprints. Passive assessment trades completeness for safety. The exam tests this trade-off

directly: when a scenario involves industrial control systems, medical devices, or legacy systems that cannot be

scanned actively, the correct answer is passive monitoring and compensating controls, never an aggressive

credentialed scan.

Running a version scan, step by step

A version scan asks each open port what software answers there. Run it against your own lab machine only:

1. Start the lab virtual machine and confirm its address.

2. Run a version scan against that address.

3. Read the output port by port: which ports are open, and which service and version answers on each.

4. Compare what you find with what you know is running, and note which findings a vulnerability scanner

would flag next. A version the vendor no longer patches is a finding even before a scanner says so.

Terminal session: a version scan with Nmap (illustrated session)

2.3 Reading assessment output

A scan report is not a verdict. It is raw material that an analyst must interpret, and the exam spends

considerable weight on this skill. The same finding can be a critical emergency or a non-issue depending on

context, and the analyst's job is to tell the difference.

2.3.1 CVSS: severity, not risk

The Common Vulnerability Scoring System (CVSS) is the industry's standard way to rate vulnerability severity on

a scale from 0.0 to 10.0. It has three metric groups:

• Base metrics describe the intrinsic properties of the vulnerability: how it is attacked (attack vector -

network, adjacent, local, or physical), how complex the attack is, what privileges are required, whether user

interaction is needed, and what impact it has on confidentiality, integrity, and availability. Base metrics do

not change over time or between organizations.

• Temporal metrics describe factors that change over time: whether exploit code exists and how mature it

is, whether a fix is available, and how confident the report is. A vulnerability with public exploit code scores

higher temporally than one with no known exploit.

• Environmental metrics let an organization adjust the score for its own context: how critical the affected

asset is, and whether compensating controls reduce the impact. Two organizations with the same

vulnerability can legitimately arrive at different environmental scores.

The qualitative severity bands for the base score are: None (0.0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9),

and Critical (9.0-10.0).

2.3.2 False positives, false negatives, and validation

Scan output contains errors in both directions, and confusing them is expensive:

• False positive: the scanner reports a vulnerability that is not actually present. Common causes include

banner-based detection of backported patches, version detection on customized builds, and signatures

that match a pattern without confirming exploitability. False positives waste remediation effort and erode

trust in the program.

• False negative: the scanner misses a vulnerability that is present. Common causes include hosts that were

offline during the scan, failed authentication, scan scope that excluded part of the network, and checks the

scanner does not have - a scanner only finds what it has signatures and logic for.

Scan finding example - CertCrack.com web server fleet

Host: web04.certcrack.internal (10.4.12.8)

Plugin: Web Server Outdated Version Detected

Reported version: 2.4.41 (banner) - flagged as vulnerable

Credentialed check: installed package 2.4.41-ubuntu2.3 (security fixes backported)

Analyst verdict: FALSE POSITIVE - banner-based detection, patch confirmed present

Action: document as false positive, tune plugin, verify with credentialed scan

Validation is how an analyst separates true findings from noise: rerun with credentials, manually confirm the

version or configuration, check whether the vulnerable component is actually reachable and loaded, and review

vendor advisories. A finding that survives validation moves to prioritization. A finding that does not is

documented as a false positive with evidence, not silently deleted - auditors and future analysts need to know

why it was dismissed.

2.3.3 Authenticated-scan gaps

A credentialed scan is only as good as its authentication success rate. Common gaps include expired or rotated

service account passwords, hosts that block the scanner's login attempts, Linux hosts where privilege escalation

to root fails, and cloud instances whose credentials were never provisioned. The analyst's job is to read the

scan's authentication report before reading its findings: which hosts authenticated successfully, which fell back

to unauthenticated checks, and which were not scanned at all. A "clean" report that authenticated to only half

the estate is a report about half the estate.

Reading a scan report, step by step

A findings table is not a to-do list in severity order. Work it this way:

1. Open the findings for one host and read every row, not just the top one.

2. Start with the Critical finding, but check its context before you act: is the host internet-facing, and is

exploit code available?

3. Remember that severity alone does not set priority: an exploited, internet-facing flaw outranks a higher

score with no exploit and no exposure.

4. Validate before you assign: confirm the finding is real and not a banner-based false positive.

5. Assign the validated findings in priority order and record the rest as accepted, false positive, or scheduled,

with a reason each.

GUI walkthrough: reading scan results in a scanner console (illustrated)

2.4 Prioritization and risk models

Once findings are validated, the hard question begins: what do we fix first? Organizations never have the

resources to fix everything at once, so prioritization is where vulnerability management earns its keep. The

exam tests several prioritization inputs, and the correct answer is almost always the one that combines them.

2.4.1 The prioritization inputs

Compensating controls Is something already reducing the risk? A control in place lowers effective priority

Compensating controls Is something already reducing the risk? A control in place lowers effective priority

Threat intelligence deserves special attention. A vulnerability with a published proof of concept is concerning; a

vulnerability that threat actors are actively exploiting against organizations like yours is urgent. Analysts track

exploitation through vendor advisories, threat intelligence feeds, and public catalogs of vulnerabilities known to

be exploited in the wild. When intelligence says a vulnerability is being exploited, its priority jumps regardless of

its CVSS score.

2.4.2 Remediation SLAs

A remediation SLA is a deadline: findings of a given severity or risk level must be fixed within a defined time. A

typical structure, which organizations adapt to their own risk appetite, looks like this:

Critical, exploited Days Emergency change, immediate mitigation

High Weeks Planned patch cycle, expedited

Medium One to two months Normal patch cycle

Low Next cycle or scheduled maintenance Bundled with other changes

SLAs turn prioritization into accountability. Without them, every finding is "planned" and nothing is urgent. With

them, overdue items are visible, exceptions are explicit, and management can see risk aging in real time. The

exam may ask what happens when an SLA is missed: the answer is escalation and a documented exception, not

silent acceptance.

2.4.3 Exceptions

Sometimes a vulnerability cannot be fixed within its SLA: the vendor has no patch, the patch breaks a critical

application, or the system cannot be taken offline. The correct response is not to ignore the finding. It is a formal

exception:

1. Document the vulnerability, the reason it cannot be remediated, and the risk it poses.

2. Apply a compensating control that reduces the risk in the meantime (see section 2.6).

3. Get approval from the risk owner - usually a business or system owner, not the security team alone.

4. Set an expiry date. Exceptions are time-bound. An exception with no expiry is a permanent acceptance

wearing a temporary label.

5. Review on expiry. Reassess: is a patch available now? Has the risk changed? Renew, remediate, or

escalate.

2.4.4 Zero-days

A zero-day vulnerability is one the vendor does not yet know about, or knows about but has not yet patched.

There is no patch to apply, so the remediation playbook changes: the goal becomes reducing exposure until a fix

exists.

Zero-day response typically includes virtual patching - blocking exploitation attempts at a web application

firewall or intrusion prevention system with a rule written for the attack pattern; disabling or restricting the

vulnerable feature or service; increasing monitoring on affected systems; and isolating exposed assets where

possible. Threat intelligence drives the response: which products are affected, what exploitation looks like, and

whether exploitation is observed in the wild.

2.5 Remediation workflows

Remediation is where findings become fixes, and the workflow matters as much as the fix itself. A mature

workflow looks like this:

1. Ticket and ownership. Every validated finding becomes a ticket assigned to the team that owns the asset

- not to the security team. Security tracks; owners fix.

2. Triage within the ticket. Confirm the finding, the affected asset, the SLA deadline, and any business

constraints such as change freezes.

3. Fix selection. Patch, upgrade, reconfigure, or replace. The right fix depends on the finding: a missing

patch gets patched, a misconfiguration gets corrected, an end-of-life product gets replaced.

4. Testing. Patches are tested in a non-production environment first, except in emergencies where the risk

of waiting exceeds the risk of an untested patch. Emergency patches still get a rollback plan.

5. Deployment. Apply through the change management process, in a maintenance window for

non-emergency fixes.

6. Verification. Rescan the asset and confirm the finding is gone. If it is not, reopen the ticket - do not close

it on the basis of a change record alone.

7. Closure and reporting. Close the ticket with evidence (the clean rescan), and feed the result into program

metrics: time to remediate, SLA compliance, and reopen rates.

Two workflow traps deserve attention. First, patching without testing can break production systems, which is

why emergency patching needs a rollback plan even when it skips full testing. Second, reopened findings -

vulnerabilities that return after being marked fixed - usually signal an incomplete fix, such as patching one host

in a cluster but not the others, or a configuration that reverts on the next deployment. A rising reopen rate

points to a process problem, not a scanner problem.

2.6 Controls, risk treatment, and compliance

Not every vulnerability is patched. Some are controlled, some are accepted, and some are transferred. This

section covers the decisions that surround remediation.

2.6.1 Compensating controls

A compensating control is an alternative safeguard put in place when the primary control is missing or cannot

be applied. It does not fix the vulnerability, but it reduces the risk to an acceptable level for a defined period.

Examples an analyst should recognize: a web application firewall rule blocking exploitation of an unpatched web

flaw; network segmentation that prevents an internet attacker from reaching a vulnerable internal service;

disabling a vulnerable protocol or feature; enhanced monitoring and alerting on the affected system; and

multi-factor authentication in front of a service with a known authentication weakness.

2.6.2 Risk treatment options

When a vulnerability is understood, the organization chooses one of four treatments:

• Mitigate. Reduce the risk, usually by patching, reconfiguring, or applying a compensating control. This is

the default treatment.

• Accept. Formally acknowledge the risk and continue operating, because the cost of fixing exceeds the risk,

or because the risk is genuinely low. Acceptance must be documented and approved - silent inaction is not

acceptance.

• Transfer. Shift some of the financial impact to another party, typically through cyber insurance or

contractual terms with a vendor. Transfer does not remove the vulnerability or the operational impact of an

incident; it shares the financial consequence.

• Avoid. Eliminate the risk by removing the cause - decommission the vulnerable system, stop using the

vulnerable service, or choose a different product. Avoidance is the right answer when a system is

end-of-life and the business no longer needs it.

2.6.3 Control types

Controls are classified two ways, and the exam tests both. By function:

2.6.4 Audit evidence

Vulnerability management is one of the most audited security functions, because it produces the evidence

auditors love: timestamped, repeatable, and quantitative. An auditor examining the program will typically ask

for:

• Scan reports showing scope, dates, and authentication coverage - not just findings.

• Remediation tickets showing ownership, deadlines, and closure evidence.

• Exception records with business justification, approval, expiry dates, and compensating controls.

• Rescan evidence proving findings were actually resolved.

• Policy documents defining scan frequency, SLAs, and roles.

• Trend reports showing whether the program is improving over time.

The analyst's habit that makes audits painless is documentation at the time of the decision, not reconstruction

afterward. A false positive dismissed without a note, an exception approved by email and never filed, or a rescan

never saved will all fail an audit even if the underlying security work was sound.

2.6.5 Disclosure policy

Disclosure policy governs how vulnerabilities are communicated - internally, to vendors, and to the public. Its

key elements:

• Internal disclosure. Findings are reported to asset owners through defined channels with defined severity

and timelines, not passed along informally. Internal disclosure rules protect sensitive detail: a scan report is

itself sensitive information, because it maps the organization's weaknesses.

• Vendor disclosure (coordinated disclosure). When an organization discovers a vulnerability in a vendor's

product, responsible practice is to notify the vendor privately and allow a reasonable period to develop a fix

before any public disclosure. Public disclosure before a fix exists puts other customers at risk.

• Public disclosure. After a fix is available, or after an agreed embargo period, details may be published so

other affected organizations can protect themselves. Disclosure timelines, embargoes, and the level of

technical detail are all policy decisions, not individual ones.

• Regulatory disclosure. Some sectors and jurisdictions require breach or vulnerability notification to

regulators within defined windows. The analyst should know that such obligations exist and escalate

promptly - the exact window depends on the regulation and the incident, and guessing at it in an exam

answer is worse than stating the principle: notify through proper channels without delay.

Chapter check

1. CertCrack.com's scanner reports a critical vulnerability on a server that the systems team patched last week. A

credentialed rescan shows the finding is gone. What most likely caused the original report?

A. A false negative in the credentialed scan

B. Banner-based detection by a non-credentialed scan

C. A zero-day vulnerability in the scanner

D. An expired remediation SLA

2. Which scan type is most appropriate for assessing a container image before it is deployed to production?

A. A network vulnerability scan of the production cluster

B. A container image scan in the deployment pipeline

C. A passive scan of the container registry's network traffic

D. A credentialed scan of the host operating system

3. A vulnerability has a CVSS base score of 9.8, but the affected system is isolated with no network path from

untrusted networks, and no exploit code is publicly available. A second vulnerability scores 6.5, affects an

internet-facing server, and is actively exploited in the wild. Under risk-based prioritization, which should be

addressed first?

A. The 9.8 vulnerability, because CVSS score always decides priority

B. The 6.5 vulnerability, because exposure and active exploitation raise its risk

C. Both equally, because they are in the same severity band

D. Neither until environmental scores are formally calculated

4. An organization cannot apply a vendor patch for a known vulnerability because the patch breaks a critical

business application. The security team documents the risk, gets the business owner's approval, applies a

firewall rule blocking the attack pattern, and sets a 90-day review date. What is this called?

A. Risk transfer

B. A formal exception with a compensating control

C. Risk avoidance

D. A false positive dismissal

5. Which of the following is the strongest evidence that a vulnerability has been remediated?

A. The change ticket marked "patch deployed"

B. The engineer's confirmation that the patch was applied

C. A rescan showing the finding is resolved

D. The passage of the remediation SLA window

6. A scan report shows no critical findings, but the authentication summary shows that only half of the hosts

accepted the scanner's credentials. What should the analyst conclude?

A. The environment is clean

B. The report covers only the authenticated portion of the estate and cannot support a clean verdict

C. The unauthenticated hosts are automatically secure

D. The scanner should be replaced

7. Active scanning is proposed for a factory's industrial control network. What is the most appropriate response?

A. Proceed with a credentialed scan at maximum intensity

B. Use passive monitoring and compensating controls instead of active scanning

C. Skip assessment of the OT network entirely

D. Run the scan during peak production hours to observe real traffic

8. A vulnerability with no available vendor patch is being exploited in the wild. Which action best reduces risk

immediately?

A. Wait for the vendor to release a patch

B. Deploy a virtual patch, such as a WAF or IPS rule blocking the exploit pattern, and increase monitoring

C. Remove the system from the asset inventory

D. Lower the vulnerability's CVSS score

Answer key: 1. B - 2. B - 3. B - 4. B - 5. C - 6. B - 7. B - 8. B

Analyst Toolkit: Scanning, Assessment, and Cloud Tools

Chapter 2 is about finding weaknesses before attackers do, and the official CS0-004 objectives name the tools by category: network scanning and mapping, multipurpose frameworks, web application scanners, vulnerability scanners, and cloud infrastructure assessment. This toolkit section walks each category in turn — what every tool does, when an analyst reaches for it instead of its neighbours, and what its results look like. Category by category, these are among the most reliably tested tool distinctions in the whole exam.

1. Network scanning and mapping

Before you can defend a network you must know what is on it. Scanning tools answer two different questions: what is alive and reachable? (discovery) and what exactly is it running? (enumeration). The two tools the objectives name for the first question are built for speed, not depth.

2. Multipurpose frameworks and reconnaissance

The objectives group four very different tools together as "multipurpose." What they share is breadth: each one supports many tasks inside a single framework. What separates them — and what the exam tests — is the kind of work: network enumeration, exploitation, or open-source intelligence (OSINT).

The sample below shows the style of Nmap output in simplified form. It is an illustrated example written for this book, not a capture of a real screen.

ILLUSTRATIVE EXAMPLE — simplified Nmap-style output (fictional data)
Host: 10.20.4.17  (ws-4417.certcrack.com) — status: up
PORT     STATE  SERVICE   VERSION
22/tcp   open   ssh       OpenSSH 9.3
80/tcp   open   http      Apache httpd 2.4.58
443/tcp  open   https     Apache httpd 2.4.58
3389/tcp closed ms-wbt-server  —
OS guess: Linux 5.x

3. Web application scanners

Web scanners test the layer the network scanners cannot see: the application itself — its pages, parameters, forms, and the server software underneath. The objectives name three, and they divide neatly into "the interactive tester," "the free automated scanner," and "the server misconfiguration checker."

4. Vulnerability scanners

A vulnerability scanner compares what it finds on systems against a database of known weaknesses and reports what is exposed. The objectives name the commercial standard, the open-source veteran, and the fast template-based newcomer — and the exam expects you to know which is which.

5. Cloud infrastructure assessment

Cloud environments fail differently from on-premises ones: most breaches trace back to misconfiguration — a public storage bucket, an over-privileged identity, an unencrypted snapshot. The objectives name four assessment tools, and telling them apart is one of the most-tested tool skills in CS0-004. Two audit a running cloud account from its APIs. One scans artefacts — container images and code — for flaws. One reads infrastructure-as-code before anything is deployed.

The sample below shows the style of a Trivy summary in simplified form. It is an illustrated example written for this book, not a capture of a real screen.

ILLUSTRATIVE EXAMPLE — simplified Trivy-style summary (fictional data)
Target: registry.certcrack.com/payments-api:2.4.1 (debian 12)
Vulnerabilities: Total 14 (CRITICAL 1, HIGH 4, MEDIUM 7, LOW 2)
Secrets:         Total 1 (an AWS-style access key found in a config file)
Misconfigurations: Total 2 (container runs as root; no read-only root fs)