Between a flaw being introduced into code and its remediation on the network lies a race against time. The faster a reliable test becomes available, the shorter the window in which attackers can exploit a vulnerability before it is found and closed. For most known security flaws, the path from a silent flaw to a ready-to-use test in the OPENVAS ENTERPRISE FEED follows a similar pattern.

Key Takeaways
Greenbone does not wait for the official CVE publication. Work on a test starts as soon as a vulnerability becomes known, with the goal of covering prioritized flaws within 24 hours of publication.
Key benefits include:
  • Tests often available before the official CVE publication
  • Over 100,000 vulnerability tests in the OPENVAS ENTERPRISE FEED, updated daily
  • Automated linking to CVEs as soon as they are assigned

What Is the Vulnerability Lifecycle?

The vulnerability lifecycle describes the path a security flaw takes from its unnoticed origin in code, through discovery and formal registration as a CVE (Common Vulnerabilities and Exposures), to the availability of a test that reliably identifies affected systems.

This timeline matters for organizations because the risk of exploitation neither starts nor ends with the CVE publication itself. Comprehensive vulnerability management therefore needs to account for both publicly known and reserved, not-yet-published vulnerabilities.

The Six Stages: From Silent Flaw to Finished Test

Not every vulnerability passes through exactly the same stations, but most known security flaws follow this pattern:

Six Steps Cyber Security Timeline
Stage What Happens Greenbone's Role
1. Vulnerability exists A security flaw enters a software product unnoticed, often through a coding error or an insecure default configuration. Greenbone recommends secure development practices and applies the same principles to its own products.
2. Vulnerability discovered A researcher, attacker, or automated tool finds the flaw. It may have existed unnoticed for years. Any flaws found internally are always reported responsibly to the vendor or the relevant security authorities.
3. CVE reserved A CVE numbering authority assigns a reserved, not-yet-published CVE identifier so that an advisory and fix can be prepared in a coordinated way. Greenbone monitors relevant discussion forums and often starts test development at this stage already, without waiting for publication.
4. CVE published The entry receives an official timestamp, a severity rating, and further links. Later updates are possible. Tests prepared in advance are automatically linked to the CVE number, with new findings incorporated immediately.
5. Vendor advisory published The vendor of the affected software publishes a security advisory, usually with an updated version or configuration guidance. A largely automated process retrieves vendor advisories and creates a test for the feed shortly after.
6. Downstream distribution Operating system or distribution vendors such as Red Hat or Debian bundle the affected component and publish their own, sometimes later, advisories. A dedicated, usually authenticated test is provided for each relevant vendor to increase detection quality.

Vulnerabilities and Exploits in Numbers

Current research shows how much the window between publication and exploitation of a vulnerability has already shrunk:

31%

of all data breaches started with the exploitation of a vulnerability, according to the Verizon Data Breach Investigations Report (2026), the first time in 19 years it has overtaken stolen credentials as the top entry point

43 Days

is the median time to patch according to the Verizon Data Breach Investigations Report (2026), a 34% increase year over year, while attackers keep getting faster

5 Days

is the median time from a vulnerability’s publication to its addition to the CISA KEV catalog of actively exploited flaws, according to Rapid7’s Global Threat Landscape Report (2026), down from 8.5 days

Sources: Verizon Data Breach Investigations Report (2026); Rapid7 Global Threat Landscape Report (2026).

Why One CVE Can Trigger Several Greenbone Tests

The same security flaw often shows up as several tests in the OPENVAS ENTERPRISE FEED. There are understandable technical reasons for this:

Remote and Authenticated Tests

A remote test only needs network access but sometimes delivers indicators only. An authenticated test accesses the installation directly, improving detection quality.

One Component, Many Products

When a vulnerable library ships inside many products, each vendor publishes its own advisory. Greenbone builds a matching test for every affected vendor.

Vendors Move at Different Speeds

Linux distributions and other integrators run their own quality assurance before releasing a fix, resulting in additional, sometimes later, advisories for the same flaw.

Vulnerability Management With Greenbone

A fast, up-to-date feed is only one half of the equation. The other is a solution that reliably runs these tests against your own infrastructure and prioritizes the results by criticality.

Follow a manual added link
Automated vulnerability management for mid-size to large organizations, with a daily updated enterprise feed and CVSS-based prioritization.
Vulnerability management for small businesses and single sites, ready to use within minutes and free to trial for 14 days.

More on vulnerability management

Checklist: Is Your Vulnerability Feed Fast Enough?

A first, practical way to check the speed of your current vulnerability management:

  • Check whether your feed updates daily rather than only weekly
  • Make sure reserved, not-yet-published CVEs are monitored for critical systems
  • Combine remote and authenticated scans to improve detection quality
  • Prioritize by CVSS severity and the prevalence of the affected product
  • Align internal patch deadlines with actual exploit speed rather than rigid standard cycles
  • Run recurring scans on all production systems instead of one-off checks
  • Define who fixes prioritized findings and within what deadline

Frequently Asked Questions About the Vulnerability Lifecycle

Greenbone does not wait for the official CVE publication. Work on a test begins as soon as a vulnerability becomes known, which can be days, and in some cases even months, before the official CVE publication. Once a CVE number exists, it is automatically linked to the matching test.

A reserved CVE already has a fixed identifier but no public details yet. It exists so that an advisory and a fix can be prepared in a coordinated way. Only publication adds a severity rating, description, and further links.

Usually because a remote test and an additional authenticated test are both possible, or because a vulnerable component is part of several products from different vendors, each of which publishes its own advisory.

Distribution vendors run their own quality assurance process before releasing a patched version. Greenbone creates a test once the respective vendor advisory is published, which can be days to weeks after the CVE depending on the vendor.

For prioritized flaws, the goal is delivery within 24 hours of publication. Actual timing depends on the quality of available vendor information and the testing effort required.

The decisive factors are CVSS severity, how widespread the affected product is, and how feasible automation is. A medium-severity flaw in widely used software often gets higher priority than a critical flaw in a niche application.

A vulnerability test is an automated check routine that determines whether a specific vulnerability exists on a scanned system. The OPENVAS ENTERPRISE FEED contains over 100,000 such tests and is expanded with new entries daily.

Yes. In some cases, no CVE exists yet, only a reserved number or a vendor advisory without a CVE assignment. Greenbone can already provide a test in such cases and links it retroactively once a CVE is assigned.

How Fast Does Your Vulnerability Management Respond Today?

Let’s check together how wide the window between publication and closure of a vulnerability currently is in your environment.