While some vulnerabilities like omigod would have CVE IDs referenced, others would not be suitable for a CVE (either because of a lack of patch/fixes or because it is fixed automatically by the vendor and no action is required from the customer's perspective).
is there a plan to have a specific tracking ID notation for the open-cvdb project, something like CVDB-2022-xxxx, in the same fashion as CVE IDs, the year would match the year of publication for retro-active assignments .
This would help when referencing and keeping track of specific vulnerabilities in advisories, articles, disclosures and so on.
While some vulnerabilities like omigod would have CVE IDs referenced, others would not be suitable for a CVE (either because of a lack of patch/fixes or because it is fixed automatically by the vendor and no action is required from the customer's perspective).
is there a plan to have a specific tracking ID notation for the open-cvdb project, something like CVDB-2022-xxxx, in the same fashion as CVE IDs, the year would match the year of publication for retro-active assignments .
This would help when referencing and keeping track of specific vulnerabilities in advisories, articles, disclosures and so on.