False-Positives

Data quality is very important for us. Therefore, our moderation team is investing additional time to determine false-positives and potential duplicates.

Vulnerability Submits

It is the task of our vulnerability moderation team to review all vulnerability submissions and determine if they are correct or not. If they are identified as a false-positive, they will be rejected. No vulnerability entry will be created based on the wrong submit and no further processing will happen.

Rejected submission are accessible via the web interface. But they are embargoed and details remain accessible to selected members of the moderation team only.

Vulnerability Commits

If we are uncertain whether a data point of a vulnerability entry is correct, we add the commit with a low confidence level. The commit overview of an entry allows an user determine such potentially weak data points.

If a commit was wrong, we do either revoke the commit (nullify the confidence level) or deploy a new commit containing the correct data. Commit data is never overwritten nor deleted to provide a reliable commit history.

Vulnerability Entries

If we are uncertain whether a vulnerability is truly existing, we display this in the report confidence fields of the CVSS vectors. If an entry is disputed by a 3rd party, we will flag the entry as such. If we are the responsible CNA to handle the associated CVE, we will add the statement by the disputee.

If an entry was wrong, we will update it properly. If a duplicate was detected, the duplicate entry will be flagged as such and redirect to the prior entry. The prior entry does also link to the duplicate.

If an entry was a false-positive, it will remain accessible and be flag it as false-positive. See VDB-255290 for an example.

If we are the responsible CNA to handle associated CVE, we will revoke the CVE as well and flag it as REJECTED. See CVE-2024-0713 for an example.

Duplicates and false-positives are sometimes hidden from overviews, searches and API requests to reduce the feed noise to a minimum.

CTI Indicator of Compromise

If an IOC is not correct, we will delete the entry which will not be available on the service anymore. It will not be listed on the web site, via the API or anywhere else. All data analysis will not be based on the deleted IOCs anymore. Generated reports will be updates as quickly as possible.

Updated: 05/26/2024 by VulDB Documentation Team