Vulnerability Management Overview
Vulnerability management is the continuous, systematic process of identifying, assessing, prioritizing, remediating, and documenting security vulnerabilities in software systems. In modern software development, it is no longer an optional security practice — it is an engineering discipline, a regulatory requirement, and a prerequisite for shipping software to enterprise and EU customers.
This page explains why vulnerability management is essential in software development, how it underpins software compliance with frameworks like the EU Cyber Resilience Act (CRA), NIS2, DORA, and ISO 27001, and how DevGuard implements a risk-based approach that scales inside modern DevSecOps pipelines.
Why Vulnerability Management Matters in Software Development
Software has become the backbone of every industry — and attackers have followed. The threat landscape has shifted from rare, headline-grabbing incidents into a constant, high-volume reality that every development team must address.
The volume of vulnerabilities is exploding. In 2017, fewer than 1,000 new CVEs were published per month. By 2023, the monthly average had doubled to roughly 2,000, and 2025 closed with over 4,000 newly disclosed CVEs per month — roughly 131 every day. The share of vulnerabilities rated "critical" has grown disproportionately, putting pressure on teams to fix more, faster.
Exploitation is faster than ever. Close to 29% of vulnerabilities added to the CISA Known Exploited Vulnerabilities (KEV) catalog in 2025 were exploited on or before the day their CVE was published. Exploitation now accounts for around 20% of all breaches according to the Verizon DBIR 2025 — a 34% year-over-year increase, and a 70% rate in espionage-motivated breaches.
The financial impact is concrete. In Germany alone, cyberattacks caused approximately €206 billion in damages in 2023, with a substantial share traceable to exploited software vulnerabilities. Globally, the security and vulnerability management market reached $17.63 billion in 2025 — a direct reflection of how much organizations now spend just to keep up.
In short: software ships with vulnerabilities, attackers find and exploit them faster than ever, and ignoring this reality is no longer a viable position for a manufacturer placing products on the market.
The Hidden Cost of Doing Nothing
- Breach exposure: 92% of organizations surveyed in the Checkmarx Global Pulse on AppSec 2024 experienced a breach in the prior year tied to vulnerabilities in software developed in-house.
- Knowing risk: 81% of organizations admit to knowingly shipping code with known vulnerabilities — usually because no structured process exists to triage and remediate them in time.
- Alert fatigue: Traditional scanners generate 50–80% false positives, masking real risks and burning out engineering teams.
- Repeat breaches: Organizations with poor vulnerability management are roughly twice as likely to suffer a repeat breach within the same year.
Vulnerability Management and Software Compliance
Software compliance has become the second engine driving vulnerability management. A growing set of regulations now make vulnerability handling a legal obligation, not just an engineering best practice — and the consequences of non-compliance are direct: lost market access, blocked contracts, and fines that scale with global turnover.
Key Software Compliance Frameworks Requiring Vulnerability Management
| Framework | Scope | Vulnerability Management Requirement | Key Date |
|---|---|---|---|
| EU Cyber Resilience Act (CRA) | Products with digital elements placed on the EU market | Documented vulnerability handling, SBOMs, security updates, reporting of actively exploited vulnerabilities | Full application: 11 December 2027 |
| NIS2 Directive | Essential and important entities in critical sectors | Risk management measures, supply chain security, incident reporting, technical vulnerability management | National transposition ongoing since 2024 |
| DORA | Financial entities and ICT third-party providers | Continuous ICT risk management, SBOMs, vulnerability handling | Applies since 17 January 2025 |
| ISO 27001 | Information Security Management Systems | Annex A controls for technical vulnerability management and secure development | Standard reference |
| BSI IT-Grundschutz | German federal and public-sector ecosystem | Documented vulnerability identification and remediation processes | Standard reference |
The EU Cyber Resilience Act in Focus
The CRA is the most consequential European cybersecurity legislation for software ever passed. Starting 11 December 2027, every manufacturer placing products with digital elements on the EU market must demonstrate compliance with Annex I — or lose the right to sell in the EU. Penalties reach up to €15 million or 2.5% of global annual turnover, whichever is higher. Reporting obligations for actively exploited vulnerabilities begin earlier, on 11 September 2026.
The CRA mandates, among other obligations:
- Secure by design and default: products must be designed with cybersecurity built in, not bolted on after the fact.
- Vulnerability handling process: continuous identification, documentation, and remediation of vulnerabilities — including in third-party components.
- Software Bill of Materials (SBOM): machine-readable inventories (CycloneDX, SPDX) for every product release.
- Security updates: provided free of charge, with clear communication to users about security implications.
- Conformity assessment and technical documentation: every scan, every triage decision, every enforced policy must be retrievable for auditors.
These obligations are not aspirational targets. They are the new minimum bar for selling software in Europe — and they map directly to the day-to-day work of a vulnerability management program. For a full breakdown, see the CRA Compliance page.
Why Software Compliance Without Vulnerability Management Is Impossible
Every modern software compliance framework — CRA, NIS2, DORA, ISO 27001, SOC 2, PCI-DSS — converges on the same operational requirement: a documented, auditable process for finding, prioritizing, and fixing vulnerabilities across the entire software supply chain.
Without continuous vulnerability scanning, SBOM generation, and triage documentation, you cannot:
- Prove to an auditor that you know what is inside your software.
- Demonstrate that newly disclosed CVEs have been re-assessed against your past releases.
- Show that risk decisions were made deliberately, by named individuals, on documented evidence.
- Meet the CRA requirement to report actively exploited vulnerabilities on the regulator's timeline.
Vulnerability management is the layer that produces the evidence every software compliance framework demands. Skip it, and compliance becomes a paperwork exercise that will not survive a serious audit.
From Reactive Patching to Risk-Based Prioritization
A naive approach — "patch every critical CVE" — does not scale when 131 new CVEs are published every day. Engineering capacity is finite. The right question is not whether to manage vulnerabilities, but which ones to fix first given limited time and competing product priorities.
Effective vulnerability management combines multiple signals to compute real-world risk rather than relying on a single severity score:
- CVSS (Common Vulnerability Scoring System): standardized technical severity expressed as a base score.
- EPSS (Exploit Prediction Scoring System): probability that a vulnerability will be exploited in the wild within the next 30 days.
- Exploit availability: presence in public databases like ExploitDB, Metasploit modules, or the CISA KEV catalog.
- Reachability and exploitability in your application context: is the vulnerable code path actually called? Are mitigating controls in place?
- Organizational security requirements: confidentiality, integrity, and availability needs of the affected asset.
When these signals are combined, a significant share of vulnerabilities with high CVSS scores re-rank to a lower real-world risk — and a small number of "medium" CVSS vulnerabilities turn out to be the ones actually being exploited. Without this re-ranking, teams spend most of their capacity on the wrong findings while attackers walk through the ones that were ignored.
For a deeper exploration of how risk-based prioritization changes outcomes — including a Sankey diagram showing how CVSS scores re-map once EPSS and exploit data are layered in — see the L3montree analysis Effektive Priorisierung von Schwachstellen.
The Vulnerability Management Lifecycle
A mature vulnerability management program is a continuous lifecycle, not a one-off audit. Each stage produces artifacts that the engineering team and external auditors both rely on.
- Discovery: continuous scanning across source code (SAST), dependencies (SCA), containers, infrastructure-as-code, secrets, and runtime. SBOMs are generated for every build.
- Matching: discovered components and code findings are matched against vulnerability databases (NVD, OSV, GitHub Advisory Database, vendor advisories).
- Risk assessment: each finding is scored using CVSS + EPSS + exploit availability + organizational context.
- Triage: findings are assigned, accepted, mitigated, or marked as false positives. Each decision is recorded with who decided, when, and why — this is the trail auditors look for.
- Remediation: patches, dependency upgrades, configuration changes, or compensating controls are applied. Issue trackers (GitHub Issues, GitLab Issues, Jira) keep security work visible inside the normal development workflow.
- Verification: re-scans confirm the fix; attestations are produced where required.
- Reporting and disclosure: status is shared internally and, where applicable, externally through VEX (Vulnerability Exploitability eXchange) documents and coordinated vulnerability disclosure channels.
Each step generates artifacts — scan logs, SBOMs, VEX documents, triage decisions, signed attestations — that together form the audit trail required by the CRA, NIS2, and ISO 27001.
How DevGuard Approaches Vulnerability Management
DevGuard implements the lifecycle above as a single, open-source platform built into the developer workflow rather than alongside it.
- Continuous scanning across the full stack: SCA, SAST, container scanning, IaC scanning, secret detection, and DAST, integrated into existing CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins).
- Risk-based prioritization: CVSS is enriched with EPSS, exploit availability, component depth, and per-organization security requirements — so the top of the queue reflects actual exploit risk, not nominal severity alone.
- Automated SBOM and VEX: CycloneDX SBOMs and live VEX endpoints are generated per release and continuously matched against newly disclosed CVEs — including retroactive matching against past releases.
- Auditable triage: every triage decision is recorded with timestamp, rationale, and responsible person. This satisfies the "evidence" requirement of CRA Annex I, NIS2 Article 21, and ISO 27001 controls.
- Signed attestations: in-toto attestations and Sigstore signing produce tamper-proof records of the security process — directly usable as conformity assessment evidence.
- Bring your own scanner: SBOM and SARIF ingestion lets teams keep existing tooling (Trivy, Grype, Semgrep, and others) and consolidate findings in one place.
The result is that vulnerability management — and the evidence required to prove software compliance — becomes a natural byproduct of the development process, not a separate program competing for engineering time.
Related Documentation
- Vulnerability Lifecycle — detailed walk-through of each lifecycle stage
- Risk Assessment Methodology — how DevGuard combines CVSS, EPSS, and context
- Vulnerability Matching — how findings are mapped to CVEs
- Mitigation Strategies — patching, dependency upgrades, VEX, and compensating controls
- False Positives — handling noise without losing real risks
- DevGuard & Compliance Frameworks — mapping vulnerability management to CRA, NIS2, ISO 27001
- CRA Compliance with DevGuard — how DevGuard maps to Cyber Resilience Act requirements
- What is DevGuard? — platform overview
Frequently Asked Questions
What is vulnerability management in software development?
Vulnerability management in software development is the continuous process of identifying, prioritizing, remediating, and documenting security vulnerabilities across source code, dependencies, containers, and infrastructure. It is now both an engineering practice and a compliance requirement under regulations like the EU Cyber Resilience Act, NIS2, and DORA.
Why is vulnerability management important for software compliance?
Vulnerability management is the operational layer that produces the evidence software compliance frameworks require. The CRA, NIS2, DORA, and ISO 27001 all mandate documented identification, assessment, and remediation of vulnerabilities — including in third-party components — plus SBOMs and an auditable trail. Without continuous vulnerability management, demonstrating compliance in a serious audit is effectively impossible.
How does the EU Cyber Resilience Act affect vulnerability management?
The CRA makes vulnerability handling a legal obligation for any manufacturer placing products with digital elements on the EU market. From 11 December 2027, manufacturers must document a vulnerability handling process, generate SBOMs, provide timely security updates, and report actively exploited vulnerabilities. Vulnerability reporting obligations begin earlier, on 11 September 2026. Non-compliance can result in fines up to €15 million or 2.5% of global annual turnover.
How should software vulnerabilities be prioritized?
Vulnerabilities should be prioritized based on real-world risk, not CVSS severity alone. Combine the CVSS base score with EPSS (exploit probability), exploit availability (CISA KEV, ExploitDB), reachability in your application, and the organizational security requirements of the affected asset. This typically re-ranks a large share of "critical" CVSS findings to lower real risk — letting teams focus capacity on what attackers will actually exploit.
What is the difference between vulnerability management and vulnerability scanning?
Vulnerability scanning is a single step — detection. Vulnerability management is the full lifecycle: discovery, matching, risk assessment, triage, remediation, verification, reporting, and documentation. Scanning produces findings; vulnerability management turns findings into decisions, fixes, and the audit trail required for software compliance.
Does open-source software fall under CRA vulnerability management requirements?
Yes — manufacturers integrating open-source components owe due diligence and must handle and report vulnerabilities in those components as part of their product. Dedicated "open-source software stewards" have their own, lighter set of policy and cooperation duties under the CRA. Either way, an SBOM and a documented vulnerability handling process are unavoidable.