A CVE - Common Vulnerabilities and Exposures - is a unique, standardized identifier assigned to a specific publicly known cybersecurity vulnerability, formatted as CVE-YYYY-NNNNN. In practice, it's a shared reference number, so a vendor's security bulletin, a scanner's alert, and your own risk assessment all point at the same flaw, in the same piece of code, without anyone having to re-describe it from scratch.
In 1997, a small networking company called Treck wrote a TCP/IP stack for embedded devices. Nothing dramatic - just code to handle network connections on hardware too small to run a full operating system. Over the next two decades, that stack got licensed, bundled, and quietly baked into products across the industry: printers, industrial controllers, medical infusion pumps, building automation systems. HP shipped it. Schneider Electric shipped it. Intel, Rockwell Automation, Caterpillar, Baxter - more than 50 vendors in total, none of whom necessarily even knew the others were using the same code. In 2020, researchers at JSOF found 19 vulnerabilities in that stack, four of them critical, CVSS scores above 9, remote code execution. They called it Ripple20, and the name is the point: one flaw, dropped into the water in 1997, rippling out through supply chains for twenty years before anyone could name it, count it, or patch it. JSOF's own estimate put the number of affected devices in the hundreds of millions. Nobody knows the real number, because nobody had a list of what was running Treck's code until JSOF told them.
That's the entire problem a CVE tracking process exists to solve: not "is our code secure," but "do we even know what's in it, and would we recognize a public vulnerability report as ours if we saw one."
Key terms, before we go further
This article uses a lot of acronyms and names, and most of them only make sense once you know what they stand for. Here are the main ones, in plain language, so nothing below requires you to already know the field. Skip ahead if you don't need it.
- CVE (Common Vulnerabilities and Exposures) - a unique ID for one specific, publicly known vulnerability, formatted CVE-YYYY-NNNNN.
- CWE (Common Weakness Enumeration) - a category of flaw, like "hard-coded credentials" or "out-of-bounds write." A CWE is the type; a CVE is one real instance of that type, in one specific product.
- CVSS (Common Vulnerability Scoring System) - a 0-10 severity score for a vulnerability, based on things like how complex an attack is and what it can do if it succeeds.
- EPSS (Exploit Prediction Scoring System) - a daily-updated probability, 0 to 1, that a given CVE will be exploited somewhere in the next 30 days.
- FIRST (Forum of Incident Response and Security Teams) - an international non-profit community of incident response and security teams. It develops and maintains CVSS and EPSS.
- CISA (Cybersecurity and Infrastructure Security Agency) - the US federal agency for cybersecurity and critical infrastructure protection, part of the Department of Homeland Security. It runs the KEV catalog and, through its ADP enrichment program, adds SSVC data to CVE records.
- KEV (Known Exploited Vulnerabilities) - CISA's list of CVEs with documented, confirmed evidence of active exploitation.
- SSVC (Stakeholder-Specific Vulnerability Categorization) - a decision framework, now carried inside NVD's own data, that recommends what to do (Track, Attend, or Act) instead of just handing you a severity number.
- CPE (Common Platform Enumeration) - a standardized way of naming one specific product and version, so a database like NVD can say which products a given CVE affects.
- PURL (Package URL) - a standardized way of naming one specific software package and version, the identifier most SBOMs and tools like OSV.dev use.
- OSV.dev (Open Source Vulnerabilities) - a free, open database of vulnerabilities in open source software, launched by Google. It aggregates advisories from many ecosystems (GitHub, PyPI, npm, Go, Debian and more) in one format, and lets you look up vulnerabilities by package name and version or by PURL.
- SBOM (Software Bill of Materials) - the full list of software components inside your product. It's what you match published CVEs against.
- VEX (Vulnerability Exploitability eXchange) - a machine-readable statement saying whether a specific CVE affects your product, and why.
- MITRE - the US non-profit that coordinates the CVE Program: it maintains the core list of CVE records and authorizes CNAs to assign IDs.
- NIST (National Institute of Standards and Technology) - the US national standards institute. It runs NVD.
- NVD (National Vulnerability Database) - the US database, run by NIST, that adds a severity score and affected-product data on top of the bare MITRE CVE record.
- CNA (CVE Numbering Authority) - an organization MITRE has authorized to assign CVE IDs in its own scope - a vendor for its own products, a Linux distribution for its own packages, and so on.
- ENISA (European Union Agency for Cybersecurity) - the EU's cybersecurity agency. Under the CRA, it receives manufacturers' notifications of actively exploited vulnerabilities.
- CSIRT (Computer Security Incident Response Team) - a cybersecurity incident response team. Article 14 notifications go to the coordinating CSIRT of the EU country where the manufacturer has its main establishment, and are made available to ENISA at the same time.
- JSOF - an Israeli cybersecurity research company specializing in embedded systems and network stacks. Its researchers found the Ripple20 vulnerabilities in Treck's TCP/IP stack in 2020.
How a CVE gets assigned
No central government office issues CVE IDs. MITRE coordinates the CVE Program, but the assignment work is spread across hundreds of CVE Numbering Authorities (CNAs) - vendors, security researchers, coordination centers, and open source foundations that MITRE has authorized to assign IDs within their own scope. A chip vendor can be a CNA for vulnerabilities in its own SDKs. A Linux distribution can be a CNA for its own packages. When none of those apply, MITRE itself or a designated root CNA assigns the ID.
The ID format is CVE-YYYY-NNNNN: the year the ID was reserved (not necessarily the year the flaw was found or disclosed), followed by a sequence number that can run to five digits or more in high-volume years. The record starts sparse - just an ID and a one-line description - and gets enriched over time with references, affected version ranges, and a severity score.
The life of a CVE, from report to your patch queue
A vulnerability's path to becoming an actionable line item in your risk register runs through several distinct stages.
Discovery and reporting. Someone - a researcher, a vendor's internal team, an automated fuzzer - finds a flaw and reports it through a CNA's disclosure channel, ideally following a coordinated disclosure process (see ISO/IEC 29147 for what a responsible one looks like).
ID reservation and publication. The CNA reserves a CVE ID, and once details are ready to go public - usually coordinated with a vendor patch - the record is published with a description and affected product information.
Enrichment. This is where things get less reliable than most people assume. The National Vulnerability Database (NVD), run by NIST, has historically been the place that adds a CVSS severity score, CPE identifiers for affected products, and reference links on top of the bare MITRE record. In April 2026, NVD shifted to a risk-based triage model: full enrichment is prioritized for vulnerabilities on CISA's Known Exploited Vulnerabilities list, those tied to federal systems, or those falling under Executive Order 14028, and a large backlog of older CVEs was reclassified to "Not Scheduled" for enrichment. The practical effect for a manufacturer: a growing share of newly published CVEs sit with no NVD-assigned CVSS score at all, which means "check the NVD score" is no longer a complete strategy on its own - you need a process that doesn't stall when that field is empty.
Your matching step. This part is all on you. A published CVE only becomes relevant the moment you match its affected-component list against your own inventory - and that match is only as good as the inventory you're matching against. This is the step an SBOM exists to make possible; without one, "matching against your own inventory" is a manual search through your own memory of what you shipped.
Triage and action. Not every match is urgent. This is where CVSS, EPSS, KEV, and SSVC earn their keep, covered next.
CVSS score decoded
CVSS (Common Vulnerability Scoring System) reduces a vulnerability to a single number, 0 to 10, based on factors like attack complexity, privileges required, and impact on confidentiality, integrity, and availability. Most published scores today use CVSS v3.1; CVSS v4.0, published by FIRST in late 2023, refines the model further and separates out threat and environmental context more explicitly than v3.1 did.
The number is a starting point, not a verdict. A 9.8 in a library function your firmware never calls is not more urgent than a 6.5 in your authentication path. CVSS measures theoretical severity in isolation from your specific deployment - it says nothing about whether the vulnerable code path is reachable in your build, whether it's internet-facing, or whether anyone is actually exploiting it in the wild. That gap is why CVSS alone isn't a triage system.
Beyond the score: EPSS, CISA KEV, and SSVC
Three supplementary signals fill the gap CVSS leaves open, and all three are free to use.
EPSS (Exploit Prediction Scoring System), maintained by FIRST, is a machine-learning model that outputs a daily-updated probability, from 0 to 1, that a given CVE will be exploited in the wild in the next 30 days. It's a forecast, not a fact, but it's a useful way to separate the CVEs that are statistically likely to matter from the ones sitting at a high CVSS score with no real-world attacker interest at all.
The CISA Known Exploited Vulnerabilities (KEV) catalog is a different kind of signal: not a prediction, a confirmation. Every entry is a CVE with documented evidence of active exploitation - a CVE ID, evidence of exploitation, and clear mitigation guidance are the standing criteria, originally set out under CISA's Binding Operational Directive 22-01 and carried forward unchanged after that directive was superseded in June 2026 by BOD 26-04. On our own end at Platanor, KEV is one of the first lists we check every single day when triaging what's new - a CVE that lands on that list jumps the queue, whatever its CVSS score says.
SSVC, the newest addition, arrived inside NVD itself. Since 17 June 2026, the NVD API and data feeds carry SSVC (Stakeholder-Specific Vulnerability Categorization) decision data sourced from CISA's ADP enrichment program, alongside a structured list of which product versions a given CVE affects. SSVC differs from CVSS, EPSS, and KEV in one useful way: it factors in decision context, not just severity or exploitation status, sorting a CVE into a recommended track such as Track, Attend, or Act. Where it's available, it slots in right after KEV.
Put together, a workable triage order looks like: is it on KEV (confirmed exploitation, act now) → what does SSVC recommend, where available (decision context, not just severity) → what does EPSS say (statistically likely, worth prioritizing) → what does CVSS say (severity ceiling, useful for ranking within a tier) - not the reverse.
Why this matters more for IoT than for a web app
You patch a web application by deploying new code to a server you control, often the same day a fix ships. An IoT device sits in a customer's building, factory floor, or hospital room, sometimes for a decade, and every patch has to survive an OTA update pipeline, a possible offline period, and a device that might not have been touched by its manufacturer since the day it left the line.
Ripple20 is the sharpest illustration of why the IoT version of this problem is structurally worse. A web framework vulnerability affects services actively run by companies watching their own dependency trees. Treck's TCP/IP stack was baked into firmware images and, in a lot of cases, forgotten - not because anyone was careless, but because a component pulled in through a vendor SDK five build cycles ago doesn't show up on anyone's radar unless something is actively checking for it. Some of the affected devices, per JSOF's own reporting, were still running unpatched years after the disclosure, because no update mechanism existed to reach them, or because nobody at the operating company knew Treck's code was even in the box.
For a manufacturer, the real danger is a critical CVE getting published when you have no mechanism that would ever tell you it applies to a device you shipped three years ago and haven't thought about since.
What CRA requires
The EU Cyber Resilience Act ties CVE tracking to two separate obligations, on two different clocks.
The first is already active. Article 14 requires manufacturers, from 11 September 2026, to notify any actively exploited vulnerability simultaneously to ENISA and their coordinating CSIRT: an early warning within 24 hours of becoming aware of it, followed by a fuller vulnerability notification within 72 hours. You cannot meet a 24-hour clock on a vulnerability you don't know applies to you - which makes an ongoing CVE-matching process, not a periodic audit, the only way to realistically comply.
The second is broader and lands later. Annex I Part II, in full application from December 2027, requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products," alongside obligations to address vulnerabilities through security updates, test regularly, and operate a coordinated vulnerability disclosure process with a public contact point. Our SBOM guide covers what that document needs to contain for firmware.
The regulatory link is direct: the SBOM is what makes CVE matching possible in the first place, and CVE matching is what makes the Article 14 clock survivable.
Setting up CVE tracking for your product: the practical steps
1. Start from an accurate SBOM. It's a living document that gets regenerated every build, in CycloneDX or SPDX, covering firmware, RTOS, vendor SDK components, and open source libraries. Everything downstream depends on this being right.
2. Match continuously against a vulnerability source. OSV.dev and NVD's own feed are the two most common free sources, and they're queried differently: OSV.dev matches directly by package identifier (PURL) against your SBOM, while NVD indexes by CPE, not PURL - its API takes a cpeName or virtualMatchString, with no purl parameter at all. Stitching PURL to CPE is its own known problem, which is one of the reasons OSV.dev tends to be the more practical fit for matching software dependencies. Run this automatically on a schedule: new CVEs get published daily, against components you shipped months ago.
3. Triage with KEV, then SSVC where available, then EPSS, then CVSS, in that order, as covered above, rather than treating every match as equally urgent. These signals tell you how dangerous the vulnerability itself is; the second question is how many of your devices in the field are running it. A CVE with the same score is more urgent on firmware running on tens of thousands of devices than on a pilot batch of a hundred.
4. Resolve every confirmed match: either with a patch or with a VEX statement. If the vulnerability affects your device, the match goes into your patch process. But not every match is exploitable in your specific build: the vulnerable library function may never be called, or the option an attack needs may be disabled at compile time. For those cases, keep a second file next to your SBOM - a VEX (Vulnerability Exploitability eXchange) document that records the vulnerabilities you've already worked through. The SBOM says what's inside the product; the VEX says what you decided about each CVE found in it, and why: a status (for example, not_affected) and a reason (for example, the vulnerable code isn't reachable in your build), in a machine-readable format. Without it, the same alert sits open forever, and your customers' scanners keep finding the same match again and again. A separate file helps because the SBOM only changes with a new firmware release, while you add to the VEX every time a new CVE lands on one of your components. If your SBOM is in CycloneDX, these records can also live inside it; for a standalone document there's the lightweight OpenVEX format.
Most of this pipeline - SBOM storage, matching against vulnerability databases, alerting - is something a tool like Dependency-Track, free and open source from OWASP, already handles. But it answers the question "which of our projects contain this CVE." An IoT manufacturer needs a different answer: "how many devices in the field are running vulnerable firmware right now" - and that number, together with the signals from step 3, determines what to patch first. That's the question we're building Platanor Cloud to answer.
FAQ
What is a CVE, in one sentence? A CVE is a unique, standardized ID assigned to a specific publicly known vulnerability, so everyone referring to it - vendors, researchers, scanners, customers - is talking about the exact same flaw.
Is a vulnerability the same thing as an exploit? No. A vulnerability is the underlying flaw - the thing a CVE identifies. An exploit is the code or technique that takes advantage of that flaw to do something, like execute arbitrary code or escalate privileges. Plenty of CVEs have no public exploit available; some vulnerabilities are exploited in the wild before a CVE even exists for them.
Why register a CVE at all, instead of just fixing the product? You have to fix it either way - a CVE doesn't replace the fix. A CVE is how the fix reaches the people it affects. Devices in the field stay on old firmware until their owners learn they need to update, and their scanners won't notice a "security fixes" line in your release notes. If other manufacturers build your module or SDK into their products, they look for vulnerabilities by matching their SBOMs against CVE databases: without an ID, their tools are unlikely to flag it, and they may never update. On top of that, from 11 December 2027 the CRA requires you to publicly disclose information about fixed vulnerabilities once an update is available. The regulation doesn't require a CVE as such, but an advisory without a CVE ID is much harder to match automatically.
Who registers the CVE if a vulnerability is found in our own product? Not you: only CNAs can assign IDs. Your job is to get the vulnerability to someone who can, and there are two cases. If the flaw is in a third-party component (a library, SDK, or RTOS), report it to its vendor or the project's maintainers: they fix the code and usually handle the CVE themselves. From 11 December 2027, the CRA makes that report mandatory. If the flaw is in your own code, find the CNA whose scope covers your product on cve.org - national CERTs are among them. If none fits, submit a request through the form on cve.org, and MITRE or the relevant root CNA will assign the ID. Include the product, the affected versions, and a short description of the flaw.
Do we have to report every CVE in our components under Article 14? No. Of the vulnerabilities in your product, Article 14 only requires reporting the actively exploited ones - those with reliable evidence that a malicious actor has already exploited them without the system owner's permission. A CVE in your SBOM doesn't trigger reporting on its own. That's why KEV gets checked first: it's the most direct public signal that exploitation is already happening. The obligation applies from 11 September 2026, and it also covers devices placed on the market earlier, even if you no longer sell them.
Is VEX mandatory under the CRA? No, the CRA doesn't mention VEX. From 11 December 2027, the SBOM and the requirement to address vulnerabilities without delay become mandatory. VEX is a way to document how you meet that requirement: a dated record of why a given CVE didn't need an immediate patch. That's the justification you'll want if a market surveillance authority reviews your decision later. VEX doesn't exempt you from Article 14 reporting.
Sources: CRA Regulation (EU) 2024/2847 - Article 3(42), Article 13(6), Article 14, Article 69(3), Annex I Part II; NIST, NVD risk-based enrichment announcement (15 April 2026); CISA Known Exploited Vulnerabilities catalog and CISA Binding Operational Directive 26-04 (10 June 2026); FIRST, CVSS and EPSS; JSOF, Ripple20 disclosure (16 June 2020).
Denys Zaliznyak is the CTO of Platanor. Platanor helps IoT and hardware manufacturers build the SBOM and CVE tracking infrastructure this article describes, as part of meeting CRA's Article 14 obligations and preparing for Annex I.