Version Handling

A basic requirement of vulnerability management is accuracy. Correct assignments of affected products and versions are important for confidence. The moderation team is eager to provide the best level of accuracy by searching and comparing all available sources for vulnerability intelligence.

Challenges of Version Details

The quality of this raw data is often not very good or even contradicting. Especially when it comes to information about which version of a product is affected. It is not unusual that different sources list different versions as affected.

We aim to complete version information whenever possible. However, our unlimited coverage of products and vulnerabilities make it often impossible to gather all information in real-time. In this cases an entry gets published without (exact) version details. These will be improved in later update runs.

Such additional effort is prioritized by important, popular, and exposed products. The definition of a specific focus is possible with an SLA agreement by customers.

Preferred Version Syntax

There are also different methodologies to indicate affected versions:

ApproachExampleSymbolizedRemark
List2.4.0, 2.4.1, 2.4.2, 2.4.32.4.0/2.4.1/2.4.2/2.4.3preferred
Range2.4.0 to 2.4.32.4.0-2.4.3alternative (not allowed)
Wildcard2.4.x2.4.*alternative (limited)
Upper Limit (including)up to 2.4.3<=2.4.3fallback
Upper Limit (excluding)prior 2.4.4<2.4.4fallback
Lower Limit (including)2.4.0 and newer2.4.0<=not useful
Lower Limit (excluding)newer than 2.3.92.3.9<not useful
Sub-Ranges2.3-42.3.x, 2.4.xto avoid

VulDB is preferring a list whenever the affected versions are conclusive. This provides the highest data quality and confidence. If raw data is inaccurate or incomplete we are using an upper limit definition if the upper limit of the affected version is known (including) or if the first not affected version is known (excluding).

The problem with range definitions like these is, that the searching within the database becomes hard to do. If an entry notes that up to 8.1 is affected, a search for XP might not match within the database.

Expanding Basic Version Information

To prevent such false-negatives we are expanding versions based on our experience and machine-learning of approved entries with similar structure. Therefore, an entry with up to 2.4.3 would be expanded as 2.4.0/2.4.1/2.4.2/2.4.3.

If a product is not flagged as do not expand in our database, we will always do this for the minor version (here 2.4.x). In this case every minor version is handled in a dedicated way. This is a requirement for products which have independent minor branches (e.g. WordPress, Linux Kernel). In this case to include 2.3.x in the expanding the entry would have to have the definition of up to 2.3.3/2.4.3. Some products are flagged that an expading is allowed for major versions like 2.x.x.

Such an expanding is not that hard if the version numbers are incremented. But some projects have word-based version numbers (e.g. Microsoft Windows), non-linear increments of versions (e.g. Google Chrome), or in-between releases (e.g. betas, release candindates). To handle the expanding of these we enrich our database with an overview of versions. In the case of Microsoft Windows the database holds the version vector [ 'XP', 'Vista', '7', '8', '8.1', '10' ]. If an entry claims that all products are affected up to 10, then all earlier versions are listed too as XP/Vista/7/8/8.1/10.

Working with Wildcards

Under certain circumstances it is not clear which minor versions are affected but the major release tree is known. This is declared as 22.0.x for example.

If we define 22.0, we mean 22.0 and 22.0.0 etc. which are equal. This does not include other succeeding minor versions like 22.1 or 22.0.1 There might be very rare cases where 22.0 might also include 22.0.1. This happens if a vendor suddenly changes the versioning format and we do not realize this. This almost never happened in the last 25 years. If we observe such an anomaly we will update the entry accordingly.

Unknown ranges are defined as 22.x or 22.0.x which might equal <23.0 or <22.1.0 respectively. If we know the maximum minor version which is included, we use <=22.0.11 to provide more accuracy thanks to the known upper limit.

In the API fields we always use up to (including) and never prior or up to (excluding) at the moment. However, but these variants might get mentioned as textual representations in the summaries under certain circumstances (e.g. if we only know the fixed version but not the affected version).

Handling Changes outside regular Releases

Some projects do not or not always publish an official release of their software. Instead they use an incremental approach with commits to apply changes to the code base.

If a vulnerability is affecting a specific commit or multiple commits outside regular releases, the commit identifiers are used as version information. Otherwise commit identifiers are usually just mentioned as advisory identifiers or patch identifiers.

If the commit is not flagged with an identifier then the availability date of the update is used as version identifier.

Multiple Products merged into one Entry

Sometimes a vulnerability affects multiple products which requires an individual grouping. If the version information of the products differs entirely, a vulnerability entry will not contain version details or just provide the version details of the most prominent product affected. Additional product-specific details might be mentioned in the field software_affectedlist.

Limitations of Automated Processing

Nevertheless, we do not recommend using version data in fully-automated processing in business-critical systems. The data quality and accuracy might not be high enough to do so. This is not a specific problem of VulDB but of vulnerability disclosure and management in general. Not all researcher and vendors disclose exact version details.

Our data teams try to collect data from various sources (e.g. advisories, exploits, patches) and engage active analysis for major entries to fill in the gaps. But having a vulnerability database with version details fully complete is just not possible in this day and age.

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!