16 Vulnerability Management · Security+

Exam objective 4.3: Given a scenario, perform tasks associated with vulnerability management. This objective covers the continuous process of finding, prioritizing, fixing, and confirming the fix for weaknesses in an organization's systems. The official objective divides the work into five activities: identification (scanning, IP address management, cloud security posture management, and source code review), prioritization (severity assessment and penetration test report review), remediation, verification, and reporting, both internal and external through bug bounty programs and responsible disclosure policies.

This is a "given a scenario, perform" objective. Expect questions that show you a scan result, a list of findings, or a description of an environment and ask what to do next: which vulnerability to fix first, why a finding is probably a false positive, what to do when a patch cannot be applied, or how to confirm that remediation worked. Chapter 4 introduced CVE and CVSS as concepts; this chapter applies them in day-to-day operations.

The Vulnerability Management Life Cycle

A vulnerability is a weakness that a threat can exploit: a software flaw, a misconfiguration, a missing patch, a weak default credential, or an insecure design. Vulnerability management is the ongoing program that reduces this exposure. It is not a one-time scan; new vulnerabilities are disclosed every day, systems change constantly, and an environment that was clean last month may be exposed today. The life cycle is continuous:

Stage Purpose Typical outputs
Identificati
on

Discover assets and the vulnerabilities on them Asset lists, scan results, CSPM findings, code review findings

Prioritizati

Decide what matters most given severity, exploitability, and business context

Ranked findings, risk ratings, remediation deadlines

Remediati

Fix, mitigate, or formally accept each vulnerability Patches applied, configurations changed, compensating controls, exceptions

Verificatio

Confirm that remediation worked and introduced no new problems

Rescan results, closed tickets

Reporting Communicate status, trends, and risk to stakeholders

Dashboards, metrics, executive reports, external disclosures

Figure 16.1: The vulnerability management life cycle runs continuously, with failed verification sending a finding back to remediation

Memory aid

The five activities in order: Identify, Prioritize, Remediate, Verify, Report — "I Prefer Really Verified Results."

Vulnerability management depends on asset management (Chapter 15): you cannot scan or patch systems you do not know exist. It feeds risk management (Chapter 23), because unremediated vulnerabilities are risks that must be treated, and it relies on change management (Chapter 2) to apply fixes safely.

Identification

Identification answers two questions: what assets do we have, and what weaknesses do they have?

Scanning

A vulnerability scanner probes systems and compares what it finds—operating system versions, installed software, open ports, service banners, configuration settings—against a database of known vulnerabilities, typically identified by CVE (Common Vulnerabilities and Exposures) numbers. Scanners also check for misconfigurations and compliance with configuration benchmarks.

Scans vary along several dimensions that the exam expects you to know:

Credentialed vs. non-credentialed. A non-credentialed (unauthenticated) scan sees the system as an outside attacker would: open ports, service banners, and responses to probes. It is faster and shows external exposure, but it misses vulnerabilities in software that is not network-facing and often guesses versions from banners, which produces false positives and false negatives. A credentialed (authenticated) scan logs in to the target, using a dedicated scanning account, and reads installed packages, patch levels, registry settings, and configuration files directly. Credentialed scans are far more accurate and complete. The scanning account should have only the privileges required, its credentials should be protected, and its use should be monitored.

Agent-based vs. agentless. Agent-based scanning uses software installed on each host that reports vulnerabilities to a central server. Agents work well for laptops that are rarely on the corporate network and reduce network load. Agentless scanning runs from a central scanner over the network and requires no software on targets, which suits network devices, appliances, and systems where agents cannot be installed.

Internal vs. external. Internal scans run from inside the network and find vulnerabilities an insider or an attacker who has gained a foothold could exploit. External scans run from the internet and show what is exposed to everyone. PCI DSS, for example, requires quarterly external scans by an Approved Scanning Vendor (ASV) as well as internal scans.

Intrusive vs. non-intrusive. Non-intrusive scans identify vulnerabilities without trying to exploit them. Intrusive scans attempt exploitation or send potentially disruptive probes and can crash fragile systems. Scans of production systems, and especially of industrial control systems and medical devices, must be planned carefully, scheduled in maintenance windows where needed, and approved through change management.

Scan type Advantages Disadvantages
Non-credentiale
d

Shows attacker's external view; no credentials to manage

Less accurate; misses local vulnerabilities; more false positives

Credential

Accurate, detailed, sees installed software and settings

Requires protected service account; more setup

Agent-basedCovers remote and intermittently connected endpoints; low network load

Agent must be deployed and maintained; not for appliances

Agentless Nothing to install; covers network devices Needs network reachability and often credentials External Shows internet-facing exposure Limited view of internal weaknesses Internal Shows exposure to insiders and lateral movement Does not reflect internet attacker's view

Figure 16.2: External, internal, credentialed, non-credentialed, agent-based, and agentless scans each see a different part of the environment

Other scanning approaches include web application scanners (dynamic application security testing, or DAST) that crawl a running application and test for injection, XSS, and authentication flaws; container and image scanners that check images in registries and CI/CD pipelines for vulnerable packages; and software composition analysis (SCA) that identifies vulnerable open-source libraries in an application's dependencies. Scanners also perform configuration compliance checks against benchmarks such as the CIS Benchmarks, often using SCAP content (Chapter 17).

A typical scanner finding looks like this:
Plugin ID: 187654
Name: OpenSSH < 9.8p1 Remote Code Execution (regreSSHion)
Host: 10.20.40.12 (web-prod-02) Port: tcp/22
Severity: Critical CVSS v3.1 Base: 8.1

Cve: cve-2024-6387

Evidence: Remote SSH banner: SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2

Solution: Upgrade to OpenSSH 9.8p1 or later, or apply vendor backported patch.

Exploit available: Yes (public PoC)

Understanding Scan Results: False Positives and False Negatives

Scanners are not perfect, and interpreting their output is a core skill.

A false positive is a reported vulnerability that does not actually exist. A frequent cause is version-based detection on a backported patch: Linux distributions often fix a vulnerability by patching an older version number rather than upgrading, so a non-credentialed scanner that sees the old version in a banner reports a flaw that has already been fixed. In the sample above, the Debian package version shown in the banner would need to be checked against the distribution's security advisory before concluding the host is vulnerable.
A false negative is a real vulnerability the scanner did not report—perhaps because the scan was non-credentialed, a host was offline, a firewall blocked probes, or the scanner's plugin database was out of date. False negatives are more dangerous because they create false confidence.
A true positive is a correctly reported vulnerability; a true negative is a correct "no vulnerability" result.

Ways to reduce errors include running credentialed scans, keeping the scanner's feed updated, correlating findings with other data (patch management records, EDR inventory, configuration management), and manually validating high-severity findings. When an analyst confirms a false positive, it should be documented and suppressed for that asset rather than simply ignored.

Exam tip

If a scenario says a scan reports a vulnerability that the administrator insists was patched, and the scan was non-credentialed or based on a banner, suspect a false positive. The best next step is usually to validate it—run a credentialed scan or check the installed package version—not to ignore it and not to immediately reinstall the patch.

IP Address Management (IPAM)

IP address management (IPAM) is the practice and tooling for planning, tracking, and managing an organization's IP address space, usually integrated with DHCP and DNS. IPAM records which subnets exist, which addresses are allocated or leased, to which device (by MAC address and hostname), and when.

IPAM supports vulnerability identification in several ways:

Defining scan scope. IPAM is the authoritative list of subnets and ranges. A scanner configured from IPAM data does not miss a new subnet that someone added last month.
Discovering unknown devices. DHCP leases and DNS records reveal devices that are not in the asset inventory and have never been scanned.
Mapping findings to owners. A vulnerability reported at 10.20.40.12 is only actionable if someone can determine what that address is and who owns it, which IPAM and the CMDB provide.
Handling dynamic addresses. Because DHCP addresses change, IPAM history helps correlate scan results taken at different times to the right device.

A network team creates a new subnet for a lab project but does not tell the security team. For six months, quarterly vulnerability scans skip it because the scan configuration lists subnets manually. When the security team integrates the scanner's targets with the IPAM system, the next scan automatically includes the lab subnet and finds three servers with critical, internet-exploitable vulnerabilities and default credentials.

Cloud Security Posture Management (CSPM)

Cloud security posture management (CSPM) tools continuously assess cloud environments (IaaS and PaaS) for misconfigurations and compliance violations by querying the cloud providers' APIs. Misconfiguration, rather than software flaws, is the leading cause of cloud breaches, and traditional network scanners do not see it.

CSPM tools typically detect:

Publicly accessible storage buckets and databases
Security groups allowing inbound access from anywhere (0.0.0.0/0) to SSH, RDP, or database ports
Missing encryption at rest or in transit
Logging (such as cloud audit trails) disabled
Overly permissive identity and access management (IAM) policies, unused credentials, and root accounts without MFA
Resources deployed in unapproved regions
Deviation from frameworks and benchmarks such as the CIS cloud foundations benchmarks CSPM provides continuous visibility across multiple accounts and providers, maps findings to compliance frameworks, and often offers automated remediation (for example, automatically removing public access from a bucket). CSPM is part of a broader category sometimes called a cloud-native application protection platform (CNAPP), which also includes workload protection and infrastructure-as-code scanning.

[CRITICAL] Storage bucket "acme-hr-exports" allows public read access
Account: prod-hr (123456789012) Region: us-east-1
Framework mapping: CIS Foundations 2.1.x, PCI DSS 7.2
Remediation: Enable "block public access" at account and bucket level
[HIGH] Security group sg-0a1b2c allows 0.0.0.0/0 on tcp/3389
[MEDIUM] Cloud audit logging not enabled in region eu-west-1
Source Code Review

Source code review identifies vulnerabilities in applications the organization develops before (or after) they reach production. It includes:

Static application security testing (SAST), automated tools that analyze source code for insecure patterns such as unsanitized input flowing into SQL queries, hard-coded secrets, and weak cryptography (Chapter 14).
Manual code review, in which experienced reviewers—often peers in a pull request process— examine code for logic flaws, authorization mistakes, and business-logic issues that tools cannot understand.
Software composition analysis (SCA) of third-party and open-source dependencies, often compared against an SBOM.
Secrets scanning of repositories for leaked credentials.

Source code review finds vulnerabilities at the cheapest point to fix them: before deployment. Integrating SAST and SCA into the CI/CD pipeline (Chapter 19) can block builds that introduce critical issues. Code review complements dynamic testing, which finds runtime and configuration issues that static review cannot see.

Other Identification Sources

Beyond the four named methods, vulnerabilities are identified through threat intelligence feeds and vendor advisories (for example, a vendor's security bulletin or a government agency's known-exploited vulnerabilities list), penetration tests, bug bounty and responsible disclosure reports, audits, and system and application logs. Chapter 4 covers these intelligence sources.

Prioritization

A large organization's scans can produce tens of thousands of findings. No team can fix everything at once, so prioritization decides what to fix first. Good prioritization focuses limited effort on the vulnerabilities most likely to be exploited and most damaging if they are.

Severity Assessment

Severity assessment determines how serious a vulnerability is. The starting point is usually the Common Vulnerability Scoring System (CVSS), which rates vulnerabilities from 0.0 to 10.0:

CVSS score Qualitative rating

0.0 None

0.1-3.9 Low
4.0-6.9 Medium
7.0-8.9 High
9.0-10.0 Critical

The CVSS base score reflects intrinsic characteristics: attack vector (network, adjacent, local, physical), attack complexity, privileges required, user interaction, and impact on confidentiality, integrity, and availability. A remotely exploitable flaw requiring no privileges or user interaction that leads to full compromise scores near 10. CVSS also includes threat (temporal) metrics, such as whether exploit code exists, and environmental metrics that let an organization adjust the score for its own context. A typical CVSS v3.1 vector string looks like this:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H -> Base score 9.8 (Critical)

CVSS alone is not enough. Effective severity assessment also considers:

Exploitability and threat activity. Is there a public exploit? Is the vulnerability being exploited in the wild? Lists of known exploited vulnerabilities (such as CISA's KEV catalog) and probability models such as the Exploit Prediction Scoring System (EPSS) help identify vulnerabilities that attackers are actually using. A CVSS 7.5 vulnerability under active exploitation can be more urgent than an unexploited 9.8.
Exposure. An internet-facing system is at far greater risk than one on an isolated internal segment.
Asset criticality and data sensitivity. A vulnerability on the payment database matters more than the same vulnerability on a test server. Asset classification from the inventory (Chapter 15) feeds directly into this.
Existing compensating controls. A WAF rule, segmentation, or disabled vulnerable feature may reduce the real risk.
Regulatory and contractual requirements. Some frameworks set remediation deadlines by severity.

Many organizations combine these factors into a risk-based priority and set remediation timelines, such as critical within 7 days, high within 30 days, medium within 90 days, and low at the next scheduled maintenance.

Real-world scenario

A scan reports two findings. One is a CVSS 9.8 remote code execution flaw on a development server on an isolated lab VLAN with no internet access and no sensitive data. The other is a CVSS 7.5 authentication bypass on the internet-facing customer portal, listed in the known exploited vulnerabilities catalog. The analyst prioritizes the customer portal: it is exposed, actively exploited, and protects sensitive data. The lab server is scheduled for remediation within its normal window.

Figure 16.3: Exposure, active exploitation, and data sensitivity can make a lower CVSS finding the first one to remediate

Exam tip

When a question asks which vulnerability to remediate FIRST, weigh severity together with exposure (internet-facing), active exploitation, and asset criticality. The highest CVSS number is not automatically the right answer if another finding is exposed and actively exploited.

Penetration Test Report Review

A penetration test simulates a real attack to show how vulnerabilities can actually be exploited, often by chaining several individually moderate issues into a serious compromise. The resulting report is a critical prioritization input. Chapter 26 covers penetration testing types and rules of engagement; here the focus is on using the report.

A penetration test report typically includes:

An executive summary describing overall risk in business terms.
The scope, methodology, and rules of engagement used.
Findings, each with a description, severity rating, affected assets, evidence (screenshots, commands, captured data), and an explanation of business impact.
Attack narratives showing how findings were chained—for example, a phishing foothold, then a misconfigured service, then credential reuse, leading to domain administrator.
Remediation recommendations for each finding.

When reviewing the report, the security team should:

Validate findings and confirm affected assets against the inventory.
Pay special attention to attack chains. Fixing one key link (such as credential reuse) may break several paths at once and deserves high priority even if each individual finding was rated medium.
Compare against scanner results. Findings the scanners missed reveal blind spots, such as logic flaws or misconfigurations, that should improve future identification.
Assign owners and deadlines, enter findings into the ticketing or vulnerability management system, and plan a retest to verify fixes.
Protect the report. It is a roadmap to the organization's weaknesses and should be classified and distributed on a need-to-know basis.

Note

Vulnerability scans identify potential weaknesses broadly and frequently; penetration tests demonstrate actual exploitability deeply but occasionally. They complement each other, and the exam may ask which is appropriate. "Confirm whether vulnerabilities can be exploited" points to a penetration test.

Remediation

Remediation is the action taken to address a vulnerability. Strictly speaking, remediation means eliminating it, but in practice organizations choose among several responses.

Patching

Patching applies vendor-supplied fixes and is the most common remediation. A sound patch management process includes:

Monitoring vendor advisories and receiving patches promptly.
Testing patches in a non-production environment to catch compatibility problems.
Deploying through change management (Chapter 2), with maintenance windows and backout plans.
Using automated patch deployment tools for operating systems and common applications.
Handling emergency, out-of-band patches for actively exploited critical vulnerabilities through an expedited change process.
Patching firmware, hypervisors, network devices, and third-party applications, not just operating systems.

Configuration Changes

Many vulnerabilities are misconfigurations rather than code flaws: default credentials, weak cipher suites, unnecessary services, public cloud buckets, or excessive permissions. These are remediated by changing the configuration, ideally by updating the secure baseline so that the misconfiguration does not reappear on new systems.

Upgrading or Replacing

When software is end of life and no longer receives patches, the remediation is to upgrade to a supported version or replace the system. Until that is possible, compensating controls are required.

Compensating Controls

A compensating control reduces risk when the primary fix cannot be applied—for example, when a vendor has not released a patch, a patch breaks a critical application, or a legacy system cannot be updated. Examples include:

Segmentation or isolation of the vulnerable system (Chapter 14)
Virtual patching with a WAF or IPS signature that blocks exploitation
Disabling the vulnerable feature or service
Restricting access to the vulnerable system to specific hosts
Increased monitoring for exploitation attempts

Compensating controls reduce the likelihood or impact of exploitation but do not eliminate the vulnerability, so the finding should remain tracked.

Exceptions and Risk Acceptance

Sometimes the business decides not to remediate a vulnerability, at least for a time, because the cost or operational impact of fixing it outweighs the risk. In that case, the organization grants a formal exception (or exemption). A proper exception:

Is requested and justified in writing, describing the vulnerability, the reason it cannot be fixed, and any compensating controls.
Is approved by the appropriate risk owner (the asset owner or management with authority to accept risk), not by the technician who would have to apply the patch.
Is time-limited, with an expiration date and a scheduled review.
Is recorded in the risk register (Chapter 23).

Ignoring a finding is not the same as accepting the risk. Risk acceptance is a documented decision by someone with authority, with a review date. A vulnerability that is simply left open with no record is an unmanaged risk and a common audit finding.

Insurance and Transfer

Some residual risk can be transferred, for example through cybersecurity insurance, which may cover costs from an incident. Insurance does not remediate vulnerabilities, and insurers increasingly require evidence of effective vulnerability management (such as patching timelines and MFA) as a condition of coverage.

Response When used Effect on vulnerability
Patch or update Fix is available and tested Eliminated
Configuration change Misconfiguration or insecure default Eliminated
Upgrade or replace End-of-life software or hardware Eliminated

Compensating control Fix not available or not yet possible Remains, but risk reduced Exception (accept) Fix too costly or disruptive; risk within appetite Remains; documented and time-limited Transfer (insurance) Residual financial impact Remains; financial impact shared Verification

Verification (also called validation of remediation) confirms that the remediation actually worked. Closing a ticket because someone says a patch was installed is not verification. Patches fail to install, require a reboot that never happened, are applied to the wrong host, or are rolled back after causing problems.

Verification methods include:

Rescanning the affected assets with the same (preferably credentialed) scan that found the vulnerability, and confirming that the finding no longer appears.
Retesting penetration test findings, often by the original testers, to confirm that the exploit no longer works.
Audits and configuration checks confirming that settings match the secure baseline.
Reviewing patch management and EDR inventory data to confirm the installed version across all affected systems.

Verification should also confirm that remediation did not create new problems, such as broken functionality or new vulnerabilities introduced by an upgrade, and that the fix covers all affected assets, not just the one that was tested. When verification confirms the fix, the ticket is closed and metrics are updated; when it fails, the finding returns to remediation.

Ticket VULN-4821 CVE-2024-6387 host web-prod-02
2026-09-14 Detected (credentialed scan) Severity: Critical
2026-09-16 Patch applied via change CHG-11873

2026-09-16 Rescan: openssh-server 1:9.2p1-2+deb12u3 (fixed version) Finding not present

2026-09-16 Status: Verified / Closed Time to remediate: 2 days

Exam tip

If a question asks what to do after applying a patch or other remediation, the answer is to verify: rescan or retest. If it asks how to confirm a suspected false positive before remediation, the answer is to validate the finding, often with a credentialed scan or manual check.

Reporting

Vulnerability management produces information that different audiences need in different forms. Reporting communicates status, progress, and risk, and supports accountability.

Internal Reporting

Internal reporting goes to people within the organization:

Technical teams and system owners need detailed, actionable findings for their assets: hosts, CVEs, evidence, solutions, and deadlines, usually through tickets or a vulnerability management platform.
Security management needs operational metrics and trends to manage the program.
Executives and the board need concise, business-oriented summaries of risk, trends, and compliance, not lists of CVEs.
Auditors and compliance teams need evidence that scanning occurs at the required frequency and that findings are remediated within policy timelines.

Common vulnerability management metrics include:
Metric What it shows
Number of open vulnerabilities by severity Current exposure
Mean time to remediate (MTTR) How quickly findings are fixed
Percentage remediated within SLA Adherence to policy deadlines

Scan coverage (percentage of assets scanned) Whether identification is complete Metric What it shows

Recurring vulnerabilities Weak baselines or processes that reintroduce issues Exceptions open and expiring Accepted risk and its review status

Trend over time Whether the program is improving

Dashboards in vulnerability management platforms and SIEMs (Chapter 17) present these metrics in real time.

External Reporting

External reporting covers vulnerability information exchanged with parties outside the organization. Organizations both receive reports from outside researchers and may report vulnerabilities they discover in others' products. Objective 4.3 names two mechanisms.

Responsible Disclosure Policies

A responsible disclosure policy (increasingly called a coordinated vulnerability disclosure policy, or a vulnerability disclosure policy, VDP) tells outside security researchers how to report vulnerabilities they find in the organization's products or systems, and what to expect in return. A good policy includes:

How to report: a dedicated email address or web form (and often a security.txt file at /.well-known/security.txt on the organization's website pointing to it), with an encryption key for sensitive reports.
Scope: which systems and products are covered, and which testing activities are permitted or prohibited (for example, no denial of service, no social engineering, no accessing other users' data).
Safe harbor: a commitment not to pursue legal action against researchers who act in good faith and within the policy.
Response expectations: acknowledgment timelines, communication during remediation, and coordination on public disclosure timing.
Disclosure timeline: researchers agree to give the organization reasonable time (commonly around 90 days) to fix the issue before publishing details.

# https://www.example.com/.well-known/security.txt
Contact: mailto:security@example.com
Encryption: https://www.example.com/pgp-key.txt
Policy: https://www.example.com/vulnerability-disclosure
Acknowledgments: https://www.example.com/security/hall-of-fame
Expires: 2027-10-01T00:00:00.000Z

The responsible or coordinated model sits between two extremes: full disclosure, in which a researcher publishes details immediately, which pressures vendors but exposes users before a fix exists; and non-disclosure, in which the vulnerability is never made public, which can leave users unaware of risk. In coordinated disclosure, the researcher notifies the vendor privately, the vendor develops a fix, and details are published once users can protect themselves, typically with a CVE identifier and credit to the researcher. Chapter 22 covers the vulnerability disclosure policy as a governance document.

Bug Bounty Programs

A bug bounty program goes further by offering rewards—usually money, sometimes recognition or merchandise—to outside researchers who report qualifying vulnerabilities. Rewards typically scale with severity. Bounty programs are often run through third-party platforms that manage researcher identity, triage, and payment, and they may be public (open to anyone) or private (invitation-only, often a starting point).

Benefits include access to a large, diverse pool of testers, continuous testing rather than periodic assessment, and paying only for results. Challenges include handling a high volume of low-quality or duplicate submissions, the need for a mature internal process to triage and fix reports quickly, and clearly defining scope so that researchers do not test systems they should not. A bug bounty does not replace internal vulnerability management or penetration testing; it supplements them. Feature Responsible disclosure policy (VDP) Bug bounty program

Purpose Provide a safe channel to report vulnerabilities

Actively incentivize researchers to find vulnerabilities

Rewards Usually none (thanks, recognition) Monetary rewards scaled by severity Researcher participation

Anyone who happens to find an issue Researchers actively hunting, often via a platform Safe harbor and scope

Yes Yes, with detailed scope and rules

Maturity required

Basic intake and response process Strong triage and remediation capacity

Real-world scenario

A researcher discovers that a retailer's mobile app exposes other customers' order histories through an API. The retailer has no disclosure policy or contact address, so the researcher's emails go to customer support and are ignored, and frustrated, the researcher posts details publicly. Had the retailer published a security.txt file and a coordinated disclosure policy with safe harbor, the report would have reached the security team privately and the flaw could have been fixed before attackers learned of it.

Other External Reporting

External reporting can also include notifying regulators or customers when a vulnerability has been exploited (Chapter 20), sharing vulnerability information with industry peers through information sharing and analysis centers (ISACs), reporting vulnerabilities to third-party vendors whose products the organization uses, and requesting a CVE identifier for a newly discovered flaw through a CVE Numbering Authority (CNA).

Putting It Together: A Vulnerability Management Scenario

Consider how the activities connect for a mid-size company:

1. Identification: IPAM supplies current subnets to the scanner; weekly credentialed scans cover servers and agents cover laptops; CSPM monitors three cloud accounts; SAST runs on every pull request.
2. Prioritization: findings are scored by CVSS, adjusted for known exploitation, internet exposure, and asset criticality from the CMDB. The annual penetration test report adds a credential-reuse chain that is prioritized as high.
3. Remediation: patches are deployed through change management; a vulnerable legacy application gets a WAF virtual patch and an exception approved by its business owner for 90 days.
4. Verification: affected hosts are rescanned within 24 hours of patching; penetration testers retest the credential-reuse chain.
5. Reporting: system owners receive weekly ticket queues; the CISO reviews MTTR and SLA compliance monthly; the board receives a quarterly risk summary; the public VDP and private bug bounty bring in external reports, which flow back into identification.

Chapter Summary

Vulnerability management is a continuous cycle: identify, prioritize, remediate, verify, and report. It depends on accurate asset inventories.
Identification uses scanning (credentialed vs. non-credentialed, agent vs. agentless, internal vs. external, intrusive vs. non-intrusive), IPAM to define and complete scan scope and map addresses to devices, CSPM to find cloud misconfigurations through provider APIs, and source code review (SAST, manual review, SCA, secrets scanning).
Validate findings to manage false positives (often backported patches detected by version banners) and reduce false negatives (missed vulnerabilities, often from non-credentialed scans).
Prioritization uses severity assessment (CVSS plus exploitability, known exploitation, exposure, asset criticality, and compensating controls) and penetration test report review (validating findings, focusing on attack chains, assigning owners, and planning retests).
Remediation options include patching, configuration changes, upgrading or replacing, compensating controls, formal time-limited exceptions approved by the risk owner, and transfer through insurance.
Verification confirms fixes through rescanning, retesting, and configuration checks.
Reporting is internal (technical tickets, metrics such as MTTR and SLA compliance, executive summaries) and external through responsible (coordinated) disclosure policies with safe harbor and bug bounty programs that reward researchers.

Key Terms

Vulnerability; vulnerability management; identification; vulnerability scanner; CVE; credentialed scan; non-credentialed scan; agent-based scan; agentless scan; internal scan; external scan; intrusive scan; non-intrusive scan; DAST; container scanning; software composition analysis (SCA); configuration compliance scan; false positive; false negative; true positive; true negative; backported patch; IP address management (IPAM); cloud security posture management (CSPM); CNAPP; source code review; SAST; manual code review; prioritization; severity assessment; CVSS; base score; vector string; known exploited vulnerabilities (KEV); EPSS; asset criticality; penetration test report; attack chain; retest; remediation; patch management; compensating control; virtual patching; exception; risk acceptance; risk owner; cybersecurity insurance; verification; rescan; reporting; mean time to remediate (MTTR); scan coverage; responsible disclosure; coordinated vulnerability disclosure; vulnerability disclosure policy (VDP); security.txt; safe harbor; full disclosure; bug bounty program; CVE Numbering Authority (CNA).

Review Questions

1. A non-credentialed scan reports that a Linux web server is vulnerable to a critical OpenSSH flaw based on the version in the SSH banner. The administrator says the distribution's security update was installed last week. What should the analyst do NEXT?

A. Close the finding as a false positive based on the administrator's statement
B. Immediately rebuild the server from scratch
C. Validate the finding with a credentialed scan or by checking the installed package version against the vendor advisory
D. Raise the finding's severity because the administrator disputed it

2. A security team wants vulnerability scans to automatically include every subnet in use, including new ones created by the network team, and to map scan findings to the correct device even though addresses are assigned by DHCP. Which tool BEST supports this?

A. CSPM
B. IPAM
C. SAST
D. WAF

3. An organization runs workloads in three public cloud accounts and is concerned about publicly exposed storage, overly permissive security groups, and disabled audit logging. Which solution is MOST appropriate for continuously identifying these issues?

A. Agentless network vulnerability scanner
B. Cloud security posture management
C. Bug bounty program
D. Static code analysis

4. A vulnerability scan produces the following findings. Which should be remediated FIRST?

A. CVSS 9.8 on an isolated lab server with no sensitive data
B. CVSS 7.5 on an internet-facing customer portal, listed as actively exploited
C. CVSS 5.3 information disclosure on an internal print server
D. CVSS 6.1 XSS on an internal wiki behind SSO

5. A critical vulnerability affects a manufacturing control application, but the vendor states that the patch will not be available for 60 days. Which actions are MOST appropriate in the meantime? (Select TWO.)

A. Isolate the system on a restricted network segment
B. Mark the finding as a false positive
C. Apply an IPS signature or other virtual patch to block exploitation
D. Remove the system from the asset inventory
E. Disable vulnerability scanning on the system

6. A system administrator applied patches for all critical findings on a group of servers and asks the security team to close the tickets. What should the security team do before closing them?

A. Accept the administrator's confirmation and close the tickets
B. Rescan the servers to verify the vulnerabilities are no longer present
C. Request a new penetration test of the entire organization
D. Grant an exception for each finding

7. A business unit cannot patch a vulnerable application for six months because the patch breaks a critical integration. The vulnerability is rated medium, and a WAF rule reduces exposure. What is the CORRECT way to handle this?

A. The system administrator documents the decision in a personal notes file
B. The finding is suppressed in the scanner indefinitely
C. The application owner approves a documented, time-limited exception recorded in the risk register
D. The security team ignores the finding until the next annual audit

8. A penetration test report rates three findings as medium individually, but the attack narrative shows that the testers chained them to obtain domain administrator privileges. How should the security team prioritize these findings?

A. Treat them as medium and remediate on the normal schedule
B. Prioritize them highly, focusing on the link that breaks the chain
C. Ignore them because no single finding is critical
D. Wait for the vulnerability scanner to confirm them before acting

9. Which scan type would provide the MOST accurate and complete view of missing patches and insecure local configurations on Windows servers?

A. External non-credentialed scan
B. Internal non-credentialed scan
C. Credentialed scan
D. Intrusive web application scan

10. A software company wants outside researchers to have a safe, documented way to report vulnerabilities, with a commitment not to take legal action against good-faith research, but it is not ready to pay rewards. What should it publish?

A. A bug bounty program
B. A responsible (coordinated) vulnerability disclosure policy
C. A full-disclosure mailing list
D. A penetration test report

11. The CISO asks for a monthly metric showing how quickly the organization fixes vulnerabilities and whether teams are meeting policy deadlines. Which metrics BEST meet this need? (Select TWO.)

A. Mean time to remediate
B. Percentage of findings remediated within SLA
C. Number of firewall rules
D. Number of DMARC reports received
E. Number of honeypots deployed

12. A development team wants to find SQL injection flaws and hard-coded credentials in its application before the code is deployed. Which identification method is MOST appropriate?

A. External vulnerability scan of production
B. Source code review with static analysis and secrets scanning in the CI pipeline
C. CSPM
D. IPAM

Answers and Explanations

1. C. Banner-based detection by a non-credentialed scan commonly misreports Linux packages that received backported fixes, so this could be a false positive—but it must be validated, not assumed. A credentialed scan or a check of the installed package version against the vendor's advisory confirms the truth. Closing the finding on the administrator's word skips validation, rebuilding the server is unnecessary, and the dispute does not change severity.
2. B. IPAM is the authoritative record of subnets and address assignments, integrated with DHCP and DNS, so it can define complete scan scope and map dynamic addresses to devices. CSPM assesses cloud configuration, SAST analyzes code, and a WAF protects web applications.
3. B. CSPM continuously queries cloud provider APIs for misconfigurations such as public storage, permissive security groups, and disabled logging, across multiple accounts. A network scanner does not see cloud control-plane configuration. A bug bounty relies on outside researchers, and static analysis examines source code.
4. B. Although the lab server has a higher CVSS score, the customer portal is internet-facing, protects sensitive data, and the vulnerability is actively exploited, making it the most likely and most damaging target. The lab server is isolated with no sensitive data. The other two findings are lower severity on internal systems.
5. A, C. When a patch is unavailable, compensating controls reduce risk: isolating the system limits who can reach it, and virtual patching with an IPS or WAF signature blocks known exploit attempts. The finding is real, so it is not a false positive. Removing the system from inventory or disabling scanning hides the risk rather than managing it.
6. B. Verification requires confirming that the vulnerabilities are actually gone, typically by rescanning with the same scan that found them. Patches can fail or require reboots. A full penetration test is excessive for this purpose, and exceptions are for vulnerabilities that will not be remediated.
7. C. A formal exception must be approved by the risk owner (the application or business owner), documented with justification and compensating controls, time-limited, and recorded in the risk register. A personal notes file, indefinite suppression, and ignoring the finding are not risk acceptance and leave the risk unmanaged.
8. B. Attack chains show real-world exploitability: together the findings lead to complete domain compromise, so they warrant high priority regardless of individual ratings. Breaking a key link in the chain can stop the whole attack path. Treating them as routine or ignoring them misses the demonstrated impact, and waiting for a scanner ignores the fact that the testers already proved exploitation.
9. C. A credentialed scan logs in to the systems and reads installed patches, software versions, and configuration settings directly, giving the most accurate and complete results. Non-credentialed scans, internal or external, see only what is exposed over the network. A web application scan tests web applications, not operating system patches.
10. B. A responsible or coordinated vulnerability disclosure policy provides a reporting channel, scope, and safe harbor without requiring payment. A bug bounty pays rewards. Full disclosure means publishing details publicly before a fix, which the company does not want, and a penetration test report is an internal assessment document.
11. A, B. Mean time to remediate shows how quickly vulnerabilities are fixed, and the percentage remediated within SLA shows whether teams meet policy deadlines. The number of firewall rules, DMARC reports, and honeypots do not measure remediation performance.
12. B. Source code review, including static analysis (SAST) for injection flaws and secrets scanning for hard-coded credentials, finds these issues before deployment, ideally automatically in the CI pipeline. A production scan happens after deployment, and CSPM and IPAM do not analyze application code.