We are much more excited by the idea of creating an ecosystem of forges (and different forge software) than in becoming the new one place where absolutely everything is hosted.

I am, for example, very pleased that even while switching to Forgejo, Fedora decided to keep on self-hosting rather than jumping to us.

To be clear, we’re open for everyone who needs us, especially individuals working on their own smaller projects. But other forges are our friends, not our competition

CRIT is trying to solve a real gap: package-oriented identifiers like CPE/PURL do not model cloud resources well, because cloud resources are runtime objects with provider-specific identifiers and exposure depends on timing, propagation, and remediation state. The draft is explicit about that, and the repo reflects it with dictionaries, schemas, samples, and a validator.

https://github.com/Vulnetix/ietf-crit-spec

They also extend the CVE record format with an x_ record just like GCVE. Yes, the ADP needs become like a major importance for the CVE Program.

CRIT records are naturally produced by parties closest to the platform semantics: cloud providers, specialized researchers, managed detection vendors, and vertical ecosystems. The draft even defines “producer” and “consumer” roles and warns that a producer aggregating multiple upstreams must handle natural-key collisions.

GCVE’s GNA model would help here because it gives each producer a stable namespace and publishing authority. That is cleaner than assuming all high-quality CRIT output ultimately needs to be mediated through the CVE pipeline or one ADP publisher. This would allow faster publication.

Potential improvements in CRIT Internet-Draft

Keep vuln_id generic, not effectively “must be CVE”.Then add:

• aliases[]
• issuer
• scheme or id_namespace (cve, gcve, maybe others)

The draft already defines “vulnerability identifier” generically, even though the examples are CVEs.

Outcome

• CRIT solves the cloud-resource modeling problem
• GCVE solves the decentralized publication and federation problem

@adulau 👍 I've been getting a lot of value out of PyVulnerabilityLookup, VLAI, and sightings for semi-automated vulnerability assessment and prioritization, as well as to support the monthly CTI report our team puts out covering the most notable vulnerabilities of the month.

With VulnMCP, I'll likely be able to centralize everything, connect Claude directly, and stop hammering the Vulnerability-Lookup API with requests from my overly eager and somewhat scattered agents 😄
I'd love to give back to the project but don't feel confident enough on the dev side to contribute that way. Hopefully I'll find another way eventually.

Thanks for everything you do for the community.