CPE vs PURL for Medical Device SBOMs: Which Identifier and When

Every component in your SBOM needs a unique identifier. CPE and PURL are the two that matter. They were built for different purposes, they don't map cleanly to each other, and getting that mapping wrong is a quiet but real way to ship a medical device with blind spots in your postmarket CVE monitoring.

Last reviewed: May 2026 against the FDA February 2026 final guidance, CycloneDX 1.6, SPDX 2.3, and NVD CPE Dictionary practice as of Q2 2026.

At a glance - CPE vs PURL in one paragraph

PURLs identify open-source packages by where you got them - pkg:npm/lodash@4.17.21, pkg:pypi/cryptography@42.0.5, pkg:generic/openssl@3.0.13. They're generated automatically by SBOM tooling from package-manager metadata. CPEs identify products by NIST-curated strings - cpe:2.3:a:openssl:openssl:3.0.13:*:*:*:*:*:*:*. They're what the NVD attaches CVEs to. The FDA guidance names neither PURL nor CPE; CycloneDX and SPDX support both. In practice, your build-time SBOM is PURL-heavy and your postmarket vulnerability monitoring is CPE-heavy - and the mapping between them is where most medical device cybersecurity programs leak.

What CPE is

Common Platform Enumeration is a structured naming scheme NIST maintains as the official CPE Dictionary. Every entry is a 13-field colon-delimited string:

cpe:2.3:a:openssl:openssl:3.0.13:*:*:*:*:*:*:*
    │   │ │      │      │      │
    │   │ │      │      │      └─ update / edition / language / sw_edition / target_sw / target_hw / other
    │   │ │      │      └─ version
    │   │ │      └─ product
    │   │ └─ vendor
    │   └─ part: 'a' (application), 'o' (OS), 'h' (hardware)
    └─ CPE 2.3 spec version

Key properties:

• Centralized. CPE dictionary entries support product matching; a CVE can exist without a corresponding CPE entry or NVD configuration.
• Product-scoped, not package-scoped. "OpenSSL 3.0.13" gets one CPE regardless of whether you got it from apt, vcpkg, or a Yocto recipe.
• What the NVD speaks. Some NVD CVE records contain configurations blocks listing affected CPEs, but not every record does. The NVD API supports CPE, CVE-ID, and keyword queries.
• Lags reality. CPE entries for new packages, niche libraries, embedded RTOSs, and vendor-specific drivers often don't exist, or exist with the wrong vendor/product slug. The NVD has publicly acknowledged this backlog.

What PURL is

Package URL is a specification maintained on GitHub by the PURL community. It identifies a package by the ecosystem it came from:

pkg:npm/lodash@4.17.21
pkg:pypi/cryptography@42.0.5
pkg:maven/org.bouncycastle/bcprov-jdk18on@1.78
pkg:cargo/serde@1.0.197
pkg:golang/golang.org/x/crypto@0.21.0
pkg:deb/debian/openssl@3.0.13?arch=amd64
pkg:generic/openssl@3.0.13?download_url=https://www.openssl.org/source/openssl-3.0.13.tar.gz

Key properties:

• Decentralized. No registry. You generate the PURL from the package metadata you already have. pkg:npm/... means "npm registry"; pkg:pypi/... means "PyPI"; the resolver is implicit in the type.
• Package-scoped, not product-scoped. Two PURLs from different ecosystems can describe what humans call "the same library" - pkg:npm/openssl-binding is different from pkg:generic/openssl even though they wrap the same C code.
• What CycloneDX speaks natively. CycloneDX supports an optional purl field. In SPDX 2.3, use externalRefs with referenceCategory: PACKAGE-MANAGER, referenceType: purl, and the PURL in referenceLocator.
• Built for software supply chain reality. Transitive dependencies, lockfile versions, hashed sources - PURL was designed to mirror the way real software is shipped.

Free to share with a link to this page: <a href="https://bluegoatcyber.com/resources/infographics/purl-vs-cpe">PURL vs CPE side by side (Blue Goat Cyber)</a> Full-size infographic and text version

The comparison table

Why medical device SBOMs end up needing both

The February 3, 2026 FDA guidance, §V.A.4(b), p. 17 references the NTIA 2021 baseline, including other unique identifiers, but names neither PURL nor CPE. Use identifiers that support your monitoring workflow, with documented alternatives where mappings are unavailable.

Premarket (build-time) leans PURL. Your CycloneDX or SPDX SBOM is generated by tooling - Syft, cdxgen, Microsoft's SBOM tool, your build system - that parses lockfiles, scans binaries, and emits PURLs. Examples include open-source libraries shipped through npm, PyPI, Maven, NuGet, Cargo, apt, dnf, or pulled into a Yocto/Buildroot image.

Postmarket (monitoring) leans CPE. Once the device is in the field, you need a feed of "new CVEs that affect components on this device." The NVD is the canonical CVE source. NVD CVEs are indexed by CPE. Ecosystem-native feeds (OSV.dev, GHSA) cover PURLs well for open-source - but the NVD is still where most automated vulnerability tooling, government threat feeds, and CISA KEV cross-references resolve. CPE improves applicability matching, but is not a prerequisite to NVD searches. KEV is keyed by CVE ID, not CPE.

Commercial, embedded, and firmware components live in CPE territory. An RTOS (FreeRTOS, VxWorks, QNX, embOS), a Bluetooth stack, a TCP/IP stack (lwIP, Treck), a chipset driver, a commercial database, the operating system on your gateway - CPE entries can help identify these products where available. Firmware, RTOSs, and vendor binaries may also use pkg:generic PURLs with supplier-defined identity and version metadata.

Result: a mature medical device SBOM carries PURLs for everything generated from a package manager, CPEs for OS/firmware/commercial components, and - critically - a CPE for the device itself as a product so future CVEs can be attached to it by researchers.

How to map PURL to CPE (and where it breaks)

There is no official PURL ↔ CPE mapping. Several open-source projects try:

• purl2cpe - community mapping database
• OWASP Dependency-Track - maintains its own internal mapping when querying the NVD
• Anchore Grype, Trivy, Syft - each ships a vulnerability matcher that bridges PURL → CPE for NVD queries plus PURL → OSV for ecosystem-native queries
• CycloneDX SBOM tools - increasingly emit both purl and cpe fields on the same component when a mapping is known

Where it breaks in real medical device programs:

1. Vendor/product slug ambiguity. pkg:pypi/cryptography maps to cpe:2.3:a:pyca:cryptography:* - but only if your tooling knows that. Pick the wrong vendor slug and your NVD query returns nothing.
2. Statically-linked C libraries discovered by binary analysis. A binary SBOM tool emits pkg:generic/openssl@3.0.13 because there's no package manager involved. Mapping pkg:generic/... to a CPE is best-effort.
3. Forked or vendored libraries. Your team forked lwIP two years ago and ships a modified copy. The PURL points to a git repo that's not in any package manager; the CPE points to upstream lwIP CVEs that may or may not apply to your fork.
4. Vendor-supplied drivers and SDKs. A chipset SDK from a silicon vendor has no PURL and no CPE. It's a tarball with a version number. Consider a pkg:generic PURL, supplier advisories, keyword searches, and documented manual review; CPE registration is not a prerequisite.
5. NVD analyst lag. A new CVE published last week may not have its CPE configuration block populated yet. PURL-native feeds (OSV, GHSA) often see it first.

The practical rule: never rely on a single identifier or a single feed. Run NVD-by-CPE and OSV-by-PURL and CISA KEV and vendor PSIRT feeds in parallel, deduplicate hits, and triage every hit with a VEX statement.

FDA postmarket implications

Section 524B requires "a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits in a reasonable time." The FDA's postmarket cybersecurity guidance and the February 2026 premarket guidance support monitoring and risk-based assessment. Automated matching is useful practice, not the only permitted method.

Useful internal review questions about identifier hygiene include:

1. "Show me a component on the device that does not have a CPE." If your answer is "we monitor it through PURL on OSV.dev," that's acceptable - but you need the documented process that shows you're doing it.
2. "Show me how you handle a CVE that's published to the NVD but doesn't yet have a CPE configuration." This is increasingly common given the NVD backlog. Your runbook needs to address it.
3. "Show me the VEX statement for the last three CVEs your SBOM matched." VEX is how you tell reviewers, customers, and CISA whether an apparent vulnerability is actually exploitable in your device's intended-use context.

The identifier choice is upstream of all three. If your SBOM components carry both PURL and CPE wherever possible, you can answer those questions credibly. If your SBOM is PURL-only or CPE-only, you have to explain why - and the explanation has to be defensible.

Practical guidance for medical device teams

1. Generate your build-time SBOM in CycloneDX 1.5+ with PURLs for everything sourceable from a package manager. This is what CycloneDX is good at and what your build tooling will produce automatically.
2. Add CPE for OS, firmware, RTOS, commercial libraries, vendor drivers, and the device itself. Use the NVD CPE Dictionary to find the right strings. Register a CPE for your device under your company's vendor slug.
3. Where both exist, ship both. CycloneDX lets you emit purl and cpe on the same component. Do it.
4. Run multi-feed monitoring. NVD (CPE), OSV.dev (PURL), GitHub Advisory Database (PURL), CISA KEV (CVE-ID-keyed), and vendor PSIRT feeds for anything commercial. Deduplicate on CVE ID.
5. Triage every hit with VEX. A CVE match without a VEX statement is just noise on a reviewer's desk. See VEX Documents for Medical Devices for the workflow.
6. Document your identifier strategy in your postmarket cybersecurity plan. Reviewers want to see that you've thought about this - not that you happened to land on PURLs because your tooling did.

How Blue Goat Cyber Approaches SBOM Identifier Strategy

CPE vs PURL is not an academic distinction - it decides whether your vulnerability monitoring actually catches the CVEs the FDA expects you to catch. Here is how we handle it on client engagements.

• Dual-identifier SBOMs by default. We emit both purl (for OSS package matching) and cpe (for NVD/CVE matching) on every component where a CPE exists, so vulnerability feeds line up regardless of which identifier the advisory uses.
• Deterministic PURL generation. PURLs come from the build system, not from post-hoc string manipulation - eliminating the mismatched-namespace bug that breaks most homegrown SBOMs.
• CPE mapping curated against NVD. For commercial and firmware components we verify CPE strings against the NVD dictionary rather than accepting scanner guesses.
• Traceability to design controls. Every SBOM revision is versioned in your QMS and tied to the software build that produced it, so postmarket vulnerability decisions are defensible.
• Postmarket monitoring wired in. SBOMs feed into an automated vulnerability watch that flags new CVEs against both identifier systems and routes them into your CAPA process.

Our medical device SBOM service is the standard entry point.

FAQ

Does the FDA prefer CPE or PURL?

Can I get away with PURL only?

Can I get away with CPE only?

Who creates a CPE for my device?

How does VEX fit in?

Does CycloneDX or SPDX handle PURL/CPE better?

Related guides

• FDA SBOM requirements - the full submission baseline these identifiers feed.
• SBOM Vulnerability Management for Medical Devices
• VEX Documents for Medical Devices and the FDA
• CycloneDX vs SPDX: Choosing an SBOM Format for the FDA
• FDA Premarket Cybersecurity Submission Checklist
• FDA Section 524B Cybersecurity Requirements Explained

Free tools for this

• SBOM Readiness Checker - check an SBOM against the FDA's expected fields before you submit it.

References

• FDA, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," final guidance, February 3, 2026, §V.A.4(b), p. 17
• Section 524B of the Federal Food, Drug, and Cosmetic Act
• NIST, "Official Common Platform Enumeration (CPE) Dictionary," nvd.nist.gov/products/cpe
• PURL Specification, github.com/package-url/purl-spec
• CycloneDX 1.6 Specification, cyclonedx.org/specification
• SPDX 2.3 Specification, spdx.github.io/spdx-spec
• OSV.dev, "A distributed vulnerability database for open source," osv.dev
• CISA, "Known Exploited Vulnerabilities Catalog," cisa.gov/known-exploited-vulnerabilities-catalog