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.
| Vulnerability Status | What does it mean and what happens? | The role of Greenbone |
| Vulnerability Exists | At some point a security bug enters a software product and no one is aware of the bug. | Greenbone recommends to use tools and processes for the software development that at least prevent standard programming mistakes. We also recommend a security-centric process when integrating third party software modules. This is what we do for our own products. |
| Vulnerability Known | Someone finds the vulnerability in the product. It could have existed for years before discovery. The finder either keeps the discovery secret and tries to exploit the knowledge for personal gain (often a criminal business model) or shares the discovery with the vendor (or security entities) for inclusion to CVE documentation processes. In the first case, the vulnerability may already be exploited for criminal or espionage purposes. At some point an additional person or entity discovers the vulnerability and exposes this information as in the second case. The time-span from introduction of the vulnerability to exposure can be brief in an optimal case or very long in worse case scenarios. | Although it is not Greenbone’s business model to actively search for unknown software vulnerabilities, our security experts may occasionally discover them. We always inform the vendor or respective security entities with all discovered information for further processing. |
| CVE Reserved | The CVE authority issues a reserved CVE number to the reporter of the vulnerability. This way an advisory and a software fix can be prepared with a properly assigned CVE reference. Reserved CVEs are sometimes discussed in public forums for wider awareness of the vulnerability prior to the availability of a solution. This can be beneficial but also holds drawbacks as the security community helps to create detection routines for identifying the risk while malicious actors may engineer exploitation code. Due to the prevalence of malicious actors, vulnerability details may only be shared in restricted circles rather than the wider public. | Greenbone monitors various places where such discussions occur. We are the good guys, and at this point begin implementing tests for our customers that can identify the presence of the vulnerability. Even if there is no solution yet, this helps the customers with isolation or other remediation measures until the vendor can present a viable solution. The preferred and primary detection routine Greenbone strives to implement is a remote unauthenticated test. The quality of detection is dependent on publicly available information (i.e. how much information is exposed about vulnerability exploitation vectors). This information often arrives from the vendor itself or the security community. The quality of detection of the initial test(s) varies, as it depends on what the vendor exposes. In the best-case scenario a non-destructive exploit can be implemented. This may subsequently be accompanied by authenticated tests to increase accuracy. |
| CVE Published | The CVE entry gets an official publication timestamp, a severity classification and further link(s) (ideally to mitigating solutions). CVEs may be updated several times when they are newly published to include the latest research information concerning the vulnerability. | Greenbone updates the security information as new information arrives regarding the CVE. This process is enhanced with various levels of automation for rapid product updates to customers. |
| Product Vendor Advisory | The vendor of the vulnerable product publishes the information about the vulnerability and a solution for mitigation. This often entails an updated version or configuration modifications. In some cases it is possible that vendors may not react at all or not provide a solution for a vulnerability advisory. | Greenbone updates security details of vulnerabilities as new information arrives from the vendor. Vendors with a formal process enable us to handle this very quickly. |
| Product-Integration Vendors Advisories | In several cases other vendors are bundling the vulnerable product with their own, such as in supply chain vulnerabilities. This can be operating system vendors like Red Hat or smaller distribution software vendors that utilize a vulnerable software library for their product, as with log4j, for example. These vendors publish their own advisory, which may be timely or occur several weeks later. The difference of the reaction time between vendors for the same vulnerability can be observed and taken into consideration. | Greenbone publishes at least one test for each vendor. This is primarily automated to increase the speed of release time to customers. The majority of these are authenticated tests with a very high quality of detection. |
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.
Example: CVE-2022-1232 (Google Chrome) was first discussed in April 2022, but the official CVE publication was in July 2022. The first Greenbone tests date April 2022, further followed in May 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:
- 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.
- 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.
Example: CVE-2021-44228 (Log4j vulnerability). Greenbone Enterprise Feed offers over 125 tests.
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.
Vulnerability Management: Future Development
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?
