Vulnerability Lifecycle and CVSS/Risk Priority

CompTIA Security+ SY0-701

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

Current Exam Facts and How Security+ Tests Judgment Domain Weighting and an 8-12 Week Study Plan Practice Questions, PBQs, and the Missed-Question Notebook

2 Domain 1: General Security Concepts (12%)

CIA and Non-Repudiation Control Types and Categories with Scenario Classification Security Principles: Least Privilege, Defense in Depth, Secure by Design, and Zero Trust Change Management and Business Impact

3 Domain 1: Identity, Trust, and Cryptography Basics

AAA and IAM Concepts Authentication Factors and MFA Traps Authorization Models: RBAC, ABAC, MAC, DAC, and Least Privilege Cryptography, Hashes, Signatures, PKI, and Certificate Decision Rules

4 Domain 2: Threat Actors, Vectors, and Social Engineering

Threat Actors and Motivations Attack Vectors and Attack Surface Social Engineering Types and Clues Supply Chain and Insider Threat Scenarios

5 Domain 2: Threats, Vulnerabilities, and Mitigations - Attacks

Malware Behaviors and Indicators Credential and Password Attacks Network and Wireless Attacks Application, API, and Cloud Attacks with Mitigation Mapping

6 Domain 2: Threats, Vulnerabilities, and Mitigations - Vulnerabilities

Vulnerability Types and Misconfiguration Vulnerability Scanning and Prioritization Secure Coding and Application Mitigations Remediation, Compensating Controls, and Risk-Based Decisions

7 Domain 3: Security Architecture - Secure Architecture Models

Architecture Models and Trust Boundaries Cloud Shared Responsibility and Service Models Zero Trust, SASE, and SSE Concepts Secure Design Review Scenarios

8 Domain 3: Security Architecture - Network Security Architecture

Segmentation, VLANs, DMZ, and Microsegmentation Firewalls, WAF, IDS, IPS, and Proxies VPN, Remote Access, and NAC Wireless Security and Enterprise Network Design

9 Domain 3 Part C: Data Protection and Resilience

Data Classification and Handling Encryption at Rest, in Transit, in Use, and Key Management DLP, Privacy, and the Data Lifecycle Backups, RTO, RPO, BCP, DR, and Resilience

10 Domain 4 Part A: Secure Operations for Hosts, Cloud, Mobile, and IoT

Endpoint and Server Hardening Cloud, Container, and Virtualization Operations Mobile, BYOD, and MDM Embedded, IoT, OT, and Physical Device Security

11 IAM Operations and Access Control

Provisioning, Deprovisioning, and Access Reviews PAM, JIT, JEA, and Service Accounts Federation, SSO, SAML, OIDC, and OAuth Account Attacks and IAM Monitoring

12 Logging, Monitoring, and Detection

Log Sources and Telemetry SIEM Correlation and Alert Triage SOAR, Playbooks, and Automation Detection Use Cases and False-Positive Handling

13 Incident Response

IR Phases and Roles Containment, Eradication, and Recovery Decisions Communication, Escalation, Legal, and Regulatory Considerations Post-Incident Lessons Learned and Metrics

14 Digital Forensics and Investigation

Evidence Handling and Chain of Custody Disk, Memory, Network, and Log Artifacts Order of Volatility and Acquisition Choices Forensic Reporting and Anti-Forensics Traps

15 Vulnerability, Patch, Asset, and Automation Operations

Asset Inventory and Data Classification in Ops Vulnerability Lifecycle and CVSS/Risk Priority Patch, Change, and Configuration Management Automation, Orchestration, SCAP, and Security Tooling

16 Governance, Policies, and Risk Management

Governance Documents: Policy, Standard, Procedure, and Baseline Risk Register and Risk Treatment Quantitative/Qualitative Risk and BIA Exceptions, Acceptance, Ownership, and Reporting

17 Third-Party Risk, Compliance, and Privacy

Vendor Risk Lifecycle and Agreements Due Diligence, Questionnaires, and Monitoring Privacy Concepts and Data Rights Compliance Reporting and Consequences

18 Audits, Penetration Testing, and Awareness

Internal and External Audits and Evidence Penetration Test Types and Rules of Engagement Security Awareness, Training, and Phishing Metrics Personnel and Physical Security Program Controls

19 Final Review and PBQ Labs

PBQ Workflow and Timing Ports, Protocols, and Acronyms High-Yield Tables Firewall, IAM, Log, and Risk PBQ Mini-Labs Final 7-Day Review Plan Mixed Exam Strategy and Missed-Question Remediation

Vulnerability Lifecycle and CVSS/Risk Priority

Key Takeaways Explain This Topic AI

Vulnerability management is a lifecycle: discover, validate, prioritize, remediate, verify, and report.

CVSS v4.0 scores 0.0–10.0 (Low 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9, Critical 9.0–10.0) but is only technical severity — not the whole priority answer.

Real priority also depends on exploitability (EPSS, CISA KEV), exposure, asset criticality, data classification, and compensating controls.

Authenticated/credentialed and agent-based scans find deeper, more reliable findings than unauthenticated scans.

False positives, exceptions, and accepted risk must be documented; remediation must be verified by rescan or control test.

Last updated: October 2026

Vulnerability management is the recurring process of finding weaknesses, validating them, prioritizing by risk, fixing or mitigating, and proving the risk changed. A scan report is only an input — the security value is turning findings into risk-based action.

Lifecycle

Phase Goal Evidence

Discover / identify Find assets and weaknesses Scan results, agent telemetry, vendor advisories, bug-bounty reports, threat feeds

Validate Confirm the finding applies (rule out false positives) Version checks, configuration review, exploit-condition review

Prioritize / analyze Decide what is fixed first CVSS, EPSS, KEV, exposure, criticality, data classification

Remediate or mitigate Remove or reduce the weakness Patch, configuration change, segmentation, compensating control

Verify Confirm the fix worked Rescan, package version, configuration state, control test
Report Communicate status and residual risk Dashboards, exceptions, risk register, aging reports

Responses on the exam are remediation (apply the patch or fix), mitigation (compensating controls reduce risk while a fix is pending), transference (insurance or contractual shift), or formal risk acceptance with owner sign-off and an expiration date. Avoidance — removing the function entirely — is the fifth option. The validate step matters more than candidates expect: scanners produce false positives (reporting a flaw that does not actually apply, often because a back-ported vendor patch leaves the version banner unchanged) and false negatives (missing a real flaw).

Before opening an emergency change you confirm the finding against version, configuration, and exploit preconditions, and you record disproven findings so the same false positive is not re-triaged every scan cycle.

CVSS v4.0 and the Severity Bands

The Common Vulnerability Scoring System (CVSS) , currently v4.0 from FIRST, expresses technical severity on a 0.0–10.0 scale:

CVSS band Score range Typical posture
None 0.0 Informational
Low 0.1–3.9 Routine cycle
Medium 4.0–6.9 Scheduled remediation
High 7.0–8.9 Expedite; plan a change
Critical 9.0–10.0 Emergency or rapid patch

CVSS is necessary but not sufficient. Layer real-world signals:

Signal Question it answers

CISA KEV catalog Is this CVE confirmed exploited in the wild?

EPSS (0–1 probability) How likely is exploitation in the next 30 days?

Exposure Internet-facing, partner-facing, or internal-only?

Asset criticality Does it support an essential business service?

Data sensitivity Confidential or restricted data at stake?

Existing controls Do segmentation, WAF, or EDR blunt the impact?

A CVE on the CISA KEV list demands action regardless of CVSS — US federal civilian agencies must remediate on CISA's directive timelines (BOD 26-04, issued June 10, 2026, revoked BOD 22-01 and its default two-week window; its timelines depend on public exposure, KEV status, exploit automation, and technical impact, and can compress the most dangerous flaws to as few as three days). The teaching point for SY0-701 is that confirmed exploitation outranks raw severity: a medium-CVSS flaw that is being actively exploited and sits on an internet-facing box should be remediated before a higher-CVSS flaw that has no public exploit and lives on an isolated segment.

EPSS gives you the forward-looking probability and CVSS the technical impact, but KEV is the present-tense fact of exploitation, and that fact usually wins the prioritization argument.

Worked Priority Example

Finding CVSS Asset Context Priority

RCE in public VPN appliance 9.8 Internet-facing VPN On CISA KEV, active exploitation, workforce access Emergency

Local privilege escalation 8.4 Isolated test lab No sensitive data, no exposure, reimage planned Scheduled

The VPN wins on exposure plus confirmed exploitation, not raw score alone.

Scan Types

Unauthenticated scans view a system from outside — good for exposure but blind to local package versions. Credentialed/authenticated and agent-based scans log in (or run locally) to detect missing patches, registry settings, services, and configuration drift far more accurately. Scanner credentials must be scoped, vaulted, monitored, and rotated; a broad scanning account is a high-value target. SY0-701 also distinguishes active scans (probe the target, may disrupt) from passive monitoring (observe traffic, low impact).

Common Traps

Sorting only by CVSS while ignoring KEV/EPSS or exposure.

Closing findings without verification evidence.

Treating a vulnerability exception as permanent permission to stay vulnerable.

Running unauthenticated scans only and assuming full coverage.

Ignoring vulnerability age and repeatedly missing remediation due dates.

Exam Focus

SY0-701 often lists several vulnerable assets and asks what to fix first. Choose the option that pairs high technical severity with real risk: confirmed exploitation (KEV), public exposure, sensitive data, business criticality, or weak controls. A second recurring question type describes a finding the team cannot immediately patch and asks for the correct interim action — the answer is a documented compensating control plus an exception with owner approval and an expiration date, never silent acceptance.

Finally, remember the verify step: closing a ticket requires evidence (a clean rescan, the new package version, or a passed control test), so any answer that closes findings on the analyst's word alone is wrong.