The CVE Program

A CVE ID is the closest thing the security field has to a permanent public record of a vulnerability — and of who found it. When a hiring manager, a bounty platform, or a program like Anthropic's Cyber Verification Program asks for "a track record of reported vulnerabilities," a CVE record with your name in the credits field is the most checkable answer there is. The CVE Program is the machinery behind those IDs: who can assign them, how records are structured, and how a reporter gets credited. This lesson teaches the machinery from the program's own documentation, because the record you will one day appear in is a formal document and you should understand its fields before your name is in one.

Level 3 · Apply — do it unaided on an unfamiliar authorized target, and explain why it worked and what would have stopped it

Real CVE record fetched via CVE API 2026-10-09 · fictional request worksheet; no real submission

1. Where this shows up

A CVE ID is the closest thing the security field has to a permanent public record of a vulnerability — and of who found it. When a hiring manager, a bounty platform, or a program like Anthropic's Cyber Verification Program asks for "a track record of reported vulnerabilities," a CVE record with your name in the credits field is the most checkable answer there is. The CVE Program is the machinery behind those IDs: who can assign them, how records are structured, and how a reporter gets credited. This lesson teaches the machinery from the program's own documentation, because the record you will one day appear in is a formal document and you should understand its fields before your name is in one.

2. Before you start

• You have completed c-cvd. Never request a CVE ID before the disclosure process is underway — the ID is the public identifier for a coordinated disclosure, not a race to claim a bug.
• You can read JSON comfortably (the record format is JSON).
• Primary reference: cve.org — the program's own site. This lesson's facts were verified there on 2026-10-09; re-verify before you act on them, because the program's scale changes.

3. How it works

What a CVE is. A CVE (Common Vulnerabilities and Exposures) entry is a public identifier — CVE-YYYY-NNNNN — plus a structured CVE Record describing one vulnerability. The program's mission, in its own words, is to "identify, define, and catalog publicly disclosed cybersecurity vulnerabilities." The ID is the handle the whole industry uses to talk about the same flaw: scanners, advisories, the KEV catalog (CISA's list of CVEs with confirmed active exploitation — the catalog c-vuln-ecosystem teaches in full), and your future write-ups all reference it.

What a CNA does. CVE Numbering Authorities are the program's federated workforce: vendor, researcher, open-source, CERT, hosted-service, bug-bounty-provider, and consortium organizations authorized to assign CVE IDs and publish CVE Records within their own scopes of coverage. As of the October 2026 check, there are 555 CNAs (552 CNAs plus 3 CNA-LRs) from 43 countries. Joining has minimal requirements — no fee, no contract. Above the CNAs sit Roots (CISA ICS, CERT@VDE, ENISA, Google, INCIBE, JPCERT/CC, Red Hat, Thales Group) and two Top-Level Roots (CISA and MITRE), which handle governance and the cases nobody else covers. A CNA of Last Resort (CNA-LR) — MITRE operates as one — assigns IDs when no other CNA's scope fits.

What qualifies. Not every bug gets a CVE. The program's counting rule, in one sentence: the issue must be a vulnerability with independently fixable security impact — one codebase that can be fixed independently of others, with a real security consequence. A crash with no security impact is not a CVE. Two products sharing one flawed library get one CVE for the library, not one per product. A scanner match on a known issue is not a new CVE (this is one of the brief's hard rules, and the program agrees with it).

Why the rule is "independently fixable." One identifier must map to one fixable unit. If every product bundling a flawed library got its own ID, scanners would drown in duplicates and no deployer could tell which IDs their patch actually resolves. "Independently fixable" keeps the catalog aligned with the work of fixing: one fix, one ID, one thing to verify patched.

How an ID is requested. The path depends on who the vendor is:

1. Confirm it is a vulnerability (independently fixable, security impact) and that no CVE ID already exists for it.
2. Make a good-faith effort to contact the vendor directly — security.txt first, per c-cvd.
3. If the vendor is a CNA, request the ID through them.
4. If not, try the vendor's parent organization, its Root, or a third-party coordinator CNA (CERT/CC and several bounty platforms operate as CNAs).
5. If no CNA path works, request through the CVE Program's web forms at cveform.mitre.org — MITRE as CNA of Last Resort.

The ID is reserved privately first; the record is populated and published to the CVE List (which updates hourly) once disclosure is coordinated. The private-first ordering is load-bearing: a public reservation for an unpatched flaw is a pointer attackers can read. The ID exists so the industry can coordinate around it; the record goes public when the coordination allows.

The record format. CVE Records use the CVE Record Format, currently version 5.2.0 (CVE Services 2.8.5), as JSON. The structure: cveMetadata (the ID, the assigner, the state — PUBLISHED, RESERVED, REJECTED), a containers.cna block (the assigner's content: descriptions, affected products and versions, references, metrics, and credits), and optionally containers.adp (Authorized Data Publisher enrichments added later). The format, in the program's words, "normalizes and enriches how CVE information is presented, and adds optional data fields such as: severity scores, credit for researchers, additional languages, affected product lists."

How a reporter is credited. The credits array lives in the CNA container. Each entry has a lang (BCP 47 language code, required — BCP 47 is the standard that assigns short tags to languages, en, en-US, so the record says which language the credit text is written in), a value (the credit text, required), and an optional type naming the role: finder (identifies the vulnerability — this is the one that puts the researcher's name in the permanent record), reporter (notifies the vendor/CNA), analyst, coordinator, remediation developer, remediation reviewer, remediation verifier, tool, sponsor, or other. The type is optional — real records often carry just the text — but when you are the finder, ask for type: finder explicitly. That field is your name in the permanent record.

Worked example: reading CVE-2021-44228

Fetched from the CVE API on 2026-10-09 (transcript: runs/c-cve-program.log). The record for Log4Shell:

• cveMetadata: ID CVE-2021-44228, state PUBLISHED, assigner apache — the Apache Software Foundation is a CNA and assigned its own ID.
• credits: one entry — {"lang": "en", "value": "This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team."} No type field (it is optional). This is what a credit looks like in the wild: plain text, permanent.
• affected: vendor "Apache Software Foundation", product "Apache Log4j2", versions from 2.0-beta9 marked affected.
• references: 53 — advisories, patches, analyses.
• metrics: the CNA container's metrics block is sparse here — a preview of the next lesson's problem, which c-vuln-ecosystem takes up: the CNA's record is the default source of truth, and what the CNA does not provide, nobody may.

Note what this teaches: the researcher (Chen Zhaojun) is credited in the vendor's record, assigned by the vendor CNA, after a coordinated disclosure. The whole Stage C pipeline — find, disclose, record, credit — is visible in this one JSON document.

4. Walkthrough

Half runnable, half worked case. Transcript: runs/c-cve-program.log (2026-10-09).

1. Fetch a real record. curl https://cveawg.mitre.org/api/cve/CVE-2021-44228 — the run returned HTTP 200, 18,335 bytes. Identify: the assigner CNA (apache), the credits array and each entry's type (here: no type — text only), the affected-product block, the metrics block, the reference count.
2. Apply the qualification test. For a fictional finding (the Harborlight Books IDOR from c-cvd): is it independently fixable? Yes — one codebase, one fix. Security impact? Yes — cross-user data exposure. Already has an ID? Search cve.org — no. It qualifies.
3. Walk the request path. The vendor (Harborlight Books) is fictional and not a CNA. The path: good-faith direct contact (done in c-cvd) → no vendor CNA → no applicable Root → coordinator CNA or cveform.mitre.org as CNA of Last Resort. Write down which path you would take and why, before touching any form.
4. Draft the credits entry. For yourself as finder:

   {"lang": "en", "type": "finder", "value": "Discovered and reported by <your name>."}

This is the exact shape the schema accepts (lang and value required, type from the enum). Drafting it now means you will ask for it correctly later.

1. Fill the request worksheet. Product, vendor, versions affected, vulnerability type, attack vector in plain words, impact proven, disclosure timeline, your contact. This worksheet becomes the CVE form submission — write it once, carefully.

Not run by us: no real CVE request was submitted — the worksheet is fictional and stays fictional. The program's forms are for real disclosures only.

5. On your own

Task: Pick any CVE from the KEV catalog (see c-vuln-ecosystem for the catalog). Fetch its record from the CVE API. Produce a one-page "record autopsy": the assigner CNA and what that tells you about who found/fixed it, the credits array (who is credited, with what type), what the affected block pins down, and what is missing from the record that you would want as a defender. Then fill a complete request worksheet for a second, fictional finding of your choice.

Success test: Your autopsy correctly identifies the assigner, quotes the credits entry exactly, and names at least one consequential gap in the record (missing weakness, missing product version bound, vague description). Your worksheet answers, with no CNA follow-up needed: the exact product and versions affected, the vulnerability type in plain words, the independently-fixable argument, the proven impact, the disclosure timeline with dates, and your contact. If any of those six is missing, the worksheet fails — fix it before it becomes a real submission.

6. Where it goes wrong

• Requesting before disclosing. A CVE ID for an unreported flaw is a public pointer to an unpatched vulnerability. The disclosure comes first; the ID follows the coordination.
• The CNA-scope miss. Requesting from a CNA whose scope does not cover the product wastes weeks. Read the CNA's scope before you write.
• Duplicate requests. Two CNAs, one flaw, two IDs — the program then has to merge or reject. Search first, then request once, through one path.
• Not asking for the credit. The credits field is optional and the CNA will not always add it unprompted. Ask explicitly, with the exact text and type: finder, during coordination — not after publication.
• Confusing the ID with the analysis. A CVE ID is an identifier, not a severity judgment, not a confirmation of exploitability. The record says what; the scoring and catalog lessons say how bad and how likely.
• Treating REJECTED as failure. Records get rejected when the issue does not meet the bar (not independently fixable, duplicate, not a security issue). A rejection is the program working, not a verdict on your skill.

7. Read the source

1. cve.org — Program Organization / CNAs (cve.org/ProgramOrganization/CNAs) — what CNAs are, the Roots, the current scale (555 as of the October 2026 check — re-check; the number moves). Read the whole page; it is short.
2. cve.org — CVE Services (cve.org/AllResources/CveServices) — the record format (5.2.0), the workflow (reserve → populate → publish hourly), the researcher-credit field, the test environment. Read the Record Format and Workflow sections; skip the API-reference sections on first pass.
3. CVEProject/cve-schema on GitHub — the actual JSON schema. Read the credits definition and the CNA container structure; skip the ADP container definition on first pass — learn the CNA container (the assigner's content) before the enrichment containers. This is the document your future credit lives in — know its shape.

At most three free resources for going deeper: the RedHatProductSecurity/CVE-HOWTO repository (a researcher-oriented request walkthrough); the CVE Program's request web forms at cveform.mitre.org (read the form fields before you ever need them); the OpenSSF finder guide's "Getting a CVE ID" section (the open-source path, from c-cvd's reading).

8. Check yourself

1. A flaw affects two products that bundle the same vulnerable library. How many CVE IDs should exist, and why — what is the "independently fixable" rule doing in this answer?
2. You found a flaw in a small vendor's product. The vendor has no security contact and is not a CNA — and a second researcher, unaware of your work, is about to request an ID for the same flaw through a different CNA. Explain the two failure modes this creates (duplicate IDs; a public reservation before coordination), then lay out the request path you take to avoid both — including where MITRE as CNA of Last Resort enters and what you must establish before touching any form.
3. A CVE record credits "the security team at Example Corp" with no type field. What does the schema say about that entry — valid or invalid, and what is lost by omitting the type?
4. Why does the program publish the ID reservation privately first and the record only after coordination? What harm does each ordering prevent?
5. Your CVE request was rejected as a duplicate of an existing ID. Name two things you should have done before requesting, and what you do now.

9. Prove it

Artifact: the record autopsy (one page) plus the completed request worksheet for a fictional finding, with the credits JSON drafted. Publish the autopsy on your blog or GitHub — it demonstrates you can read the industry's core artifact.

Honest claims after this lesson: you can read any CVE record and explain every field; you can determine whether a finding qualifies for an ID; you can walk the request path without getting lost. Cannot yet claim: a CVE credit — that requires a real finding, a real disclosure, and a real vendor. This lesson is the map, not the territory.

10. Leads to

• c-cvss — the metrics block in the record: how severity scores are actually computed, by hand.
• c-vuln-ecosystem — what surrounds the record: weakness catalogs, exploit evidence, and where enrichment comes from now that NVD enriches only prioritized CVEs.
• Stage D red-team and DFIR tracks read CVE records daily; this lesson is their prerequisite vocabulary.