Vulnerability Assessment & Patch Management

From discovery to remediation — building a systematic, AI-augmented approach to finding and fixing security weaknesses before attackers exploit them.

Why Vulnerability Management Matters

Organizations face an ever-growing attack surface. The average enterprise has thousands of known vulnerabilities at any given time, but limited resources to fix them.

The Vulnerability Management Lifecycle

A continuous, five-phase cycle that never truly ends — each iteration strengthens your security posture.

1. Discover — Identify assets and scan for known vulnerabilities across infrastructure, applications, and dependencies
2. Assess — Evaluate each finding: confirm true positives, understand severity, and determine affected scope
3. Prioritize — Rank findings by business risk, exploitability, asset criticality, and environmental context
4. Remediate — Apply patches, configuration changes, mitigating controls, or accept residual risk with documentation
5. Verify — Confirm the fix is in place, rescan to validate, and update tracking records

Phase 1: Discover

You cannot protect what you do not know about. Discovery combines asset inventory with vulnerability scanning.

Asset Discovery

• Network scanning — Nmap, Masscan to find live hosts and open ports
• Cloud inventory — AWS Config, Azure Resource Graph, GCP Asset Inventory
• CMDB integration — ServiceNow, Lansweeper for enterprise asset tracking
• Container registries — Docker Hub, ECR, GCR — what images are deployed?

Vulnerability Scanning

• Authenticated scans — Agent-based or credentialed, sees installed software versions
• Unauthenticated scans — Network-based, sees externally visible weaknesses
• Application scans — DAST tools like OWASP ZAP, Burp Suite for web app vulns

Scanning Tools: Nessus, OpenVAS, Qualys

Interpreting Nessus Scan Results

A typical Nessus export contains structured data per finding. Here is an abbreviated CSV example:

Plugin ID,CVE,CVSS v3,Risk,Host,Protocol,Port,Name,Synopsis
11219,CVE-2023-44487,7.5,High,10.0.1.15,tcp,443,HTTP/2 Rapid Reset DoS,Remote HTTP/2 server vulnerable to DoS
20007,CVE-2023-38545,9.8,Critical,10.0.1.22,tcp,22,curl SOCKS5 Heap Overflow,libcurl SOCKS5 proxy heap buffer overflow
42873,,2.1,Low,10.0.1.15,tcp,80,SSL/TLS Certificate Info,SSL certificate uses SHA-1 signature
57582,CVE-2024-3094,10.0,Critical,10.0.2.5,tcp,22,XZ Utils Backdoor (CVE-2024-3094),Backdoored xz-utils 5.6.0/5.6.1
19506,,0.0,Info,10.0.1.15,tcp,0,Nessus Scan Information,Scan metadata and configuration

CVE & CVSS Scoring

What is a CVE?

Common Vulnerabilities and Exposures — a standardized identifier (e.g., CVE-2024-3094) for publicly known security flaws. Maintained by MITRE and NVD.

CVSS v3.1 Score Breakdown

Reading a CVSS Vector String

Every CVSS score is derived from a vector string that encodes attack characteristics:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H   (Score: 9.8 Critical)

AV:N  = Attack Vector: Network (remotely exploitable)
AC:L  = Attack Complexity: Low (no special conditions needed)
PR:N  = Privileges Required: None (unauthenticated)
UI:N  = User Interaction: None (no clicks needed)
S:U   = Scope: Unchanged
C:H   = Confidentiality Impact: High
I:H   = Integrity Impact: High
A:H   = Availability Impact: High

Phase 2: Assess

Raw scan results contain noise. Assessment separates real risk from false positives and informational clutter.

Key Assessment Activities

• Validate findings — Confirm the vulnerability actually exists (not a scanner misidentification)
• Check exploitability — Does a public exploit exist? Is it in exploit-db, Metasploit, or CISA KEV?
• Determine reachability — Can an attacker actually reach the vulnerable service?
• Assess data exposure — What data/systems are at risk if exploited?
• Identify compensating controls — WAF rules, network segmentation, EDR monitoring

Phase 3: Prioritize — Risk-Based with AI

CVSS score alone is a poor prioritization strategy. Risk-based vulnerability management (RBVM) adds context.

Factors Beyond CVSS

• Asset criticality — A vuln on a payment server > the same vuln on a dev sandbox
• Network exposure — Internet-facing vs. internal-only vs. air-gapped
• Exploit availability — Known exploit in the wild = immediate escalation
• Compensating controls — IPS signature, WAF rule, or firewall blocks the attack path
• Business impact — Revenue-generating service vs. archival system
• Regulatory requirements — PCI DSS, HIPAA, SOC 2 mandate specific timelines

EPSS: Exploit Prediction Scoring System

EPSS is a data-driven model that estimates the probability a vulnerability will be exploited in the wild within the next 30 days.

# Query EPSS API for a CVE
import requests

cve_id = "CVE-2024-3094"
resp = requests.get(f"https://api.first.org/data/v1/epss?cve={cve_id}")
data = resp.json()["data"][0]
print(f"{cve_id}: EPSS={data['epss']}, Percentile={data['percentile']}")
# CVE-2024-3094: EPSS=0.93, Percentile=0.99

Dependency Scanning: Your Supply Chain Attack Surface

Modern applications inherit hundreds of transitive dependencies. Each is a potential vulnerability vector.

npm audit: Realistic Output

$ npm audit

# npm audit report

semver  <7.5.2
  Severity: moderate
  semver vulnerable to ReDoS - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
  fix available via `npm audit fix`
  node_modules/semver

xml2js  <0.5.0
  Severity: moderate
  xml2js is vulnerable to prototype pollution - GHSA-776f-qx25-q3cc
  fix available via `npm audit fix --force`
  node_modules/xml2js

jsonwebtoken  <9.0.0
  Severity: high
  jwt algorithm confusion - https://github.com/advisories/GHSA-hjrf-2m68-5959
  Depends on: semver
  fix available via `npm audit fix --force`
  node_modules/jsonwebtoken

8 vulnerabilities (3 moderate, 4 high, 1 critical)

To address all issues, run: npm audit fix

pip-audit: Python Dependency Scanning

$ pip-audit

Found 4 known vulnerabilities in 3 packages
Name        Version  ID                   Fix Versions
----------- -------- -------------------- ------------
requests    2.28.0   PYSEC-2023-74        2.31.0
flask       2.2.0    CVE-2023-30861       2.3.2
cryptography 39.0.1  CVE-2023-38325       41.0.2
cryptography 39.0.1  CVE-2023-49083       41.0.6

Key observations for AI triage:

• requests 2.28.0 — Information disclosure via proxy headers; moderate severity
• flask 2.2.0 — Session cookie vulnerability; depends on cookie config
• cryptography — Two CVEs, both fixed in 41.x; potential breaking API changes in upgrade

Snyk & Dependabot: Automated Remediation

# Scan a project
snyk test

# Monitor continuously
snyk monitor

# Scan a container image
snyk container test myapp:latest

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

Container Image Scanning: Trivy & Grype

Container images bundle OS packages, language libraries, and your code — all need scanning.

# Scan an image
trivy image python:3.11-slim

# Scan and filter severity
trivy image --severity HIGH,CRITICAL \
  myapp:latest

# Output as JSON for AI processing
trivy image -f json -o results.json \
  myapp:latest

# Scan an image
grype python:3.11-slim

# Generate SBOM first, then scan
syft myapp:latest -o json > sbom.json
grype sbom:sbom.json

# Filter by severity
grype myapp:latest --only-fixed \
  --fail-on high

Trivy Scan: Realistic Output

$ trivy image myapp:latest

myapp:latest (debian 12.4)
==========================
Total: 142 (UNKNOWN: 2, LOW: 68, MEDIUM: 49, HIGH: 19, CRITICAL: 4)

+-----------------+------------------+----------+-------------------+---------------+
|     LIBRARY     |  VULNERABILITY   | SEVERITY | INSTALLED VERSION | FIXED VERSION |
+-----------------+------------------+----------+-------------------+---------------+
| libcurl4        | CVE-2024-2398    | HIGH     | 7.88.1-10+deb12u4 | 7.88.1-10+deb12u5 |
| openssl         | CVE-2024-0727    | MEDIUM   | 3.0.11-1~deb12u2  | 3.0.13-1~deb12u1  |
| zlib1g          | CVE-2023-45853   | CRITICAL | 1:1.2.13.dfsg-1   |               |
| libc6           | CVE-2024-2961    | HIGH     | 2.36-9+deb12u3    | 2.36-9+deb12u7 |
| python3.11      | CVE-2024-0450    | MEDIUM   | 3.11.2-6          | 3.11.2-6+deb12u2 |
+-----------------+------------------+----------+-------------------+---------------+

Python (pip)
============
Total: 12 (HIGH: 3, CRITICAL: 1)

+-----------------+------------------+----------+-------------------+---------------+
|     LIBRARY     |  VULNERABILITY   | SEVERITY | INSTALLED VERSION | FIXED VERSION |
+-----------------+------------------+----------+-------------------+---------------+
| cryptography    | CVE-2024-26130   | HIGH     | 41.0.1            | 42.0.4        |
| pillow          | CVE-2024-28219   | CRITICAL | 10.0.0            | 10.3.0        |
| jinja2          | CVE-2024-22195   | MEDIUM   | 3.1.2             | 3.1.3         |
+-----------------+------------------+----------+-------------------+---------------+

AI-Assisted Patch Impact Analysis

The hardest question in patching: "Will this patch break something?"

What AI Can Analyze

• Changelog parsing — Summarize breaking changes between current and target versions
• API surface comparison — Identify deprecated/removed functions your code uses
• Dependency conflict detection — Flag incompatible version constraints across packages
• Test coverage assessment — Determine if critical paths have test coverage for regression detection
• Historical incident correlation — "Last time we upgraded X, service Y broke because of Z"

prompt = """
Analyze the upgrade path from Django 4.1 to Django 5.0 for our project.

Our codebase uses:
- django.utils.timezone.utc (removed in 5.0)
- DEFAULT_FILE_STORAGE setting (replaced with STORAGES)
- url() patterns (removed, must use path())

List each breaking change, the files affected, and a migration plan.
"""

Patch Impact: AI Response Example

Here is what an AI-assisted analysis might return for the Django upgrade:

Breaking Changes Detected:
==========================

1. django.utils.timezone.utc → datetime.timezone.utc
   Files affected: utils/dates.py (line 12), api/views.py (line 87)
   Migration: Find-and-replace import. No logic change needed.
   Risk: LOW

2. DEFAULT_FILE_STORAGE → STORAGES dict
   Files affected: settings/production.py (line 45)
   Migration: Restructure setting to new STORAGES format.
   Risk: LOW (config-only change)

3. url() → path()/re_path()
   Files affected: urls.py (14 patterns), api/urls.py (8 patterns)
   Migration: Convert regex patterns to path() converters.
   Risk: MEDIUM — regex patterns with captures need careful conversion.

Recommendation: Stage upgrade in dev, run full test suite.
Estimated effort: 2-3 hours for experienced developer.

Phase 4: Remediate

Remediation is not always "just patch it." There are multiple strategies depending on context and risk.

Remediation Options

Patch Management Strategies

A structured approach to deploying patches safely across environments.

The Patch Pipeline

1. Staging/Test — Apply patch to non-production environment first
2. Automated testing — Run regression suite, integration tests, smoke tests
3. Canary deployment — Roll to a small subset of production (5–10%)
4. Monitor — Watch error rates, latency, and functionality for 1–4 hours
5. Full rollout — Expand to all production systems
6. Verification scan — Rescan to confirm vulnerability is resolved

Rollback Planning

• Pre-patch snapshots — VM snapshots, database backups, container image tags
• Blue-green deployment — Keep previous version running; switch back if needed
• Feature flags — Disable new code paths without full rollback
• Documented rollback procedure — Step-by-step, tested before patch day

Emergency Patching: When the Clock is Ticking

Zero-day or actively exploited vulnerabilities require an accelerated process.

Accelerated Timeline

1. Hour 0–1: Assess exposure — which systems are affected?
2. Hour 1–4: Apply mitigation (WAF rules, network blocks) while testing patch
3. Hour 4–8: Abbreviated test cycle — smoke tests on staging
4. Hour 8–24: Production rollout with enhanced monitoring
5. Day 2–3: Full regression testing, verify fix across all systems

SLA-Based Remediation Timelines

Define clear remediation SLAs based on severity and asset tier. Track compliance metrics.

Tracking & Metrics

• MTTR (Mean Time to Remediate) — by severity level
• SLA compliance rate — percentage of vulns fixed within SLA
• Vulnerability debt — total open vulns past SLA deadline
• Risk reduction over time — trending total risk score down

Phase 5: Verify

Remediation without verification is hope-based security. Always confirm the fix.

Verification Methods

• Rescan — Run the same scanner that found the vulnerability; confirm it no longer appears
• Targeted validation — Attempt the specific exploit against the patched system
• Version check — Verify the package/OS version matches the patched version
• Configuration audit — For misconfigurations, verify the setting is correct
• Automated pipeline check — CI/CD gates that fail builds with known CVEs

# Verify a specific CVE is resolved
trivy image --severity CRITICAL myapp:latest | grep CVE-2024-28219
# (no output = vulnerability resolved)

# Check installed package version
dpkg -l | grep openssl
# ii  openssl  3.0.13-1~deb12u1  (patched version confirmed)

AI-Powered Triage Pipeline

Combining all the concepts into an end-to-end AI-assisted vulnerability management workflow.

import anthropic, json

client = anthropic.Anthropic()

# 1. Load scan results
with open("trivy_results.json") as f:
    scan_data = json.load(f)

with open("asset_inventory.json") as f:
    assets = json.load(f)

# 2. AI-assisted triage
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=4096,
    messages=[{
        "role": "user",
        "content": f"""You are a vulnerability management analyst.

Analyze these Trivy scan results and prioritize remediation.

SCAN DATA:
{json.dumps(scan_data, indent=2)}

ASSET CONTEXT:
{json.dumps(assets, indent=2)}

For each vulnerability:
1. Effective risk (considering asset tier and exposure)
2. Whether a fix is available
3. Recommended remediation action
4. Estimated effort (low/medium/high)
5. SLA deadline based on our policy

Output as a prioritized remediation plan in markdown."""
    }]
)
print(response.content[0].text)

Anatomy of a CVE Entry

Understanding what a CVE record contains helps you make faster triage decisions.

{
  "id": "CVE-2024-3094",
  "description": "Malicious code was discovered in the upstream tarballs of xz-utils, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file in the source code, which is then used to modify specific functions in the liblzma code, producing a modified library used by OpenSSH sshd authentication.",
  "published": "2024-03-29T17:15:00",
  "cvss_v3": {
    "baseScore": 10.0,
    "baseSeverity": "CRITICAL",
    "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
  },
  "affected_versions": ["5.6.0", "5.6.1"],
  "references": [
    "https://www.openwall.com/lists/oss-security/2024/03/29/4",
    "https://tukaani.org/xz-backdoor/"
  ],
  "cisa_kev": true,
  "epss": 0.93
}

Building a Remediation Plan

A good remediation plan is actionable, time-bound, and assigns clear ownership.

## Remediation Plan — Weekly Scan 2024-W14

### IMMEDIATE (24h) — Critical, Exploited in Wild
| # | CVE            | Host       | Action                         | Owner    | SLA     |
|---|----------------|------------|--------------------------------|----------|---------|
| 1 | CVE-2024-3094  | 10.0.2.5   | Downgrade xz to 5.4.x         | Ops Team | 24 hrs  |
| 2 | CVE-2024-28219 | containers | Rebuild with pillow>=10.3.0    | DevOps   | 24 hrs  |

### HIGH PRIORITY (7 days)
| # | CVE            | Host       | Action                         | Owner    | SLA     |
|---|----------------|------------|--------------------------------|----------|---------|
| 3 | CVE-2024-2398  | 10.0.1.15  | Update libcurl4 to deb12u5     | SysAdmin | 7 days  |
| 4 | CVE-2024-2961  | 10.0.1.15  | Update libc6 to deb12u7        | SysAdmin | 7 days  |
| 5 | CVE-2024-26130 | containers | Upgrade cryptography to 42.0.4 | DevOps   | 7 days  |

### MEDIUM (30 days)
| # | CVE            | Host       | Action                         | Owner    | SLA     |
|---|----------------|------------|--------------------------------|----------|---------|
| 6 | CVE-2024-0727  | 10.0.1.15  | Update openssl to deb12u1      | SysAdmin | 30 days |
| 7 | CVE-2024-22195 | containers | Upgrade jinja2 to 3.1.3        | DevOps   | 30 days |

### Accepted Risk
- CVE-2023-45853 (zlib): No fix available from Debian. Mitigated by WAF. Review next month.

Shift Left: Scanning in CI/CD

Catch vulnerabilities before they reach production by integrating scanning into your pipeline.

# .github/workflows/security-scan.yml
name: Security Scan
on: [push, pull_request]

jobs:
  dependency-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run pip-audit
        run: |
          pip install pip-audit
          pip-audit -r requirements.txt --fail-on-vuln

      - name: Run npm audit
        run: npm audit --audit-level=high
        working-directory: ./frontend

  container-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Trivy scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: 1   # Fail the build on findings

Common Vulnerability Management Pitfalls

Key Takeaways

• Vulnerability management is a lifecycle — discover, assess, prioritize, remediate, verify — repeat continuously
• CVSS alone is not enough — combine with EPSS, CISA KEV, and asset context for effective prioritization
• AI accelerates every phase — scan interpretation, triage, impact analysis, remediation planning, and reporting
• Scan everything — infrastructure, dependencies, containers, and IaC — shift left into CI/CD
• Patch strategically — test first, have rollback plans, use canary deployments for critical changes
• Track and measure — SLAs, MTTR, and vulnerability debt are your operational health metrics
• Emergency processes matter — pre-approved change procedures for zero-days save critical hours

CTF Challenge: Vulnerability Triage & Remediation Plan

Your Mission

1. Triage the scan — Review the provided Nessus CSV (50+ findings) and Trivy JSON (container scan). Identify false positives and duplicates.
2. Prioritize findings — Use CVSS, EPSS data, CISA KEV status, and the provided asset inventory (with tier classifications) to rank findings by effective risk.
3. Create a remediation plan — Assign each finding to a remediation track (immediate / high / medium / accepted risk) with owner, action, and SLA deadline.
4. Draft an AI prompt — Write a prompt that would automate this triage process for next week's scan, including the context an AI would need.
5. Bonus: Identify one finding where the CVSS score is misleading (too high or too low given context) and explain why.