Require CNA publication via CVE Services API, with accurate timestamps
The current CNA Operational Rules do not require that CVE Records be created and updated through the CVE Services API. At least one CNA, MITRE, frequently publishes and modifies records outside that path. This bypasses the validation and audit trail the API is supposed to provide.
The measurable symptom of this is timestamp quality. I pulled every 2025 and 2026 CVE Record from cvelistV5 (github.com/CVEProject/cvelistV5) and checked datePublished and dateReserved for a zeroed time component (T00:00:00.000Z).
- MITRE, all of 2025-2026: 5,905 records, 95.5% zeroed
datePublished, 95.6% zeroed dateReserved.
- MITRE, last 30 days (June 7 to July 6, 2026): 205 records, 84.4% still zeroed. This is not a legacy problem, it's happening this week.
- Every other CNA checked (30 largest by volume, including GitHub, Patchstack, VulDB, Linux, Wordfence, Microsoft, Adobe, Red Hat, Apple, Oracle, IBM, Cisco, ~69,700 records combined): 0.0% zeroed on either field, full stop.
This isn't a platform constraint. Some MITRE records have full millisecond precision (CVE-2026-54424: published 2026-07-04T00:45:24.208Z), while others published the same week are flattened to midnight (CVE-2026-38973, CVE-2026-38976, CVE-2026-38979, all published July 6, 2026 with both datePublished and dateReserved zeroed). Same CNA, same schema, same week, wildly different data quality.
Proposed rule changes
- All CNAs, including MITRE and any CNA of Last Resort, MUST create, update, and publish CVE Records exclusively through the CVE Services API. Direct repository commits that bypass the API MUST NOT be used as a normal publication path.
- All required timestamp fields in a CVE Record MUST reflect the actual wall-clock time of the associated action. A CNA MUST NOT set a static, zeroed, or otherwise fabricated time component to satisfy the field's format requirement.
Why this matters
Timestamps are one of the few fields in a CVE Record that are supposed to be objective and machine-trustworthy. Right now, the largest single source of CVE Records is still shipping fabricated timestamps on 84% of what it published in the last 30 days, while every other CNA in the sample gets this right at 0%. Anything downstream that measures time-to-publish, time-to-update, or disclosure latency (EPSS, CNA scorecards, research like mine) is quietly built on bad data for the biggest chunk of the dataset.
Methodology note: analysis script and full per-CNA breakdown available on request; happy to publish to RogoLabs if useful for the review.
Require CNA publication via CVE Services API, with accurate timestamps
The current CNA Operational Rules do not require that CVE Records be created and updated through the CVE Services API. At least one CNA, MITRE, frequently publishes and modifies records outside that path. This bypasses the validation and audit trail the API is supposed to provide.
The measurable symptom of this is timestamp quality. I pulled every 2025 and 2026 CVE Record from cvelistV5 (github.com/CVEProject/cvelistV5) and checked
datePublishedanddateReservedfor a zeroed time component (T00:00:00.000Z).datePublished, 95.6% zeroeddateReserved.This isn't a platform constraint. Some MITRE records have full millisecond precision (
CVE-2026-54424: published2026-07-04T00:45:24.208Z), while others published the same week are flattened to midnight (CVE-2026-38973,CVE-2026-38976,CVE-2026-38979, all published July 6, 2026 with bothdatePublishedanddateReservedzeroed). Same CNA, same schema, same week, wildly different data quality.Proposed rule changes
Why this matters
Timestamps are one of the few fields in a CVE Record that are supposed to be objective and machine-trustworthy. Right now, the largest single source of CVE Records is still shipping fabricated timestamps on 84% of what it published in the last 30 days, while every other CNA in the sample gets this right at 0%. Anything downstream that measures time-to-publish, time-to-update, or disclosure latency (EPSS, CNA scorecards, research like mine) is quietly built on bad data for the biggest chunk of the dataset.
Methodology note: analysis script and full per-CNA breakdown available on request; happy to publish to RogoLabs if useful for the review.