How it works / Anatomy of a CVE

Anatomy of a CVE

A CVE is an ID for a publicly known vulnerability. By the time a scanner shows you one, it has passed through a lot of hands.

🔒 Behind closed doors
A bug is found and reported
ResearcherThis input freezes the server.
MaintainerConfirmed. We'll ship a fix soon.
steps 01–03 ↓
It gets a number and a fix
CVE-2024-XXXXX
Reserved, not public yet
✓ patched in 2.4.0
steps 04–06 ↓
↓ Disclosure day
Out in the open
Databases copy it and score it
NVDCVSS 7.5 · High
GitHubHigh
OSVlisted
Affected: < 2.4.0
steps 07–08 ↓
Your scanner sounds the alarm
⚠ High severity
some-lib@2.3.0
is vulnerable. Upgrade now.
step 09 ↓
You upgrade
some-lib 2.3.0 → 2.4.0
✓ Alert cleared
step 10 ↓
Illustrative example. The package, CVE ID, and scores are made up.

Step by step

  1. 01DiscoveryResearcher, user, or maintainer

    Someone notices the code doing something it shouldn't. For now it's a bug with a theory attached.

  2. 02ReportFinder → maintainer

    Ideally in private: a SECURITY.md contact, GitHub's private reporting, or a coordinator like CERT/CC. Posting it publicly first makes it a zero-day.

  3. 03TriageMaintainer

    The maintainer tries to reproduce it and decides if it's a security issue at all. “That's documented behaviour” is a common, sometimes correct, answer.

  4. 04CVE ID reservedA CNA

    A CNA (for npm, usually GitHub or MITRE) assigns an ID like CVE-2024-10491. It can do this even if the maintainer disagrees.

    • CVE-2024-10491 · the official ID: year, then a number
    • GHSA-xxxx-xxxx-xxxx · GitHub's advisory ID, often an alias of a CVE
    • CWE-1333 · a bug type, not a vulnerability ID
  5. 05DiscussionFinder, maintainer, sometimes a coordinator

    They agree on how severe it is, which versions it affects, and when to go public. Usually that's quick. When they don't agree, the debate carries on in public issues and PRs, and can end with the record tagged DISPUTED or REJECTED.

    ↳ The discourse investigator reads these conversations: who said what, in what role.

  6. 06Fix, or notMaintainer

    Usually a patched release. Sometimes a workaround, a docs change, or no fix because the behaviour is intended.

  7. 07PublicationCNA, maintainer

    The CVE record goes public with a description and affected versions. Advisories and release notes appear alongside it.

  8. 08EnrichmentNVD, GitHub, OSV

    Each database adds its own severity score and machine-readable version range. They usually match; occasionally one lists different versions.

    ↳ Here, tots reads all three and keeps each source's range, so a mismatch shows up instead of being hidden.

  9. 09Scanners alertScanners, users

    Scanners match your dependencies against those databases and alert on every installed version in range, whether or not your code uses the vulnerable feature.

    • npm audit · reads GitHub Advisory Database
    • Dependabot · reads GitHub Advisory Database
    • OSV-Scanner · reads OSV
    • Trivy · reads GitHub, NVD, and others
    • Grype · reads GitHub, NVD, and others
  10. 10UpgradeEveryone using the package

    The longest stage. Old versions stay installed for years, and every team asks: does this apply to my version?

    ↳ That's the question tots answers.

Real CVEs skip and overlap these steps: a bug is posted publicly first, or a CVE is published before any fix exists. That's why tots checks the code and reads the discussion instead of trusting the record. See how it works →

Glossary

CVE · Common Vulnerabilities and Exposures
The public catalogue of vulnerabilities. Each entry has an ID like CVE-2024-10491 and a short record.
CNA · CVE Numbering Authority
An organisation allowed to assign CVE IDs, such as GitHub, MITRE, or a large vendor.
CVD · Coordinated Vulnerability Disclosure
The practice of fixing a bug privately before announcing it, so a patch exists on day one.
CERT/CC · CERT Coordination Center
Carnegie Mellon's coordinator that helps finders reach vendors. Wrote the CVD guide cited below.
MITRE · The MITRE Corporation
A US non-profit that runs the CVE Program and acts as a CNA of last resort.
NVD · National Vulnerability Database
Run by NIST (US National Institute of Standards and Technology). Adds scores and affected-product data to CVEs.
GHSA · GitHub Security Advisory
GitHub's advisory format and database. The main source for npm packages.
OSV · Open Source Vulnerabilities
Google's open database that merges advisories from many ecosystems, with precise version ranges.
CVSS · Common Vulnerability Scoring System
The 0–10 severity score. Describes the worst case, not your version or setup.
CWE · Common Weakness Enumeration
A list of bug types, e.g. CWE-1333 for slow regexes. Says what kind of bug, not whether it's real.
PoC · Proof of Concept
A minimal script that shows the bug happening. Each tots run tries one in a sandbox against your version.
PR · Pull Request
A proposed code change on GitHub. Fixes and many arguments about CVEs live in PRs and issues.
SBOM · Software Bill of Materials
A list of every package and version in a piece of software. Scanners match it against CVEs.
VEX · Vulnerability Exploitability eXchange
A statement that a product is or isn't affected by a CVE. CycloneDX and OpenVEX are two formats for it.
TIP · Threat Intelligence Platform
A tool that collects security feeds for a security team.
purl · Package URL
A standard package identifier, e.g. pkg:npm/express@5.2.1.
npm · Node Package Manager
The JavaScript package registry. For now, tots only covers npm packages.
HTTP(S) · HyperText Transfer Protocol (Secure)
How the web fetches data. For the CVE record, tots reads NVD, GitHub, and OSV with plain HTTP calls.
OIDC · OpenID Connect
A sign-in standard. Vercel issues short-lived OIDC tokens so tots needs no stored API keys.
AI · Artificial Intelligence
Here: the language models that break down claims, investigate, and judge.

Sources