These requirements applies to an overall system, a federation of vulnerability sources.
FEDERATION: A global system needs to be operated by many actors, following the same rules and formats for managing vulnerability data. By using the same namespace, collisions in identifiers (CVE) will be avoided.
GLOBAL: We need a multistakeholder solution with global participation. An organisation with representatives from Open Source, multiple industries, military and governments.
FREE: The data shall be freely accessible and replicable worldwide.
INTEROPERABILITY: The API for lookups needs to be standardised, as well as the data format.
NAMING: Vendors and creators need to be in control of their identifiers (DNS name) and the product names, no one else. The system may have a small managed namespace for software creators without a DNS name registration, which of course can’t guarantee any similarity with a natural name in order to avoid collisions.
GLOBAL NAMESPACE: The identifier for a vulnerability needs to be globally unique. Multiple identifiers for the same issue cause confusion and hinders cooperation.
EXTENSIBLE: Data added should not be modified by a third party, but a third party may be able to append their data to an issue. Users needs to be able to choose whom to trust.
TRUSTED and AUTHORITATIVE: There needs to be a high level of trust in the databases, by using digital signatures and transparency systems to monitor the systems for invalid changes in data. This database should be authoritative for legislations and vertical standards world wide. All vulnerabilities must be independently verifiable.
REPLICATION FRIENDLY: The data needs to be replication friendly. One reason is that APIs can be used to track the content of SBOMs for a specific IP/Enterprise and having data locally is much faster. In addition, local data offloads the traffic from the API endpoint.