Criteria and Process for Feed Inclusion in Vulnerability-Lookup

This document defines the criteria for adding new vulnerability feeds to Vulnerability-Lookup.

Feed Inclusion Criteria

A feed SHOULD be considered for inclusion if it meets one or more of the following criteria:

  • If the core developers (e.g. CIRCL) have a strong operational or strategic interest in the data source, the priority for inclusion SHOULD be increased.
  • The feed SHOULD provide a new data source or additional metadata not already available through existing feeds. In exceptional cases, multiple feeds covering similar data MAY be included to provide redundancy (for example, CVE List and the NVD API).
  • The priority of a feed SHOULD be increased if it provides data using an existing, supported format such as the CVE Program format, the GCVE BCP format, or CSAF. Feeds requiring the development of a completely new parser MAY have a lower inclusion priority.
  • The feed SHOULD provide a sufficient level of structure and parsability, in particular for fields intended to be ingested and exposed by Vulnerability-Lookup.
  • Feeds with licenses that allow redistribution SHOULD be prioritized.

Licensing Considerations

  • If the license of a feed does not permit redistribution, the feed MAY still be integrated but MUST be disabled by default.
  • Feeds that cannot be redistributed SHOULD be assigned a low inclusion priority.

Feed Configuration

Vulnerability-Lookup MUST allow users to enable or disable individual feeds depending on their deployment and operational requirements. The core developers SHOULD provide a default set of enabled feeds that is known to be functional and relevant for CSIRT use cases. This default configuration MAY be modified by users to match their specific interests and needs.

1 Like

just for information, the installation section of the documentation includes a sub-section related to the individual activation/deactivation of the feeders: Installation β€” Vulnerability-Lookup
It’s a recent feature.

1 Like

Currently all implemented feeders are enabled by default in this file. Except the emb3d feeder. But now I am thinking that we could have by default disabled the feeders:

  • cnw_known_exploited (ENISA KEV): it is not active
  • VARIoT: it is not active, maybe because the project is over.
  • GSD: no more active. The quality of data is really bad.

I checked the other sources and they are active.

1 Like

If we go a bit further and look at best practice for feed generation, should we go for a BCP in GCVE or update BCP-02 to provide a set of recommendations?