Vulnerability management: The complete guide
Implementing systematic vulnerability management: from detection and prioritization to remediation—using CVSS, EPSS, and patching strategies.
Table of Contents (6 sections)
Every company has vulnerabilities in its IT infrastructure—the question isn’t whether, but which ones and how many. Vulnerability management is the systematic process of identifying, assessing, and addressing these gaps before attackers can exploit them.
What is vulnerability management?
Vulnerability management is a continuous security process that identifies, assesses, prioritizes, and remediates vulnerabilities in IT systems, applications, and networks. It is not a one-time project, but an ongoing operational process.
A vulnerability is a flaw in software, hardware, or configurations that can be exploited by attackers. The best-known database is the CVE system (Common Vulnerabilities and Exposures) maintained by the MITRE Corporation, which catalogs vulnerabilities with a unique ID (e.g., CVE-2021-44228 for Log4Shell).
Distinction: Vulnerability Management vs. Penetration Testing
| Vulnerability Management | Penetration Testing | |
|---|---|---|
| Frequency | Continuous (weekly/monthly) | One-time or annual |
| Method | Automated scanning | Manual exploitation |
| Depth | Broad coverage | In-depth analysis of individual attack paths |
| Goal | Overall overview of attack surface | Proof of exploitability |
| Result | List of vulnerabilities with CVSS scores | Detailed attack report with business impact |
Both methods complement each other: Vulnerability management creates the database, while penetration testing validates the most critical risks.
The Vulnerability Management Lifecycle
Phase 1: Build an Asset Inventory
You can only protect what you know. A complete asset inventory includes:
- Servers (on-premises, cloud, VMs)
- Endpoints (workstations, laptops, mobile devices)
- Network devices (routers, switches, firewalls)
- Applications (web apps, APIs, SaaS)
- OT/IoT devices in production and building automation
Tools for asset discovery: Nessus, Qualys, Tenable.io, Microsoft Defender for Endpoint, OpenVAS
Phase 2: Vulnerability Scanning
Authenticated vs. Unauthenticated Scans:
- Unauthenticated: The scanner views the system from an attacker’s perspective (externally). Faster but less thorough—many vulnerabilities are only visible from the inside.
- Authenticated: The scanner receives login credentials and can analyze the system from the inside. Detects up to 10× more vulnerabilities.
Scan Types by Environment:
Network Scan: All hosts, open ports, service versions, operating system
Web App Scan: SQL injection, XSS, IDOR, CSRF, authentication weaknesses (OWASP Top 10)
Container Scan: Docker images, Kubernetes configurations, registry vulnerabilities
Cloud Scan: Misconfigurations in AWS/Azure/GCP (S3 permissions, IAM, etc.)
Code Scan (SAST): Static analysis of source code for security patterns
Recommended Scan Frequency:
- Critical systems: weekly
- Production servers: monthly
- Endpoints: at least quarterly
- After major changes: ad hoc
Phase 3: Assessing vulnerabilities
The challenge: A typical scan produces thousands of findings. Not all are equally critical. This is where assessment systems come into play.
CVSS - Common Vulnerability Scoring System
CVSS (currently Version 4.0) rates vulnerabilities on a scale from 0 to 10 based on:
| Category | Factors |
|---|---|
| Base Metrics | Attack vector, complexity, required privileges, user interaction, impact on CIA |
| Temporal Metrics | Exploit Availability, Patch Status |
| Environmental Metrics | Protection Need in Own Context |
CVSS Severity Levels:
| Score | Severity |
|---|---|
| 0.0 | None |
| 0.1 - 3.9 | Low |
| 4.0 - 6.9 | Medium |
| 7.0 - 8.9 | High |
| 9.0 - 10.0 | Critical |
Important: A CVSS score alone does not determine prioritization. Log4Shell had a CVSS score of 10.0—but not all systems use Log4j.
EPSS - Exploit Prediction Scoring System
EPSS (developed by FIRST) supplements CVSS with a probability in % that a vulnerability will be actively exploited in the wild within the next 30 days. Data source: real exploit observations from global threat intelligence.
Example: CVE-2022-30190 (Follina, Microsoft MSDT)
CVSS Base Score: 7.8 (High)
EPSS Score: 95.7% probability of exploitation
→ Immediate prioritization despite "only" a High rating
CISA KEV - Known Exploited Vulnerabilities
The U.S. agency CISA maintains a mandatory catalog of vulnerabilities that are actively being exploited. Mandatory for U.S. federal agencies; an excellent prioritization signal for all other organizations. Currently over 1,100 entries.
Prioritization Matrix:
High EPSS Low EPSS
┌─────────────────┬──────────────────┐
CVSS Critical/High │ Patch IMMEDIATELY │ Patch promptly │
│ (24-72h) │ (7-14 days) │
├─────────────────┼──────────────────┤
CVSS Medium/Low │ Patch soon │ Normal cycle │
│ (30 days) │ (90+ days) │
└─────────────────┴──────────────────┘
Phase 4: Prioritization and Risk Assessment
Beyond raw scores, you must consider the business context:
- Is the system accessible from the outside? (Significantly increases priority)
- What data does the system process? (GDPR relevance, protection requirements)
- Are there mitigating measures in place? (WAF, network segmentation, EDR)
- Is an exploit publicly available? (Metasploit module, PoC code on GitHub)
- Is the system in a prod/dev/test environment?
A Vulnerability Risk Rating combines these factors into a practical traffic light scale (Red/Orange/Yellow/Green) for reporting to management.
Phase 5: Resolution and Remediation
Remediation Types:
| Type | Description | When appropriate |
|---|---|---|
| Patch | Apply official vendor patch | Whenever available |
| Upgrade | Migrate to newer version | For end-of-life software |
| Workaround | Mitigation measure without patch | When patch is not (yet) available |
| Compensating Control | Additional security measure (e.g., WAF rule) | When immediate patch availability is impossible |
| Accept | Accept risk (documented) | When risk or effort is very low >> benefit |
Recommended SLA definitions:
Critical: Patch within 24 hours
High: Patch within 7 days
Medium: Patch within 30 days
Low: Patch within 90 days
Phase 6: Verification
After patching, the fix must be verified:
- Re-scan the affected system
- Confirmation that the CVE is no longer detected
- Documentation in the ticket system (JIRA, ServiceNow)
Phase 7: Reporting and Metrics
Key KPIs for vulnerability management:
| KPI | Description | Target Value |
|---|---|---|
| MTTD (Mean Time to Detect) | Average time to detection | < 7 days |
| MTTR (Mean Time to Remediate) | Average time to remediation | SLA-dependent |
| Open Critical Vulnerabilities | Number of unaddressed critical vulnerabilities | 0 |
| Patch Compliance Rate | % of systems with up-to-date patches | > 95% |
| Vulnerability Debt | Trend of open vulnerabilities over time | Declining |
Vulnerability Management and Compliance
NIS2 Requirements
Article 21 of NIS2 explicitly requires measures for addressing vulnerabilities as part of the security concept. These include:
- Regular risk analyses and security audits
- Patch and change management processes
- Vulnerability disclosure policies
BSI IT-Grundschutz OPS.1.1.3
The BSI module OPS.1.1.3 Patch and Change Management defines:
- Requirements for software inventory
- Process for vulnerability assessment
- Test environments for patches prior to production deployment
- Emergency patch procedures for critical vulnerabilities
ISO 27001 Annex A
A.12.6.1 Management of Technical Vulnerabilities requires:
- Timely identification of vulnerabilities
- Risk assessment
- Appropriate mitigation measures
Tooling Landscape
Commercial Scanners
- Tenable Nessus / Tenable.io - Market leader, extensive plugin database
- Qualys VMDR - Cloud-native, good asset management integration
- Rapid7 InsightVM - Strong remediation workflows
- Microsoft Defender Vulnerability Management - Well integrated into Windows environments
Open Source
- OpenVAS / Greenbone - Free alternative for smaller environments
- Trivy - Container and IaC scanning
- OWASP ZAP - Web application scanning
DevSecOps integration (Shift Left)
Developer pipeline:
Write code → SAST (e.g., SonarQube, Semgrep)
Commit → Secret scan (Gitleaks, TruffleHog)
Build → SCA (Dependency Check, Snyk, Dependabot)
Deploy → DAST (OWASP ZAP, Burp Suite Scan)
Production → VM scanner (Nessus, Qualys)
Common Mistakes in Vulnerability Management
- Scanning without authentication - Only ~20% of vulnerabilities are found
- Incomplete asset inventory - Shadow IT and forgotten systems remain unprotected
- Prioritization based solely on CVSS - Without exploit data (EPSS), many misprioritizations
- Patching without testing - Patches can destabilize production systems
- No verification - Patches are applied but not verified
- Reporting to the wrong audience - IT needs tickets; management needs risk trends
- Isolation of results - Vulnerabilities are not linked to incident response
Conclusion
Vulnerability management is the foundation of any serious security program. It combines technical scanning with strategic prioritization and clear processes—from discovery to verification of remediation. Without this continuous process, every other security investment remains ineffective because entry points for attackers remain open.
Sources & References
- [1] NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management - NIST
- [2] CVE Program - MITRE / CISA
- [3] EPSS - Exploit Prediction Scoring System - FIRST
- [4] BSI IT-Grundschutz OPS.1.1.3: Patch- und Änderungsmanagement - BSI
Questions about this topic?
Our experts advise you free of charge and without obligation.
About the Author
M.Sc. IT-Sicherheit mit über 5 Jahren Erfahrung in offensiver Sicherheitsanalyse. Leitet die Durchführung von Penetrationstests mit Spezialisierung auf Web-Applikationen, Netzwerk-Infrastruktur, Reverse Engineering und Hardware-Sicherheit. Verantwortlich für mehrere Responsible Disclosures.