Objective 4.3: Explain various activities associated with vulnerability management

Cert: CompTIA Security+ (SY0-701) Domain: 4.0 Security Operations Weight: ~28% of SY0-701 (Domain 4 total) Depth: Explain. Be able to walk the vulnerability management lifecycle, name the identification methods, score with CVSS, choose a remediation path, and describe validation and reporting in plain English.

What this objective tests

You should be able to read a vulnerability scanner finding, a CVE disclosure, or a CISA KEV alert and place it in the operational lifecycle. Name the right identification method for a scenario. Confirm the finding. Score and prioritize it. Pick the right remediation path. Validate the fix. Report the result to leadership. This is one of the most operational objectives on the exam. Every "Given a scenario" question in Domain 4 wants the right vocabulary, the right phase of the lifecycle, and the right SY0-701 term for the activity.

Key facts

The vulnerability management lifecycle

SY0-701 organizes the activities into four phases. Memorize the phases first, then the activities inside each.

Most enterprise programs run all four phases as a continuous loop with weekly or daily cycles, not quarterly cycles.

Identification methods

Eight identification methods are named on the exam. Know one situation where each fits.

• Vulnerability scan. Automated tool (Nessus, Qualys, Rapid7 InsightVM, OpenVAS) that probes systems for known weaknesses. Authenticated scans log in and see what is installed. Unauthenticated scans probe from outside and see what an attacker would see. Most programs run both.
• Application security testing. SAST (Static Application Security Testing) analyzes source code at rest and catches vulnerabilities pre-deploy. DAST (Dynamic Application Security Testing) probes a running application and catches runtime vulnerabilities. Both belong in a CI/CD pipeline.
• Package monitoring. Watches the third-party libraries an application pulls in (npm, PyPI, Maven, NuGet) and fires when a library gets a new CVE. The 2021 Log4Shell event made this category visible to every executive. SBOM (Software Bill of Materials) is the inventory it runs against.
• Threat feed. A subscription stream of vulnerability and threat intelligence. Sources include OSINT (Open Source Intelligence from CISA, vendor blogs, NVD), proprietary feeds (paid products from Mandiant or Recorded Future), third-party feeds (community sources), information-sharing groups (ISACs by sector, like MS-ISAC for state and local government, H-ISAC for healthcare), and dark web monitoring (paid services watching criminal forums).
• Penetration testing. Ethical hackers attack the environment under controlled rules of engagement. Pen tests find what scanners miss. Run annually or after major architecture changes. NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) is the public reference for methodology.
• Responsible disclosure. A security researcher reports a vulnerability to the vendor privately before going public, giving the vendor time to ship a patch. The Google Project Zero 90-day disclosure window is the well-known example.
• Bug bounty. A company pays researchers for vulnerabilities they report through a managed program (HackerOne, Bugcrowd, vendor programs like Microsoft's). Bounty payouts scale with severity, typically a few hundred dollars for medium findings to six figures for critical findings on major platforms.
• System and process audit. A structured review of systems or processes against a standard, often by an outside auditor. Standards include NIST 800-53, CIS Critical Security Controls, ISO 27001 Annex A, and sector-specific frameworks like HITRUST for healthcare. Audits surface vulnerabilities that scanners and pen tests miss because they look at process gaps, not just technical flaws.

Analysis: confirmation and the four outcomes

Step one of analysis is always confirmation. A scanner finding is a claim, not a fact. Each finding gets marked as one of four outcomes.

False positives are the loud failure mode. False negatives are the silent killer. A program that tunes the scanner to suppress false positives without verifying coverage can drift into false negatives. The discipline is to confirm, document the confirmation, and update the scanner policy when both sides are clear.

CVE and CVSS

The Common Vulnerabilities and Exposures (CVE) system is the public identifier for vulnerabilities. Format: CVE-YYYY-NNNNN. Maintained by MITRE, cross-referenced in the NVD (National Vulnerability Database, run by NIST). Every published vulnerability gets a CVE number.

The Common Vulnerability Scoring System (CVSS) is the 0.0 to 10.0 severity score. CVSS v3.1 is the dominant version in use. CVSS v4.0 was published in 2023 and is rolling out. CVSS has three components.

• Base score. Reflects intrinsic technical severity. Considers attack vector (network, adjacent, local, physical), attack complexity, privileges required, user interaction, scope (does the vulnerability cross trust boundaries), and the CIA impact (confidentiality, integrity, availability). The base score does not change after publication.
• Temporal score. Adjusts the base score for whether an exploit exists in the wild and whether a patch is available. Improves as the patch ships and degrades when exploit code drops.
• Environmental score. Adjusts the temporal score for how the vulnerability affects this specific environment. Considers asset criticality and the local impact on CIA.

The CVSS severity bands map to remediation timelines used by most enterprise programs.

These bands are floors, not ceilings. An internet-facing system gets tighter SLAs than the band suggests. An isolated lab system can sit longer than the band suggests if compensating controls and risk acceptance are documented.

Environmental judgment

The base score alone is not enough. Local analysts layer environmental judgment on top.

• Exposure factor. The percentage of asset value lost if the vulnerability is exploited. A vulnerability that destroys a database has a higher exposure factor than one that crashes a single service.
• Environmental variables. Internet-facing or internal only? Holds regulated data (PHI, PCI, FERPA)? On the same VLAN as a domain controller? Reachable from a non-trusted vendor network?
• Industry impact. A SQL injection on a billing system at a healthcare provider triggers HIPAA breach notification. The same SQL injection at a coffee shop triggers a customer apology. Industry alters the cost of failure.
• Organizational impact. Some assets are revenue-critical. Some are reputation-critical. Some are both. The risk register names the high-impact assets.
• Risk tolerance. The residual risk floor leadership will accept without action. Above the floor, fix. Below the floor, document and move on.

CISA Known Exploited Vulnerabilities (KEV) catalog

The CISA KEV catalog is the single most actionable feed in the field. CISA lists CVEs with confirmed active exploitation in the wild. Federal civilian agencies are required by Binding Operational Directive 22-01 to patch KEV-listed vulnerabilities by the listed due date, typically two weeks or shorter. Most enterprises copy the KEV deadline as their priority floor because attackers are already using these vulnerabilities. Cyber insurance carriers ask for KEV coverage percentage during underwriting. The catalog is free and updated continuously at cisa.gov/known-exploited-vulnerabilities-catalog.

Response and remediation paths

Five remediation paths cover the SY0-701 list. Choose the one that matches the scenario.

Patching is the default. Segmentation buys time. Compensating controls (a WAF rule that blocks the exploit pattern, an EDR rule that detects the exploit behavior, an ACL that limits reachability, an IPS signature) are bridges, not destinations. Insurance transfers some of the residual risk to a carrier and is never a substitute for fixing the vulnerability. Exceptions and exemptions are the formal accept-the-risk decisions, time-bound (typically 90 days, renewable), signed by the system owner and security leadership, with the compensating controls named and the review date set. An undocumented exception is a hidden risk waiting for the next auditor.

Validation: rescan, audit, verify

Three validation activities. Use the one that matches the depth required.

• Rescanning. Run the vulnerability scanner again. Confirm the finding is gone. Fastest. Highest volume. Catches the easy cases.
• Audit. Structured review against the policy and the change record. Confirms the patch was applied per the change ticket, the exception is still valid, and the compensating control is documented.
• Verification. Manual proof the fix works. Often a test exploit attempt in a controlled lab or a hands-on inspection of the patched configuration. Use verification for critical CVEs and KEV-listed items where rescan-only is not sufficient evidence.

Skip validation and the program drifts into self-reporting fiction. The discipline is to validate every remediation, even when the scanner says the finding is gone.

Reporting: the three numbers leadership wants

Vulnerability management is one of the few security activities with hard numbers leadership understands. Three metrics anchor the report.

• MTTR (Mean Time to Remediate). Average days from discovery to fix, broken out by CVSS severity band. The headline metric for every mature program.
• KEV coverage. Percentage of CISA KEV-listed CVEs patched within the federal deadline. Cyber insurance carriers ask for this number directly.
• Exception count. Open accept-the-risk decisions. A growing exception count is the early warning that the patch pipeline cannot keep up.

Ship monthly with a one-sentence narrative. Add a top-5 lookahead: what is coming due in the next 30 days. A program that ships these three numbers consistently outlasts every leadership change.

Common gotchas

• False negatives are scarier than false positives. False positives waste time. False negatives mean the gap is real and nobody knows it is there. Tuning the scanner to suppress false positives without verifying coverage is how programs drift into false negatives.
• CVSS base alone is not enough. Two systems can have the same CVSS base score and very different real-world urgency. Internet-facing changes everything. Industry and regulatory exposure changes everything. Environmental judgment is the analyst job.
• KEV listing is a deadline, not a recommendation. Federal civilian agencies have a hard deadline under BOD 22-01. Most enterprises and insurance carriers treat KEV as the priority floor. Treat KEV listing as urgent regardless of the base score.
• Compensating controls are not patches. A WAF rule blocking an exploit pattern is a bridge until the application team ships the real fix. Track compensating controls separately and watch for them piling up.
• Insurance is not a remediation. Insurance transfers some residual risk to a carrier. The vulnerability still exists. The fix still has to happen.
• An undocumented exception is a hidden risk. Every accept-the-risk decision must be written down with the system owner signature, the compensating controls, and the review date. The auditor finds every undocumented exception eventually.
• Quarterly scanning is not vulnerability management. A quarterly scan is a snapshot. A program runs the loop continuously, ideally weekly or daily. New CVEs land every day. Patch Tuesday from Microsoft alone produces dozens of monthly findings.
• SAST and DAST are not the same. SAST reads source code at rest and catches issues pre-deploy. DAST probes a running app and catches runtime issues. Programs need both.
• Pen test is not a scan. A pen test brings ethical hackers in to find what scanners miss. Scans are continuous and automated. Pen tests are scoped engagements with rules of engagement and a final report. They serve different purposes.
• MTTR by band, not single MTTR. Reporting one MTTR number across all severities hides the dangerous gaps. Break MTTR out by Critical, High, Medium, Low. Leadership reads the Critical MTTR first.

Real-world context

In a vulnerability analyst seat, Monday morning starts with the weekend scan results and the Patch Tuesday import from the prior week. The analyst opens the dashboard: 412 new findings, 38 Critical, 14 of those on the CISA KEV catalog. The first hour is confirmation. The analyst clicks into each KEV-listed finding, validates the affected asset list against the CMDB (Configuration Management Database), and confirms three false positives that the scanner pattern matched on stale registry keys. The remaining 11 KEV findings go straight to the patch queue with the federal deadline as the SLA. The dashboard updates and the dashboard widget for cyber insurance auto-refreshes the KEV coverage percentage.

In a SOC Tier 1 seat, a CVE disclosure drops at 14:00. CISA adds it to the KEV catalog by 16:00. The Tier 1 analyst pulls the asset inventory, sees the company runs 240 of the affected systems, and routes the work to the vulnerability analyst and the IT operations engineer. By 18:00 the change request is in for the emergency window. By 06:00 the next morning the patches are deployed on 198 of 240 systems. The remaining 42 sit in the exception queue with a compensating control: a temporary IPS signature that detects the exploit pattern and a network ACL that restricts inbound access to admin jump hosts.

In a vulnerability management program that ships to leadership monthly, the report opens with the three numbers. MTTR Critical: 9 days, down from 12 last month. KEV coverage: 94 percent within deadline, up from 89 percent. Open exceptions: 38, of which 11 are aging past the 90-day review date and need either renewal or remediation. The one-sentence narrative says "Critical patch pipeline improved after the emergency window standardization, but the print spooler vendor certification delay drove 11 long-aging exceptions that need leadership attention."

Cyber insurance carriers now read these metrics before renewing a policy. The underwriter sample for a mid-market healthcare organization includes EDR coverage percentage, MFA (Multi-Factor Authentication) coverage, MTTR by severity band, KEV coverage percentage, and segmentation between corporate and clinical networks. Premiums move with the numbers. A program that ships clean, consistent metrics earns better terms. A program that ships nothing earns a higher premium or a non-renewal.

In a regulated industry, the auditor lens layers on top. HIPAA Security Rule 164.308(a)(1)(ii)(A) calls for a risk analysis. PCI DSS Requirement 6.3 calls for a documented vulnerability management process with scoring and remediation timelines. NIST 800-53 RA-5 calls for vulnerability scanning at organization-defined frequencies and reporting. The vulnerability management program is the operational evidence for all three. Skip the program and the auditor finding writes itself.

Sources

• CompTIA Security+ SY0-701 Exam Objectives, Section 4.3
• NIST SP 800-40 Rev 4 Guide to Enterprise Patch Management Planning
• NIST SP 800-115 Technical Guide to Information Security Testing and Assessment
• CVSS v3.1 Specification Document (FIRST.org)
• CISA Known Exploited Vulnerabilities (KEV) Catalog and Binding Operational Directive 22-01
• OWASP Top 10 (for SAST and DAST grounding)
• NIST NVD (National Vulnerability Database) for CVE details