Vulnerability Management
Before you start
Who is this for?
For system administrators and security learners who need a repeatable remediation process.
Prerequisites
- Security Fundamentals
- Basic system administration
What you'll be able to do
- Explain CVE and CVSS
- Validate scan results
- Prioritize with exposure and impact
- Remediate and verify findings
Practical outcome
Create a documented remediation plan that considers more than a severity score.
Vulnerability management is a repeatable process for reducing exploitable weaknesses. A vulnerability is a flaw or condition that could be abused. An exploit is a method or code that takes advantage of a vulnerability. Risk combines likelihood and impact in a particular environment; a vulnerability score alone is not the whole risk decision.
Learning objectives
Section titled “Learning objectives”- Explain CVE and CVSS without treating severity as business risk.
- Build an inventory and validate scanner findings.
- Prioritize, remediate, document exceptions, and verify closure.
Identify assets and findings
Section titled “Identify assets and findings”Start with an owned inventory: systems, software, versions, exposure, business owner, criticality, and lifecycle. Include cloud assets, appliances, and dependencies where possible. Scanning is a useful discovery method, but coverage depends on credentials, network reachability, plugins, and freshness. Only scan assets and ranges you are authorized to assess.
A CVE (Common Vulnerabilities and Exposures) identifier names a publicly known vulnerability record; it is not itself a severity score. CVSS (Common Vulnerability Scoring System) communicates severity using defined metrics. CVSS versions and metric groups differ; record which version and vector you use. CVSS is not a direct probability of compromise and a Base score does not include all local exposure, business impact, or changing threat context. See the FIRST CVSS v4.0 specification.
Validate and prioritize
Section titled “Validate and prioritize”Before action, validate that the affected product and version are present, the vulnerable component is enabled/reachable, and the finding is not a scanner artifact. Vendor backports can fix a vulnerability without changing the upstream-looking version string; check the distribution or vendor advisory rather than assuming a version match proves exposure.
A practical priority review combines:
- verified affected asset and business criticality;
- network exposure and reachable attack surface;
- credible active exploitation (for example, check the CISA Known Exploited Vulnerabilities catalog);
- available exploit conditions and required privileges;
- potential impact and compensating protections;
- remediation availability and operational constraints.
This is why CVSS alone is insufficient: the same severity can have very different urgency on an isolated lab host and an exposed critical service. Conversely, a lower score may deserve urgent action if exploitation is active and the asset is important.
Remediate and verify
Section titled “Remediate and verify”Prefer the vendor-supported fix: patch, upgrade, remove an unused component, or correct the configuration. Test changes in a suitable environment and use change controls for critical systems. If an immediate fix is unavailable, document compensating controls, owner, residual risk, approval, and an expiry/review date. A firewall rule or isolation may reduce exposure but does not remove the underlying defect.
After remediation, verify with the authoritative package/configuration state and a rescan or targeted check. Confirm the service still works and record evidence, date, scope, and any remaining affected assets. Close findings only when the agreed verification criteria pass.
Common failure modes
Section titled “Common failure modes”- Treating a scanner report as confirmed without validation.
- Prioritizing only by the largest CVSS number.
- Assuming a successful patch deployment means every asset received it.
- Leaving temporary exceptions open indefinitely.
- Scanning without authorization or without defining scope and impact.
Practice
Section titled “Practice”For a lab finding, record the asset owner, product/version, evidence, exposure, relevant vendor advisory, exploitation context, chosen fix, verification method, and exception expiry if applicable. Explain why your priority differs from the raw severity score, if it does.
Create a documented remediation plan that considers more than a severity score.
Related: Defensive Logging and Incident Triage, Security Fundamentals.