Yes. CVE Record Format version 5.2.0, deployed on 29 October 2025, added support for Package URL (purl) identifiers through a packageURL property on the affected array items. It is a non-breaking change, and it only helps for records whose publishers choose to fill it in.
What the update says
The cvelistV5 repository notes the 5.2.0 release. It lists these changes:
- support for PURL identifiers using the packageURL property within the affected array items
- additionalProperties set to false for the affected array items
- updated example records, including a purl example
- documentation and infrastructure work for future format updates
The same note says CVE Services 2.6.0 went with it. Earlier format versions had no purl field, so matching to open source packages relied on other fields.
How open source packages were identified before
The version encoding documentation says commercial products use vendor and product, while open source packages use collectionURL and packageName. Records could also carry CPE strings. That left scanners to guess a mapping from a CVE's names to an ecosystem's names, which is a common source of missed or false matches. Our post on purl or CPE, which identifier an SBOM should use explains why.
What a purl field improves
A purl names the ecosystem, the package name and optionally a version in one string, such as an npm or Maven coordinate. With a purl in the record:
- matching an SBOM component to a CVE becomes a string comparison on a defined format
- fewer name collisions across ecosystems (see same package name in two ecosystems)
- cleaner joins between a CVE record and an ecosystem advisory
If you are new to the format, read what a purl is.
What it does not fix
| Limit | Why it matters |
|---|---|
| Field is optional | Many records will still lack it |
| Old records | Records published before the update have no purl unless updated |
| Version logic | The purl names the package; version ranges still need correct version types |
| Quality | A wrong purl is worse than none; validate on ingest |
The practical rule is to prefer a purl when present, fall back to collectionURL and packageName, and use CPE as a last resort.
A parser checklist
- Read the format version in the record and validate against the matching schema.
- If the affected item has a packageURL, normalize it and use it as the primary key.
- Else use collectionURL plus packageName, mapped to the ecosystem.
- Compare versions using the record's version type.
- Log which identifier produced each match, so a wrong match can be traced.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, where components are identified by package coordinates. Try a free scan at gold.safeguard.sh/scan to see how your project's components are listed.
Quick check
When did CVE support for purl arrive?
With CVE Record Format 5.2.0, noted as deployed on 29 October 2025.
Do all CVE records have a purl now?
No. The field is optional and depends on the publisher.
What should I use if there is no purl?
Use collectionURL and packageName for open source packages, then CPE if needed.
Sources
- CVE Program, cvelistV5 repository README, fetched 19 October 2026.
- CVE Program, CVE 5.0 product and version encodings, fetched 19 October 2026.
Last reviewed: 19 October 2026.
