rfd: Introduce a Validation Library

[alilleybrinker]

This RFD describes the need to create a JavaScript library for validating CVE Records.

Rendered

[zmiele]

The versioning of this library would, for clarity and simplicity, be matched to the versioning of the CVE Record Format. Whenever new versions of the Record Format are published, a new release of the validation library with a matching version number would also be published.

One small concern that comes to mind here is that this will require the inverse to be true as well. If there is an issue with the library, we'll be required to bump the version of the schema in order to provide fixes in the validation library. Is that something we're comfortable with? If so, we'll need to keep that in mind when defining the versioning rules for the schema in #418.

[alilleybrinker]

@zmiele hm, that's a fair point. In general, I think that such a binding still makes sense. The schema and the validation library become, in effect, a single product with a single version. Fixes to address bugs would be a patch release for both, whether the error is in the schema or in the library.

[alilleybrinker]

In discussion among the QWG today, we agreed that the negative operational trade-offs for matching versions between the validation library and the Record Format make such a matching commitment not worth it. We can instead document compatibility between the two. I'll amend the RFD.

[alilleybrinker]

Potential requirements for what we want out of the validator library:

• (@ccoffin) Provide clear and descriptive schema validation error reporting for CNAs and other data producers
• (@ccoffin) Provide warnings/notifications for future schema changes (e.g., this property will be deprecated in 6.0)
• (@alilleybrinker) Be usable by both CVE Services and 3rd-party consumers

[jgamblin]

Hi Andrew,

Thanks for putting this RFD together! It’s a very well-thought-out proposal and clearly articulates a growing pain point for the community.

I completely agree that relying solely on JSON Schema is hitting its limits, especially with the introduction of complex fields like packageURL. The schema just isn't expressive enough anymore, and pushing that validation logic into an official, standardized package makes perfect sense.

A few specific thoughts on the proposal:

• Local Validation is Crucial: I strongly support the requirement that this package must run locally without phoning home. Many CNAs and security teams will absolutely refuse to send unreleased, potentially sensitive vulnerability details to an external API just to check if their formatting is correct. Providing an offline, local tool is exactly the right approach to build trust and adoption.
• Versioning Strategy: Tying the validator package version directly to the CVE Record Format version is brilliant. It completely removes the guesswork for users trying to figure out which package version supports which schema iteration.
• Ecosystem Choice: Releasing this as an NPM package (@cve/record-validator) feels like the right move, given its alignment with CVE Services and the broad adoption of JavaScript/TypeScript tooling in this space. Establishing an official @cve (or similarly obvious) scope will go a long way in establishing trust.
• Procedural Updates: Adding a requirement to the RFD template to assess necessary validator updates is a smart, forward-looking way to ensure the schema and the validator don't drift out of sync over time.

Looking forward:
I know the specific API design and requirements are slated for a follow-up RFD, but one thing I’d love to see prioritized in that discussion is developer experience around error messaging. When a record fails validation (especially on custom rules like packageURL parsing or nonsensical version ranges), providing clear, actionable error messages pointing to exactly why it failed and how to fix it will be key to getting developers and stakeholders to love this tool.

Overall, I'm very much in favor of this direction. Great work laying the foundation here!