Vulnerability Assessment and Patch Management

4 Nov 2026, 11:2826 min readby ITYantra Admin

Complete guide to vulnerability assessment and patch management including CVSS scoring, vulnerability scanning, patch testing, change management, and compliance reporting.

# Vulnerability Assessment and Patch Management

Introduction

Unpatched vulnerabilities are among the leading causes of security breaches. According to industry reports, a significant percentage of breaches exploit known vulnerabilities that had available patches but were not applied. Vulnerability assessment and patch management form a continuous cycle of identifying, evaluating, prioritizing, and remediating security weaknesses across the enterprise.

This tutorial provides a comprehensive guide to vulnerability assessment and patch management. Topics include CVSS scoring, vulnerability scanning, patch testing, change management, zero-day response, and compliance reporting.

Learning Objectives

By the end of this tutorial, you will be able to:

Conduct vulnerability scans using industry-standard tools
Score and prioritize vulnerabilities using CVSS v3.1
Design and implement a patch management lifecycle
Test patches in staging before production deployment
Manage zero-day vulnerabilities and emergency patches
Generate compliance and risk reports for stakeholders
Integrate vulnerability management with SIEM and ticketing systems

Technical Background

CVSS v3.1 Scoring

The Common Vulnerability Scoring System (CVSS) provides a standardized way to score vulnerability severity.

**Base Metric Group:**

| Metric | Values | Description | |--------|--------|-------------| | Attack Vector (AV) | Network, Adjacent, Local, Physical | How the vulnerability is exploited | | Attack Complexity (AC) | Low, High | Complexity of exploit | | Privileges Required (PR) | None, Low, High | Privileges needed to exploit | | User Interaction (UI) | None, Required | Whether user must act | | Scope (S) | Unchanged, Changed | Whether impact spreads beyond vulnerable component | | Confidentiality (C) | None, Low, High | Impact on data confidentiality | | Integrity (I) | None, Low, High | Impact on data integrity | | Availability (A) | None, Low, High | Impact on system availability |

**Severity Ratings:**

| Score Range | Severity | Color | |-------------|----------|-------| | 9.0–10.0 | Critical | Red | | 7.0–8.9 | High | Orange | | 4.0–6.9 | Medium | Yellow | | 0.1–3.9 | Low | Light green | | 0.0 | None | Green |

**CVSS Calculator Example:**

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

Attack Vector: Network (exploitable remotely)
Attack Complexity: Low (no special conditions)
Privileges Required: None (no authentication needed)
User Interaction: None (no user action needed)
Scope: Unchanged (impact limited to vulnerable component)
Confidentiality: High (full data exposure)
Integrity: High (full data modification)
Availability: High (complete service disruption)

Vulnerability Management Lifecycle

1. Discover          → Asset inventory, vulnerability scanning
2. Prioritize        → CVSS scoring, asset criticality, threat intel
3. Remediate         → Patch, configure, compensate
4. Verify            → Rescan, confirm fix
5. Report            → Executive dashboards, compliance reports
6. Repeat            → Continuous monitoring cycle

Patch Management Process

1. Identify          → Vendor advisories, CVE feeds, scanner results
2. Evaluate          → Applicability, impact, urgency
3. Test              → Staging environment validation
4. Approve           → Change advisory board (CAB) approval
5. Deploy            → Phased rollout (canary → pilot → production)
6. Verify            → Post-deployment validation
7. Report            → Patch compliance metrics

Prerequisites

Asset inventory with hardware and software details
Network access to scan target systems
Staging environment for patch testing
Change management process (CAB)
Ticketing system (Jira, ServiceNow, etc.)

Hardware and Software Requirements

| Component | Requirement | |-----------|-------------| | Vulnerability Scanner | Nessus Professional, OpenVAS, Qualys, Rapid7 Nexpose | | Patch Management | WSUS, SCCM, Ubuntu Landscape, Red Hat Satellite, Ansible | | CVE Feed | NVD, vendor security advisories, CISA KEV catalog | | Ticketing | Jira, ServiceNow, Zendesk | | SIEM | For vulnerability trend analysis |

Step-by-Step Implementation

Phase 1: Asset Inventory

#### 1.1 Build Asset Inventory

Asset Fields:
  - Hostname
  - IP address (internal, external)
  - Operating system and version
  - Installed software and versions
  - Asset owner
  - Business criticality (Tier 1/2/3)
  - Data classification (Public, Internal, Confidential, Restricted)
  - Network segment
  - Cloud provider and region (if applicable)

#### 1.2 Asset Discovery

# Network discovery with nmap
nmap -sV -sC -oA network-scan 10.0.0.0/24

# Active directory query
dsquery * -filter "(&(objectCategory=computer)(operatingSystem=*Server*))" -attr name,operatingSystem,operatingSystemVersion

# Cloud asset inventory
aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,PrivateIpAddress,State.Name,Platform]'

Phase 2: Vulnerability Scanning

#### 2.1 Configure Nessus Scan

Scan Name: Quarterly Internal Vulnerability Assessment
Targets: 10.0.0.0/16, 172.16.0.0/12
Scan Type: Advanced Scan
Credentials:
  - SSH (Linux): key-based auth, sudo enabled
  - Windows (SMB): domain admin account
  - SNMP: community string for network devices
  - Database: read-only account for Oracle/MySQL/PostgreSQL
Plugins:
  - All plugins enabled
  - Safe checks: enabled
  - Port range: default + custom
Schedule: Weekly (incremental), Monthly (full)

#### 2.2 Run OpenVAS Scan (Open Source)

# Start OpenVAS services
sudo gvm-setup
sudo gvm-start

# Create target
gvm-cli create <gmp> <target> <<EOF
<create_target>
  <name>Internal Network</name>
  <hosts>10.0.0.0/24</hosts>
</create_target>
EOF

# Create scan task
gvm-cli create <gmp> <task> <<EOF
<create_task>
  <name>Weekly Vulnerability Scan</name>
  <comment>Weekly internal vulnerability assessment</comment>
  <config id="daba56c8-73ec-11df-a475-002264764cea"/>
  <target id="TARGET_ID"/>
  <schedule id="75eedb22-443a-449e-8e6b-0e1a1c5e2c3c"/>
</create_task>
EOF

# Start scan
gvm-cli start <gmp> <task> TASK_ID

#### 2.3 Authenticated vs Unauthenticated Scans

| Scan Type | Pros | Cons | |-----------|------|------| | Unauthenticated | Fast, no credentials needed, simulates external attacker | Misses local vulnerabilities, more false positives | | Authenticated | Detailed results, fewer false positives, sees local config | Requires credentials, more intrusive |

Best practice: Run authenticated scans on internal assets, unauthenticated on perimeter.

Phase 3: Vulnerability Analysis and Prioritization

#### 3.1 CVSS Scoring Example

Vulnerability: Apache Log4j2 Remote Code Execution (CVE-2021-44228)
CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Base Score: 10.0 (Critical)

Attack Vector: Network - exploitable from anywhere
Attack Complexity: Low - no special conditions
Privileges Required: None - no authentication needed
User Interaction: None - automatic exploitation
Scope: Changed - impacts components beyond vulnerable software
Confidentiality: High - complete data exposure
Integrity: High - complete data modification
Availability: High - complete service disruption

#### 3.2 Prioritization Matrix

| CVSS Score | Asset Criticality | Threat Intelligence | Priority | SLA | |------------|-------------------|---------------------|----------|-----| | 9.0–10.0 | Tier 1 (Critical) | Known exploited (CISA KEV) | P1 – Immediate | 24 hours | | 7.0–8.9 | Tier 1 (Critical) | No active exploitation | P2 – High | 7 days | | 9.0–10.0 | Tier 2 (Important) | Known exploited | P2 – High | 7 days | | 7.0–8.9 | Tier 2 (Important) | No active exploitation | P3 – Medium | 30 days | | 4.0–6.9 | Any | No active exploitation | P4 – Low | 90 days | | 0.1–3.9 | Any | No active exploitation | P5 – Defer | Next cycle |

#### 3.3 CISA Known Exploited Vulnerabilities (KEV)

Check CISA KEV catalog before prioritizing:

# Download KEV catalog
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | \
  jq '.vulnerabilities[] | select(.cveID == "CVE-2021-44228")'

If a vulnerability appears in KEV, elevate priority regardless of CVSS score.

Phase 4: Patch Management

#### 4.1 Patch Testing Process

Stage 1: Download patch from vendor
Stage 2: Verify checksum/signature
Stage 3: Install in isolated test environment
Stage 4: Functional testing (application regression)
Stage 5: Security testing (verify vulnerability fixed)
Stage 6: Performance testing (no regressions)
Stage 7: CAB approval
Stage 8: Production deployment (phased)

#### 4.2 Patch Deployment with Ansible

# patch-servers.yml
---
- name: Apply security patches to Linux servers
  hosts: linux_servers
  become: yes
  vars:
    reboot_required: false
  
  tasks:
    - name: Check for available updates (Ubuntu)
      ansible.builtin.apt:
        update_cache: yes
        cache_valid_time: 3600
      register: apt_result
    
    - name: Install security updates
      ansible.builtin.apt:
        name: "*"
        state: latest
        only_upgrade: yes
      when: apt_result is changed
      register: patch_result
    
    - name: Check if reboot required
      ansible.builtin.stat:
        path: /var/run/reboot-required
      register: reboot_check
    
    - name: Set reboot fact
      ansible.builtin.set_fact:
        reboot_required: "{{ reboot_check.stat.exists }}"
    
    - name: Notify reboot required
      ansible.builtin.debug:
        msg: "Reboot required on {{ inventory_hostname }}"
      when: reboot_required

#### 4.3 Windows Patch Management (WSUS)

1. Install WSUS role on Windows Server
2. Configure synchronization schedule (daily, 2:00 AM)
3. Create computer groups (Test, Pilot, Production)
4. Approve updates for Test group first
5. After validation, approve for Pilot group
6. After validation, approve for Production group
7. Configure automatic updates via Group Policy

Group Policy settings:

Computer Configuration > Administrative Templates > Windows Components > Windows Update:
  - Configure Automatic Updates: 4 - Auto download and schedule the install
  - Scheduled install day: Every Wednesday
  - Scheduled install time: 2:00
  - Allow Automatic Updates immediate installation: Enabled
  - No auto-restart with logged on users: Enabled

Phase 5: Zero-Day Response

#### 5.1 Zero-Day Response Procedure

1. Detection: CVE published, vendor advisory, threat intel alert
2. Triage: Determine if asset is vulnerable (version, configuration)
3. Containment: Apply workaround, restrict network access, WAF rules
4. Remediation: Apply vendor patch or mitigation
5. Verification: Confirm fix applied, vulnerability no longer detected
6. Post-incident: Document lessons learned, update procedures

#### 5.2 Emergency Patch Deployment

Timeline:
  T+0:   Vulnerability disclosed
  T+1h:  Asset inventory check completed
  T+2h:  Exposure assessment (which systems affected)
  T+4h:  Workaround applied (network restrictions, WAF rules)
  T+24h: Patch tested in staging
  T+48h: Patch deployed to production (emergency change)
  T+72h: Verification scan completed

Phase 6: Reporting and Compliance

#### 6.1 Vulnerability Metrics

| Metric | Description | Target | |--------|-------------|--------| | Mean time to detect (MTTD) | Time from vulnerability disclosure to detection | < 24 hours | | Mean time to remediate (MTTR) | Time from detection to fix applied | < 7 days (critical), < 30 days (high) | | Patch compliance % | Percentage of systems up-to-date | > 95% | | Critical open vulnerabilities | Count of unpatched critical vulnerabilities | 0 | | Overdue patches | Patches past SLA deadline | 0 |

#### 6.2 Executive Dashboard Template

Vulnerability Management Dashboard (Monthly)

Total Assets Scanned: 1,250
Vulnerabilities Found: 3,420
  - Critical: 45
  - High: 128
  - Medium: 1,150
  - Low: 2,097
Remediated This Month: 2,890
Patch Compliance: 96.2%
Mean Time to Remediate (Critical): 18 hours
Mean Time to Remediate (High): 5.2 days
Top 5 Vulnerable Products:
  1. Microsoft Windows Server 2016
  2. Apache HTTP Server
  3. OpenSSH
  4. Oracle Java
  5. Adobe Reader

#### 6.3 Compliance Reporting (PCI DSS Example)

PCI DSS Requirement 6: Develop and maintain secure systems and applications

6.1: Identify security vulnerabilities → Monthly vulnerability scans ✓
6.2: Patch critical vulnerabilities within 1 month → Average 5.2 days ✓
6.3: Develop secure applications → Secure SDLC in place ✓
6.5: Address common coding vulnerabilities → SAST/DAST integrated ✓
6.6: Public-facing web applications → WAF deployed ✓

Verification and Expected Outputs

| Check | Method | Expected Result | |-------|--------|-----------------| | Scan coverage | Compare asset inventory vs scanned assets | 100% of assets scanned | | Critical patch SLA | Track days from patch availability to deployment | < 7 days | | Rescan after patch | Run scanner on patched systems | Vulnerability no longer detected | | Rollback test | Verify rollback plan works | System restorable to pre-patch state | | CVE correlation | Match scanner results to CVE database | All findings have CVE references |

Troubleshooting Scenarios

| Issue | Diagnosis | Resolution | |-------|-----------|------------| | Scanner cannot authenticate | Wrong credentials or permissions | Verify credentials, test manually | | False positive | Scanner misidentifies version | Manual verification, mark as false positive in scanner | | Patch breaks application | Incompatible patch | Rollback, contact vendor, test in staging longer | | Scan crashes system | Intrusive plugin on fragile system | Use safe checks, exclude system from intrusive scans | | Patch not detected as installed | Registry/file mismatch | Verify patch installation method matches scanner expectation | | Zero-day with no patch | Vendor hasn't released fix | Apply workaround, network isolation, WAF rules |

Security Best Practices

**Scan continuously:** Weekly authenticated scans on critical assets, monthly on all assets
**Prioritize by risk:** CVSS score alone is insufficient; consider asset criticality and threat intelligence
**Test before deploy:** Always test patches in staging that mirrors production
**Phased rollout:** Deploy to canary group, then pilot, then production
**Maintain rollback plans:** Every patch must have a tested rollback procedure
**Subscribe to advisories:** Monitor vendor security bulletins, CISA alerts, CVE feeds
**Patch third-party software:** Don't forget browsers, PDF readers, Java, and other end-user software
**Document exceptions:** Record and justify any system that cannot be patched
**Automate where possible:** Use configuration management for consistent patch deployment

Enterprise Considerations

**Maintenance windows:** Schedule patching during approved maintenance windows
**Change management:** All patches require CAB approval except emergency security patches
**Regulatory SLAs:** PCI DSS requires critical patches within 30 days; other regulations may vary
**Vendor support lifecycle:** Plan for end-of-support operating systems and applications
**Air-gapped systems:** Use manual patch transfer for isolated networks
**IoT and OT:** Special considerations for industrial control systems that cannot be easily patched
**Container images:** Rebuild and redeploy container images rather than patching running containers

Conclusion

Vulnerability assessment and patch management is a continuous cycle, not a one-time project. By combining regular scanning, risk-based prioritization, tested patch deployment, and measurable SLAs, organizations can dramatically reduce their exposure to known exploits. The key is maintaining visibility across all assets and ensuring critical vulnerabilities are remediated before attackers can exploit them.

Frequently Asked Questions

**Q: How often should vulnerability scans be run?** A: At minimum, monthly full scans and weekly incremental scans. Critical assets may require weekly full scans.

**Q: What is the difference between a vulnerability and a CVE?** A: A vulnerability is a weakness in a system. A CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to a publicly disclosed vulnerability.

**Q: Should I patch immediately when a CVE is announced?** A: Not always. First assess whether your systems are affected (version, configuration), then test the patch in staging before production deployment. For actively exploited zero-days, apply mitigations immediately.

Official Technical References

NVD (National Vulnerability Database): https://nvd.nist.gov/
CISA Known Exploited Vulnerabilities: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
CVSS v3.1 Specification: https://www.first.org/cvss/specification-document
NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management: https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final
OWASP Vulnerability Management: https://owasp.org/www-community/vulnerability-management/