From CVE to Management Feed: The Vulnerability Timeline

Vulnerabilities can differ greatly, however share similarities in the timeline from their discovery to documentation and a solution. The development and refinement of vulnerability tests are an essential part of this timeline and a key activity of Greenbone.

Below is the timeline for the majority of known vulnerabilities.

FAQ

How is it possible that a Greenbone test is published months prior to the respective CVE?

Greenbone does not wait for an official CVE publication. We begin working on vulnerability tests as soon as we are aware of a vulnerability. This may be measured in days, however we’ve also experienced delays in months of time until the official CVE publication. We can often link a reserved, yet unpublished CVE, however there are also cases where not even a CVE exists but is reserved and the test is in our Feed. We maintain our tests so that once a CVE exists, they are linked in our tests.

Timeline showing that Greenbone began testing CVE-2022-1232 in April 2022, months before its official publication in July 2022

Why are there so many Greenbone tests for the same vulnerability?

There are two main reasons why we have multiple tests for the same vulnerability:

  1. A test can be done from the outside as well as from the inside. The tests from the outside (also called remote checks) are simple to execute due to the scanner only requiring network access to the scanned system. Some have a high quality of detection due to the vulnerability or the tested service exposing very concrete properties. Some tests are limited to less reliable components of a service, delivering only indicators but not definitive proof. Tests from the inside typically have a higher quality detection method because they may access the software installation at its base and do not rely on external indicators. These types of scans require authentication to the target system.
  2. A vulnerable product is part of several other products or operating systems. Think of software libraries or products that are a standard part of operating systems. In this case the vendors issue their own security advisory including information about the solution. Greenbone implements tests for each of these vendors.

LOG4J Vulnerability - Over 125 Tests by OPENVAS ENTERPRISE FEED

Why are the Greenbone tests for Debian/Red Hat/etc published later than the CVE?

Each operating system vendor has their own scheme to prepare updates of third party tools. The patches must pass a quality assessment process, while affected dependencies and modules require further tests before final release of the update. The vendors publish the advisory when a tested solution is ready for distribution. Greenbone uses a mostly automated process to retrieve vendor advisories as soon as they are published to create a test for our Feed. We have experienced delays spanning from days to weeks about multiple advisories for the same vulnerability.

Example: CVE-2022-2509 (a vulnerability in GnuTLS library) was published August 1st 2022. Debian advisory was published August 8th and the SUSE advisory was published on August 18th. Slackware (July 29th) and Fedora (July 31st) were published more timely in this case.

How fast will Greenbone make a test available for a new vulnerability?

All of our heart and motivation is focused on providing vulnerability tests for prioritized advisories within 24 hours of release.

In many cases we meet that goal. In some cases more time is required and we have collected several insights for you regarding our daily challenge for your security:

  • Testing the test: After a new test is developed it is tested to send an alert in case the vulnerability is present and to stay silent if the vulnerability is not present or already fixed. Most of the testing time consists of configuring vulnerable test systems or services. We have a growing test lab of readily available systems to support this process.
  • Research: The reporters of a vulnerability often do a great job and we can implement a test immediately reports become available. Occasionally, we have in-depth questions for an optimal hit rate of our tests and need to research the details or behavior of a product. This requires considerable time to complete in cases where the vendor provides insufficient information.
  • Automation: Full and partial automation helps immensely with accelerating the development. We keep the human brains busy with new challenges while our advisory processing pipelines handle the known standard challenges and repetitive work steps.Flowchart showing vulnerability management leading into three focus areas: testing, research, and automation

How many of the published vulnerabilities is Greenbone covering?

We implement tests aiming to cover all vulnerabilities that are severe or important to our customers. To achieve this goal we are applying the following prioritization scheme:

  • Severity of the vulnerability: Of course the official severity score in the “CVSS” (Common Vulnerability Scoring System) is a relevant criterion. Severe and actively exploited vulnerabilities receive the highest priority.
  • Distribution of the product: A medium severity vulnerability in a wide-spread product such as Microsoft Windows has a higher priority for us than a critical vulnerability in a browser game, for example.
  • Viability for automation: Some product vendors have set up a formal and highly reliable process for security advisories. In such cases our automated routines will process all of the advisories regardless of severity level.

This Could Also Interest You

The Race to Protect from Cyber Attacks

We help you win a race against the attackers. How do we do it?

More