As a registered user you are able to define custom product filters in your personal settings. These filters can be used in different parts of the service to provide a pre-defined custom view. Filters expect one product per line. A product usually consists of a vendor, product name, and a version number. Not all of these details are necessary.
For example, you are able to match all Windows entries by defining the following item:
If you just want to match Windows 11, then you may add the version definition:
Microsoft Windows 11
It is also possible to add the patch level 11 22H2 to narrow these matches down:
Microsoft Windows 11 22H2
If you want to cover an early release of Windows 10 as well, you would add another line:
Microsoft Windows 11 22H2 Microsoft Windows 10 1607
You will find an overview of the available vendors and products online which is a good starting point to understand the established naming conventions. It is not recommended to use highly specific version filters for minor version details.
Testing Your Filters
It is possible to verify the matching capabilities of the filters in the personal views on the web service:
There are different approaches to optimize filters:
One Product per Line
Do not try to cover multiple products per line:
Microsoft Office Excel 2016
Create two separate items instead:
Microsoft Office 2016
Microsoft Excel 2016
Keep Filters as Simple as Possible
Do not establish highly complex filters containing detail information:
Microsoft Windows 11 22H2 64bit Spanish Edition
Such filters might not work because of too many patterns. If these patterns are not known or stored, the filter will not be able to match. Use a simple product definition instead:
Microsoft Windows 11 22H2
And use these matches afterwards to filter more specificly by platform (64bit) and language (Spanish) if and only if available and necessary.
Use Multiple Wordings to Extend Matching
Some product names are not very much clear and might be established in different forms. Use all known possibilities to increase the matching possibilities:
CheckPoint Firewall-1 Check Point Firewall-1
Inner Working of Filter Matching
VulDB is using a custom database engine to provide unique features like commit histories. This unique structure also requires a custom search engine:
- The personal product filter list by a user is read
- This list is dissected by item (one item per line) ⇒
Microsoft Windows 10 22H2
- All words in an item are dissected as well ⇒ [
- The DB engine is looking for vulnerabily entries, which contain all these dissected items in one of the fields
software_affectedlist. Some level of fuzziness is used to compensate for similar naming conventions and uncertain version details.
- If an entry has a full match, this match is made available in the results
After you have established your filters, you are able to use the custom views as mentioned before. But there are also additional possibilities like:
- Use the parameter
myfilter=1in your API requests to get only the items that match your filter
- Use the RSS feed to generate a custom list of entries matching your filter
- Use the mail alert feature to receive an email once per day to stay up-to-date regarding new entries
Limitations of Filters
Please be aware that product identification and version matching are not perfect. It is not unusual that exact details for vulnerabilities are not disclosed by vendor nor researchers. Sometimes version details are very uncertain, contradicting or even missing. If your filter excepts certain details which are not available, there will be no match. Therefore, we do not recommend using highly precise matching definitions to prevent false-negatives.
It might take some time until you have defined and optimized your filters. But good filters will help you to approach vulnerability management with much more efficiency and confidence.
Filter Access and Changes
Sensitive user information is only available to the user itself (if necessary) and the core database team. The support teams and the web development teams are not able to access this kind of personal user information. If the support team has to handle a case which includes the personal filters, they need to get temporary permission to do so. This permission request is documented, monitored, and revoked afterwards. Having to handle such support cases is very rare (approx. 1-2 per year).
Changes to the personal filter are considered critical and as such they will inform the registered user about the edit via email. These security-relevant notifications will not contain sensitive data about the product list but instead inform about the extent of the differences.
If you do not want such data to be associated with your company directly, we recommend using a generic mail address (e.g. gmail.com) to enforce some kind of disconnect.
Do you want to use VulDB in your project?
Use the official API to access entries easily!