Updates

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

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.

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

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