Vulnerability Management Program: CVSS, SLAs, and Remediation Tracking

Every day, new vulnerabilities are discovered in the software components, cloud configurations, and systems that power your infrastructure. A vulnerability management program is the systematic process for discovering, prioritizing, and remediating these vulnerabilities before attackers exploit them.

Without a program, vulnerability response is reactive — a CVE is announced, and the team scrambles to figure out if they are exposed and who is responsible for the fix. With a program, you have continuous visibility, clear ownership, defined SLAs, and metrics that demonstrate improvement over time.

The Four Phases of Vulnerability Management

1. Discovery — Find all vulnerabilities in your environment before attackers do. 2. Prioritization — Determine which vulnerabilities pose the most actual risk. 3. Remediation — Fix, mitigate, or accept each vulnerability. 4. Verification — Confirm vulnerabilities are actually resolved.

Discovery: Scan Cadence and Coverage

Vulnerabilities are discovered continuously — new CVEs are published daily. Your scanning program must keep pace.

Scan types and frequency:

Scan Type	Coverage	Cadence
Agent-based endpoint scan	All managed endpoints	Continuous
Network vulnerability scan	Internet-exposed hosts	Weekly
Container image scan	All images in registry	Every build
Cloud configuration scan	All cloud resources	Daily
Web application DAST	Internet-facing apps	Weekly
Penetration test	Critical systems	Annual + major releases
Code SAST	All repositories	Every PR

Key scanning tools:

Tenable.io / Nessus — Comprehensive network and endpoint scanning, industry-standard
Qualys VMDR — Unified VM + patch management, strong compliance reporting
Rapid7 InsightVM — Good cloud integration, real-risk scoring
Trivy — Open-source container and IaC scanning
Nuclei — Fast, template-based web application scanning

Coverage is the first priority. An authenticated scan of 80% of your servers is better than an unauthenticated scan of 100%. Unauthenticated scans miss local privilege escalation, unpatched packages not exposed via network services, and many configuration issues.

Authenticated scanning configuration (Tenable):

Scanner type: Credentialed scan
Authentication: SSH key pair (deploy scanner's public key to all targets)
Scan policy: Advanced Network Scan
Schedule: Weekly, off-hours
Target groups: Production servers, Staging servers, Corporate endpoints

CVSS: Understanding the Scoring System

CVSS (Common Vulnerability Scoring System) is the industry standard for rating vulnerability severity. CVSS v3.1 and v4.0 score vulnerabilities on a 0.0-10.0 scale.

CVSS v3.1 Base Score components:

Exploitability metrics:

Attack Vector (AV) — Network, Adjacent, Local, Physical
Attack Complexity (AC) — Low, High
Privileges Required (PR) — None, Low, High
User Interaction (UI) — None, Required

Impact metrics:

Confidentiality Impact (C) — None, Low, High
Integrity Impact (I) — None, Low, High
Availability Impact (A) — None, Low, High
Scope (S) — Unchanged, Changed

Score ranges:

Score	Severity
9.0 – 10.0	Critical
7.0 – 8.9	High
4.0 – 6.9	Medium
0.1 – 3.9	Low

The CVSS problem: CVSS scores rate theoretical severity, not actual exploitability in your environment. CVE-2021-44228 (Log4Shell) scored 10.0 CVSS — but if your Java applications do not use Log4j, the risk to you is zero. A CVSS 7.5 vulnerability in a component you use heavily in internet-facing services may be higher priority than a CVSS 9.8 in an internal-only tool.

Better Prioritization: Beyond CVSS

EPSS (Exploit Prediction Scoring System):

FIRST.org's EPSS predicts the probability that a CVE will be exploited in the wild within the next 30 days, based on historical exploitation patterns and threat intelligence.

High CVSS + High EPSS = Fix immediately. High CVSS + Low EPSS = Fix within SLA. Low CVSS + High EPSS = Fix sooner than CVSS alone would suggest.

import requests

def get_epss_score(cve_id: str) -> float:
    response = requests.get(
        f"https://api.first.org/data/v1/epss?cve={cve_id}"
    )
    data = response.json()
    if data['data']:
        return float(data['data'][0]['epss'])
    return 0.0

# CVE with CVSS 9.8 but EPSS 0.001 = low exploitation probability
# CVE with CVSS 6.5 but EPSS 0.92 = extremely likely to be exploited

CISA KEV (Known Exploited Vulnerabilities):

CISA publishes a catalog of CVEs with confirmed in-the-wild exploitation. Any KEV-listed vulnerability in your environment should be treated as Critical regardless of CVSS score.

# Download and search the KEV catalog
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | python3 -c "
import json, sys
kev = json.load(sys.stdin)
for v in kev['vulnerabilities']:
    print(v['cveID'], v['vendorProject'], v['product'])
" | grep -i "apache\|log4j\|spring"

Asset context:

A vulnerability's priority changes based on the asset it affects:

Internet-exposed — Higher priority (reachable by external attackers)
Production — Higher priority (handles real customer data)
Privileged — Higher priority (compromise has larger blast radius)
Internal-only, isolated — Lower priority

A risk score formula:

Risk Score = CVSS × (1 + Internet_Exposure × 0.5) × (1 + Production × 0.3) × EPSS_Factor

Defining SLAs

SLAs define the maximum time from discovery to remediation by severity. Without SLAs, vulnerability remediation has no accountability.

Recommended SLA tiers:

Severity	Definition	Remediation SLA
Critical	CVSS 9.0+ AND (KEV listed OR EPSS > 0.5)	7 days
High	CVSS 7.0-8.9 OR CVSS 9.0+ on non-KEV	30 days
Medium	CVSS 4.0-6.9	90 days
Low	CVSS < 4.0	180 days or risk-accepted

SLA exceptions:

Some vulnerabilities cannot be patched within SLA due to:

Vendor patch not yet available
Remediation requires downtime (requires change window)
Dependency on a third-party update

For exceptions, document:

Exception reason
Compensating controls implemented
New target remediation date
Approving security team member

Ticketing Integration

Vulnerability management is only as effective as the process for getting fixes to the engineering teams who implement them.

Integration pattern:

Scanner discovers vulnerability
VM platform identifies owner based on asset tags (team, service, environment)
VM platform auto-creates Jira/Linear/GitHub issue in the owner's project
Issue contains: CVE ID, CVSS score, EPSS, affected asset, remediation guidance, SLA due date
SLA countdown begins from creation date
At 75% of SLA elapsed: automatic reminder sent to owner and manager
At SLA breach: escalation to security team for review
After patch applied: scanner re-scans and automatically closes ticket if vulnerability is gone

Jira integration via VM platform API:

Most enterprise VM platforms (Tenable, Qualys, Rapid7) have native Jira/ServiceNow connectors. For custom integrations:

from jira import JIRA
from datetime import datetime, timedelta

def create_vuln_ticket(jira_client: JIRA, finding: dict) -> str:
    sla_days = {'critical': 7, 'high': 30, 'medium': 90, 'low': 180}
    severity = finding['severity'].lower()
    due_date = datetime.now() + timedelta(days=sla_days[severity])

    issue = jira_client.create_issue(
        project=finding['team_jira_project'],
        summary=f"[{severity.upper()}] {finding['cve_id']}: {finding['title']}",
        description=format_vuln_description(finding),
        issuetype={'name': 'Security Vulnerability'},
        priority={'name': severity.capitalize()},
        duedate=due_date.strftime('%Y-%m-%d'),
        labels=['security', 'vulnerability', finding['cve_id']],
        customfield_cvss_score=finding['cvss_score']
    )
    return issue.key

KPIs and Reporting

Track these metrics to demonstrate program effectiveness:

Coverage:

Percentage of assets scanned within the last 7 days (target: 98%+)
Percentage of CI/CD pipelines with scanning enabled (target: 100%)

Velocity:

Mean time to remediation by severity (target: within SLA)
SLA compliance rate by severity tier (target: 95%+ for Critical)

Volume:

Total open vulnerabilities by severity (track trend, not absolute number)
Net new vulnerabilities introduced per sprint (leading indicator)
Vulnerability closure rate (are you gaining or losing ground?)

Quality:

Percentage of Critical/High vulnerabilities with compensating controls where patch not available
Mean days to first response (ticket acknowledged by owner)

Monthly trend report format:

VULNERABILITY MANAGEMENT — MARCH 2026

Open Vulnerabilities (end of month):
  Critical: 3 (↓2 from Feb) — SLA compliance: 100%
  High: 47 (↓8 from Feb) — SLA compliance: 94%
  Medium: 312 (↑12 from Feb) — SLA compliance: 87%

SLA Compliance Trend:
  Critical: 100% (3 months running)
  High: 94% (Feb: 89%, Jan: 82%) ▲ Improving
  Medium: 87% (Feb: 85%, Jan: 81%) ▲ Improving

Top Findings This Month:
  1. CVE-2026-XXXX in nginx (Critical, KEV listed) — remediated in 3 days
  2. 12 AWS S3 buckets with server-side encryption disabled — remediated
  3. ...

Focus Next Month:
  - Medium backlog has grown; scheduling remediation sprint for top-30 oldest

A vulnerability management program does not succeed by eliminating all vulnerabilities — that is impossible in a world of continuously published CVEs. It succeeds by ensuring that the most dangerous vulnerabilities are fixed first, fast, and with accountability, while building the organizational muscle to sustainably reduce exposure over time.