Patching and Vulnerability Management

The Asset Inventory Problem

The most common reason organizations get breached through known vulnerabilities is not that they did not have patches available — it is that they did not know the vulnerable system existed. A complete, accurate asset inventory is the foundation of all vulnerability management. Without it, you are patching blindly.

Building the Asset Inventory

An asset inventory must capture:

• Hardware: Servers (physical and virtual), workstations, network devices, IoT devices, mobile devices
• Software: Operating systems, applications, libraries, frameworks, containers
• Cloud resources: VMs, serverless functions, storage buckets, databases, Kubernetes clusters
• Network information: IP addresses, DNS names, open ports, network segments
• Ownership: Who is responsible for each asset
• Criticality: How important is this asset to the business?

# Discover hosts on a network
nmap -sn 192.168.1.0/24

# Detailed discovery with OS and service detection
nmap -sV -sC -O 192.168.1.0/24

# Check installed packages on a Linux host
dpkg -l > inventory.txt    # Debian/Ubuntu
rpm -qa > inventory.txt     # RHEL/CentOS

# Check for outdated packages
apt list --upgradable        # Debian/Ubuntu

The inventory must be continuous, not periodic. New assets appear constantly — cloud instances are created and destroyed, developers spin up test servers, employees connect personal devices. A point-inventory snapshot is outdated the moment it is taken. Continuous discovery tools (cloud asset management, network scanning, EDR platforms) maintain a current inventory automatically.

Vulnerability Scanning

Once you know what assets exist, you scan them for vulnerabilities:

# Open-source vulnerability scanner
# OpenVAS (Greenbone)
# Install and run a scan against a target

# Nessus (commercial, free for home use)
# Create a scan policy, target specific assets, run scan

# Command-line scanning with nmap scripts
nmap --script vuln 192.168.1.100

Vulnerability scanners detect:

• Missing security patches
• Default credentials
• Misconfigurations (weak TLS, unnecessary services, default pages)
• Known CVEs in installed software

Scanner limitations:

• Scanners cannot detect vulnerabilities in custom application code
• Scanners may cause service disruptions if not configured carefully
• Scanners require credentials for authenticated scans (more thorough but riskier)
• Scanners produce false positives that must be triaged

The Vulnerability Management Lifecycle

Vulnerability management is a continuous cycle, not a one-time project:

1. Discover: Identify all assets in the environment
2. Assess: Scan for vulnerabilities and misconfigurations
3. Prioritize: Rank vulnerabilities by risk (not just CVSS)
4. Remediate: Patch, mitigate, or accept the risk
5. Verify: Confirm the remediation was effective
6. Monitor: Continuously scan for new vulnerabilities

    Discover → Assess → Prioritize → Remediate → Verify
        ↑                                        |
        └──────────── Monitor ←───────────────────┘

Each stage feeds the next. Discovery finds new assets, assessment finds vulnerabilities on them, prioritization determines which to fix first, remediation applies the fix, verification confirms it worked, and monitoring finds new vulnerabilities introduced by changes.

Risk-Based Prioritization

The most common mistake in vulnerability management is prioritizing solely by CVSS score. A CVSS 9.8 vulnerability on an isolated internal test server is a lower priority than a CVSS 7.5 vulnerability on an internet-facing payment system. CVSS measures severity — how bad the vulnerability would be if exploited — but it does not measure risk, which combines severity with likelihood and impact.

Adjusting CVSS for Your Environment

The CVSS base score should be adjusted by environmental factors:

Exploitability adjustment:

• Is there a known public exploit? (Exploit-DB, Metasploit module)
• Is the exploit reliable or does it require specific conditions?
• Is the vulnerability being actively exploited in the wild? (CISA KEV catalog)

Exposure adjustment:

• Is the asset internet-facing or internal-only?
• Is the asset in a segmented network with firewall protection?
• Does the asset process sensitive data (PII, financial, health)?

Asset criticality adjustment:

• Is the asset a single point of failure?
• How many users depend on this asset?
• What is the financial impact of downtime?
• Are there regulatory requirements for this asset?

Temporal adjustment:

• Has a patch been available for a long time? (Longer = more likely to be exploited)
• Is a patch available now, or is mitigation the only option?

The CISA KEV Catalog

The CISA Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities that are being actively exploited in the wild. Any vulnerability on this catalog should be treated as critical regardless of its CVSS score, because attackers are actively using it.

# Check if a CVE is in the KEV catalog
# https://www.cisa.gov/known-exploited-vulnerabilities-catalog
# Download the JSON and search:
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | \
  python3 -c "import json,sys; data=json.load(sys.stdin); [print(v['cveID']) for v in data['vulnerabilities'] if 'CVE-2024' in v['cveID']]"

Patch SLAs: Balancing Speed and Stability

Patching too slowly leaves you vulnerable. Patching too quickly can break production systems. Patch SLAs (Service Level Agreements) define how quickly different categories of vulnerabilities must be patched:

The SLA clock starts when the patch is available, not when the vulnerability is disclosed. Vendors often release patches on a regular schedule (e.g., Microsoft's Patch Tuesday). The SLA should account for the time required to test the patch in a staging environment before deploying to production.

Patch Testing and Deployment

1. Vendor releases patch
2. Security team assesses urgency (CVSS + environmental factors)
3. Patch is deployed to staging environment
4. QA team tests for regressions
5. Patch is deployed to production (maintenance window)
6. Vulnerability scan verifies the patch was applied
7. Risk register is updated

When patching is not possible:

• Compensating controls: If a patch cannot be applied immediately, implement compensating controls — firewall rules, WAF rules, network segmentation, or configuration changes that reduce the risk.
• Virtual patching: A WAF or IPS rule that blocks exploitation of a specific vulnerability without patching the underlying software.
• Risk acceptance: If the cost of patching exceeds the risk, document the decision and the rationale. This is a valid choice — but it must be explicit, not implicit.

Vulnerability Management Metrics

Track these metrics to measure the effectiveness of your vulnerability management program:

• Mean time to patch (MTTP): Average time from patch availability to deployment
• Patch compliance rate: Percentage of assets patched within SLA
• Vulnerability aging: How long vulnerabilities have been open
• Recurrence rate: How often the same vulnerability reappears (indicates process failure)
• Coverage: Percentage of assets scanned in the last 30 days

These metrics tell you whether your program is improving or degrading over time. A rising MTTP or declining patch compliance rate indicates a process problem that needs attention.