Skip to content

Require CNA publication via CVE Services API, with accurate timestamps #41

Description

@jgamblin

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

  1. 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.
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions