The CVE Program requires a centralized warning notification mechanism for broadcasting changes to CVE Record formats and validation rules, such as field deprecations.
Warnings are stored in a CVE Program registry and must be managed independently of CVE Record validation. Validation results must include the registered warnings without changing the record’s validation status.
Each warning contains:
- Message ID
- Notification message
- Notification details
- Schema path
- Date added
- Date updated
- Start date
- End date
- Priority
Definition of Done:
- Implement a centralized, JSON-backed warning notification registry.
- Store CVE Program warnings under src/registry/cve-program/warnings.json.
- Provide a public API for adding warnings independently of CVE Record validation.
- Validate warning data before saving it to the registry.
- Persist warnings across library executions.
- Include registered warnings in every Diagnostics validation result.
- Ensure warnings do not change the validation result’s valid, error, message, or details fields.
- Support warning priority and effective start/end dates.
- Provide an idempotent stub-warning script for local development.
- Export warning types and registry APIs from the package entry point.
- Document warning registration and validation-result behavior.
- Add tests covering persistence, registry reload, warning fields, and diagnostic serialization.
The CVE Program requires a centralized warning notification mechanism for broadcasting changes to CVE Record formats and validation rules, such as field deprecations.
Warnings are stored in a CVE Program registry and must be managed independently of CVE Record validation. Validation results must include the registered warnings without changing the record’s validation status.
Each warning contains:
Definition of Done: