Filter

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.

Filter Definition

For example, you are able to match all Windows entries by defining the following item:

Microsoft Windows

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:

• My Recent
• My Updates
• My Alerts

Filter Optimization

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

Check our vendors and products overview to identify the most popular wording structures to improve your filter.

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:

1. The personal product filter list by a user is read
2. This list is dissected by item (one item per line) ⇒ Microsoft Windows 10 22H2
3. All words in an item are dissected as well ⇒ [ Microsoft, Windows, 10, 22H2 ]
4. The DB engine is looking for vulnerabily entries, which contain all these dissected items in one of the fields software_vendor, software_name, software_version, or software_affectedlist. Some level of fuzziness is used to compensate for similar naming conventions and uncertain version details.
5. If an entry has a full match, this match is made available in the results

Filter Possibilities

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=1 in 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.