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:
|2.4.0, 2.4.1, 2.4.2, 2.4.3
|2.4.0 to 2.4.3
|alternative (not allowed)
|Upper Limit (including)
|up to 2.4.3
|Upper Limit (excluding)
|Lower Limit (including)
|2.4.0 and newer
|Lower Limit (excluding)
|newer than 2.3.9
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
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.0 etc. which are equal. This does not include other succeeding minor versions like
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.0.x which might equal
<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
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.
Do you know our Splunk app?
Download it now for free!