Vendor as a GCVE GNA and decentralized vulnerability publication workflow What it means for a vendor to become a GNA in the GCVE model Across GCVE BCPs, a GNA is treated as a publisher of vulnerability information and related metadata with decentralized operational control: The directory is a trust anchor: “The directory file contains authoritative metadata about GCVE Numbering Authorities (GNAs)” (BCP-01 “Abstract” / “Scope and Purpose”). Publication is decentralized by design: “each GNA has full control over its own publication process” (BCP-03 “Mechanism”). The directory enables discovery: BCP-03 explains that the directory “provides a way to discover the entry points” for collecting vulnerabilities (BCP-03 “Mechanism”). In practical terms, a vendor acting as a GNA is committing to: Operating an endpoint by which its vulnerability records can be pulled (BCP-03). Publishing records in the GCVE-compatible vulnerability record/container format (BCP-05), referencing GCVE identifiers allocated by that GNA (BCP-04). Participating in an ecosystem where consumers verify the directory signature before trusting GNA metadata (BCP-01). Publication model diagram (BCP-01 + BCP-03) flowchart TD %% Source of Truth A[<b>GCVE Directory</b><br/>GNA Metadata] %% The Endpoint subgraph Vendor_GNA [<b>Vendor as GNA</b><br/>Publication Endpoint] B[Discovery URL<br/>gcve_pull_api] D[Vulnerability Records<br/>BCP-05] E[KEV Assertion Objects<br/>BCP-07] end %% Consumers C([<b>Consumers</b><br/>Security Tools / Users]) %% Relationships A -- "Points to" --> B A -. "Root of Trust<br/>(Signatures)" .-> C B --- D B --- E D & E -- "Pull / Synchronize" --> C %% Styling style A fill:#e1f5fe,stroke:#01579b style C fill:#f3e5f5,stroke:#4a148c style Vendor_GNA fill:#fff3e0,stroke:#e65100 BCP-07 KEV assertion format and capabilities Core conceptual capability: exploitation as an attributable, event-level statement BCP-07 §2 explicitly separates vulnerability identity from exploitation: “The KEV format explicitly models exploitation as an event-level assertion linked to a vulnerability identity” (BCP-07 §2). This gives three crucial capabilities for real-world compliance and operations: Attribution: who made the assertion, from what evidence / signal stream. Temporal traceability: when exploitation was first seen and when an organization asserted or updated the status. Plurality: multiple assertions (including disagreement) can exist simultaneously without breaking the vulnerability identifier. Detailed field-level capabilities (BCP-07 §4 “Field Description”) BCP-07 specifies a single JSON object per KEV entry bound to a vulnerability identifier (GCVE or other). The important capabilities are explained below as “what the field enables,” not merely “what it is.” Linking to a vulnerability identity (vulnerability object) vulnerability.vulnId: anchors the assertion to a vulnerability identifier, enabling correlation across records and ecosystems. vulnerability.altId: supports referencing additional identifiers where needed (BCP-07 §4 “vulnerability” object fields). Capability: A vendor can publish a KEV assertion referencing its GCVE record, while other authorities can reference the same or alternate identifiers without requiring a single centralized truth source. Binary KEV status with explicit rationale (status object) status.exploited is the binary core (exploited true/false). status.status_reason is an enum that documents why the status is what it is (allowed values include confirmed, suspected, disputed, historical, unknown) (BCP-07 §4 “status.status_reason”). status.status_updated_at timestamps the last change (BCP-07 §4). Capability: Supports the compliance-relevant “state machine” needed when exploitation is suspected, confirmed, disputed, or later reclassified—without rewriting the vulnerability identity record. Minimal technical characteristics (without becoming threat intelligence) BCP-07 includes a characteristics object (e.g., remote_code_execution, authentication_required, local_access_required) (BCP-07 §4). Capability: Provides enough structured technical signal to prioritize remediation while honoring BCP-07’s intention to avoid full threat intelligence. This is particularly useful where organizations must decide urgency and patch sequencing under time pressure. Temporal semantics (timestamps object) BCP-07 distinguishes: first_seen_at (when exploitation first observed) asserted_at (when assertion was made) potentially additional timestamps such as last seen or related lifecycle (BCP-07 §4 “timestamps”). Capability: Critical for aligning system actions to regulatory clocks. “First seen” is an operational indicator; “asserted at” can align to “became aware” workflows for reporting obligations. Evidence as structured signals with confidence (evidence[] array) BCP-07 defines evidence as a “Collection of independent signals supporting the exploitation claim” (BCP-07 §4 “evidence Array”), including: evidence[].type (enum of evidence origin classes) evidence[].signal (e.g., mass scanning, confirmed compromise, weaponized exploit availability) evidence[].confidence (0.0–1.0 or enum), with a normative statement that confidence “SHALL come from the following confidence evaluation table” (BCP-07 §4, evidence confidence table) evidence[].source as a logical identifier for who/what produced the evidence signal (BCP-07 §4) Capability: Enables machine-consumable “why we believe this is exploited” without requiring disclosure of sensitive raw evidence. Enables downstream automation to weigh assertions differently based on confidence and source. GCVE attribution metadata (gcve objects) BCP-07 contains GCVE ecosystem attribution metadata (including references to origin UUIDs, GNA IDs, and object UUID capture) (BCP-07 §4 “gcve Object” references). Capability: Supports traceability and deduplication across decentralized publication, making it feasible to keep multiple independent KEV assertions while reliably identifying provenance. “BCP-07 KEV file” capability profile A KEV assertion file (or stream) in BCP-07 format can support: Multiple assertions per vulnerability (different observers, different times, different confidences). Revisions and withdrawals over time via status updates (BCP-07 §2 on revisability). Partial publication: since most fields are optional, publishers can start small and increase fidelity when feasible (BCP-07 §3). Schema validation: BCP-07 provides a JSON schema (BCP-07 §5), enabling CI checks and automated ingestion. CRA obligations relevant to vulnerability handling and exploited-vulnerability reporting This section extracts the CRA clauses most directly relevant to the GCVE capabilities in scope (lifecycle vulnerability handling, public disclosure, updates, and exploited-vulnerability reporting). “No known exploitable vulnerabilities” at market placement CRA Annex I, Part I includes the essential requirement that products be: “be made available on the market without known exploitable vulnerabilities” (Annex I, Part I, point (1)(a)). This obligation is upstream of GCVE (design/development), but downstream transparency mechanisms (publication, disclosure, KEV assertions) can help demonstrate how vulnerabilities discovered post-market are handled. Vulnerability handling requirements (Annex I, Part II) CRA Annex I, Part II imposes explicit lifecycle vulnerability handling requirements on manufacturers, including (non-exhaustive highlights): SBOM and component/vulnerability documentation: Manufacturers shall “identify and document vulnerabilities and components … including … drawing up a software bill of materials … … top-level dependencies” (Annex I, Part II, point (1)). Timely remediation and security updates: Manufacturers must “address and remediate vulnerabilities without delay … by providing security updates” and where feasible provide security updates separately (Annex I, Part II, point (2)). Public disclosure after fixes: Once a security update is available, manufacturers must “share and publicly disclose information about fixed vulnerabilities” and may delay publication only where justified until users can patch (Annex I, Part II, point (4)). Coordinated vulnerability disclosure: “put in place and enforce a policy on coordinated vulnerability disclosure” (Annex I, Part II, point (5)). Facilitate information sharing and provide a reporting channel: Manufacturers must facilitate sharing information about potential vulnerabilities and provide a contact address (Annex I, Part II, point (6)). Secure update distribution and timely dissemination: Secure distribution mechanisms and “disseminated without delay … free of charge … accompanied by advisory messages” (Annex I, Part II, points (7)–(8)). Support period, point of contact, and component reporting (Article 13) CRA Article 13 embeds vulnerability handling and transparency obligations operationally: Vulnerability handling across the support period: “Manufacturers shall ensure … that vulnerabilities … are handled effectively … in accordance with … Part II of Annex I” (Article 13(8)). Single point of contact for vulnerability reporting: “designate a single point of contact … including … reporting on vulnerabilities” (Article 13(17)). Reporting vulnerabilities in integrated components and sharing fixes upstream: Manufacturers must report vulnerabilities to component maintainers and share code/documentation for fixes “where appropriate in a machine-readable format” (Article 13(6)). Reporting actively exploited vulnerabilities (Article 14) The compliance-critical “actively exploited vulnerability” reporting requirement is explicit and time-bounded: Duty to notify: Manufacturers must notify “any actively exploited vulnerability” to the coordinator CSIRT and ENISA via the single reporting platform (Article 14(1)). Timeline requirements: “within 24 hours of the manufacturer becoming aware” (early warning) (Article 14(2)(a)) “within 72 hours” (vulnerability notification) (Article 14(2)(b)) “no later than 14 days after a corrective or mitigating measure is available” (final report) (Article 14(2)(c)). Article 14 also defines parallel timelines for severe incidents (Article 14(3)–(4)), which can be supported by similar internal data models but are not directly a “vulnerability publication” concept. Mapping GCVE functionality to CRA obligations Analytical mapping narrative GCVE does not replace CRA legal obligations, but it can support CRA compliance by providing: A normalized, machine-readable vulnerability identity and publication layer (BCP-04, BCP-05, BCP-03). A structured representation for actively exploited vulnerability assertions (BCP-07), which is conceptually aligned with Article 14’s “actively exploited vulnerability” reporting trigger. A trust-anchored directory and discovery mechanism (BCP-01) that supports consistent consumption and verification of vendor-published vulnerability data. A key alignment is the CRA’s obligation to “share and publicly disclose information about fixed vulnerabilities” (Annex I, Part II, point (4)). GCVE-BCP-05’s recordType values (advisory, update, analysis, etc.) and relationships model allow manufacturers to publish an advisory and later publish updates/corrections, without losing linkage. Another critical alignment is CRA Article 14’s duty to report exploited vulnerabilities quickly. BCP-07’s separation of (a) exploitation status and (b) evidence and timestamps supports creating an internal, auditable exploitation record for each vulnerability that can drive the 24h/72h/14d notifications while also enabling public consumption where appropriate. Comparison table: GCVE features vs CRA obligations | CRA obligation (exact hook) | What CRA requires (summary) | GCVE capability (BCP) | How GCVE supports | Coverage | |---|---|---|---|---| | Annex I, Part I, (1)(a) | Product placed without “known exploitable vulnerabilities” | GCVE publication & identification (BCP-04/05) | Indirect: supports post-market transparency and tracking; does not enforce secure-by-design | Partial | | Annex I, Part II, (5) | “policy on coordinated vulnerability disclosure” | Vulnerability handling guidance (BCP-02) | Provides process guidance (intake → remediation → coordinated publication) that can be operationalized by vendors | Partial (process guidance, not regulation) | | Article 13(17) | “single point of contact” for vulnerability reporting | GNA publisher role + directory discovery (BCP-01/03) | Directory + publication endpoints complement contact point by publishing authoritative advisories and updates | Partial | | Article 13(6) | Report vuln to component maintainer; share fix code/docs “machine-readable” | Container format + publication (BCP-05/03) | GCVE records can reference affected components and publish machine-readable advisories; upstream sharing is organizational but GCVE helps structure | Partial | | Annex I, Part II, (2) | Remediate without delay; provide security updates; separate where feasible | Update publication model (BCP-05 recordType: update) + pull transport (BCP-03) | Enables iterative updates and consumer automation for patching prioritization | Partial | | Annex I, Part II, (4) | Publicly disclose info about fixed vulns; can delay publication to allow patching | recordType: advisory/update + relationships (BCP-05) | Enables publish-then-update cycles; supports delayed disclosure strategies while preserving record linkage | Strong (publication mechanics) | | Annex I, Part II, (8) | Disseminate security updates without delay; advisory messages | Advisory publication (BCP-05) + distribution (BCP-03) | Vendor GNA can publish advisories with remediation info and make them retrievable programmatically | Partial | | Article 14(1)–(2) | Notify “actively exploited vulnerability” with 24h/72h/14d artifacts | KEV assertion format (BCP-07) | Encodes exploitation status, timestamps, evidence, confidence, and provenance; can drive compliance reporting payload generation | Strong for internal/external exploitation records; complementary to the mandated reporting channel | | Article 16 | Use single reporting platform (ENISA/CSIRT workflow) | Not defined by GCVE | GCVE is not the CRA reporting platform; can only support internal structuring and external comms | Gap | Overview of the process and mapping with GCVE capabilities flowchart TD %% Entry Point A([Receive vulnerability report<br/>BCP-02 process]) --> B[Triage & reproduce] %% Triage Logic B --> C{Confirmed?} C -- No --> B_End[Reject / Close Report] C -- Yes --> D[Allocate GCVE ID<br/>BCP-04] %% Main Advisory Path D --> E[Create advisory record<br/>recordType=advisory BCP-05] E --> M[Release security update] M --> N[Publish update record<br/>recordType=update BCP-05] N --> F %% Intelligence/KEV Path (Parallel) D --> H{Exploitation observed<br/>or credible?} H -- Yes --> I[Create KEV assertion<br/>BCP-07] I --> J{Meets CRA threshold?} J -- Yes --> K[CRA Article 14 notifications<br/>24h/72h/14d via Art 16 platform] J -- No --> L[Flag as suspected/disputed<br/>Monitor for evidence] K & L --> E %% Publication and Consumption F[Publish via GNA endpoint<br/>BCP-03] --> G[Users/consumers pull records<br/>Verify signature BCP-01] %% Styling style A fill:#f9f,stroke:#333,stroke-width:2px style G fill:#bbf,stroke:#333,stroke-width:2px style K fill:#f66,stroke:#333,stroke-width:2px