The quality of a vulnerability database heavily relies on the update procedures of existing entries. Our vulnerability moderation team is updating such on a daily basis.

Update Priority Definition

We want to keep all our entries up-to-date. This includes several thousand entries, which contain hundreds of data points per entry which are linked to hundreds of sources. As our resources are limited, we have to prioritize certain elements regarding update handling.

The prioritizing of monitoring entries/sources and processing of updates is defined by several factors:

  • SLA agreements with our enterprise customers
  • popularity of products
  • popularity of entries
  • distribution in professional environments
Our enterprise customers are able to establish custom SLA agreements for vendors, products, technologies, and entries. This guarantees the coverage and timeliness of processing.

Update Procedures

Updates of existing entries happen on a regular basis. The different vulnerability data teams are responsible to keep the data fields of the entries up-to-date. To do so, they have to monitor their sources.

We distinguish between two procedures:

  • Old entries are validated: All data is verified if it still holds true. Sources are queried to see of there are any new changes.
  • Sources are monitored for new changes: Sources are reviewed to determine if there are any new changes published affecting existing entries.
Reviewing sources happens 24/7. This might include regular screening of sources. Often there will be batched updates of entry groups (e.g. all Microsoft entries, all entries within a specific time-range, all data fields regarding exploits) happening once a week or once a month.

User-requestes Updates

Registered users are able to commit edits to existing entries via the web interface. All changes are reviewed by the moderation team to provide the expected quality assurance.

Users are also able to request updates for certain entries or entry families. These are prioritized the same way like regular update processing.

Change History

Whenever a change is detected, the affected entry is updated. It is the goal to keep entries as complete and updated as possible.

Edits are reflected in the changelog and the last update timestamp to help users to recognize changes.

We provide data from three different repositories:

RepositoryEditable ByTimestamp Change
MonoblockModerators, UsersYes
Meta DataModeratorsYes
Virtual FieldsModeratorsNo

All changes within the Monoblock and Meta Data are reflected in the field entry_timestamp_change.

تم التحديث: 07/04/2022

Do you want to use VulDB in your project?

Use the official API to access entries easily!