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:
|List||2.4.0, 2.4.1, 2.4.2, 2.4.3||2.4.0, 2.4.1, 2.4.2, 2.4.3||preferred|
|Range||2.4.0 to 2.4.3||2.4.0-2.4.3||alternative|
|Upper Limit (including)||up to 2.4.3||<=2.4.3||fallback|
|Upper Limit (excluding)||prior 2.4.4||<2.4.4||fallback|
|Lower Limit (including)||2.4.0 and newer||2.4.0<=||not useful|
|Lower Limit (excluding)||newer than 2.3.9||2.3.9<||not useful|
|Sub-Ranges||2.3-4||2.3.x, 2.4.x||to 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
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
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
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.
Are you interested in using VulDB?
Download the whitepaper to learn more about our service!