Virtual Fields

VulDB stores data in a database. But for some data points no such storage is approached but a virtual field used instead. This introduces some important advantages.

What are Virtual Fields

Virtual fields are generated on-the-fly whenever an entry is shown. Changes to the representation of virtual fields are not stored in the database.

This approach is used for data points which might require a large number of updates without a real benefit for historization and update alerting. This makes it possible to keep the amount of update noise and wasteful API consumption to a minimum. Especially customers with small quantities of API credits profit from this methodology.

The introduction of new data points is often approached with virtual fields to keep a maximum of flexibility during the rollout. The overview of available data points explains which are used as virtual fields.

Updates of Virtual Fields

As virtual fields are not stored in the database, they by default do not cause an update and will not be published as such via the update streams on the web site, the RSS feeds nor the API.

If you want to renew the entries in an API client, you would have to refetch the specific entries manually. To do so in the official VulDB Splunk app you may use the advanced option to list the desired entries.

Customers are able to enable virtual field updates to get all changes automatically. Enabling this feature might consume much more API credits than before.

Interested in the pricing of exploits?

See the underground prices here!