Updates

The quality of a vulnerability database heavily relies on the update procedures of existing entries. Our vulnerability data 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 dynamic 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 obligations
popularity of products
popularity of entries
distribution in professional environments
interest of attackers (risk/threat)
accessibility of data

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:

Repository	Editable By	Timestamp Change
Monoblock	Moderators, Users	Yes
Meta Data	Moderators	Yes
Virtual Fields	Moderators	No

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

Uppdaterad: 07/08/2024 förbi VulDB Documentation Team

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!

◂ TidigareÖversiktNästa ▸