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
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.

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.

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.

Do you know our Splunk app?

Download it now for free!