Vulnerability Lifecycle and CVSS/Risk Priority

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

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 is necessary but not sufficient. Layer real-world signals:

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

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.