PURL support for IoT devices

[mjherzog]

The following discussion about PURL support for IoT devices was moved to this discussion from:

• Add new PURL type for non-packaged software #516
  because it is off topic for the discussion of a new PURL type for software that does not have a registry.

---

rjb4standards
Would there be any support for pid = Product Identifier to include other products, i.e. IoT devices?
For example: pkg:pid/acmerobotics.org/Acme/robot-vaccuumm@2.3.0

mjherzog
@rjb4standards Our focus for PURL has always been software, not hardware. From your previous comments I thought that there were already sufficient other mechanisms to identify hardware?

Tomalrich
In 2022, the SBOM Forum (now the OWASP SBOM Forum) published this paper https://owasp.org/assets/files/posts/A%20Proposal%20to%20Operationalize%20Component%20Identification%20for%20Vulnerability%20Management.pdf on the advantages of PURL over CPE. At the end, we discussed how commercial software could be identified (that was the origin of the SWID type), and also how intelligent devices could be identified.

@stevespringett came up with the idea of using the GS1 standards (UPC code is one of them). These are used to identify items, including intelligent devices, in international trade (although they're also used in trade within one country's borders). Specifically, the GTIN and GMN standards could be used. The nice thing about these standards is they're already in widespread use, so probably all intelligent devices have a GTIN number today. https://www.gs1.org/

Our proposal suggested the NVD could support GTINs and GMNs, but this could easily be a separate database (in fact, that would probably be better). The important thing is that device makers would need to report CVEs (and other than a few big device makers like Cisco, Schneider and HPE, I don't believe there are many device makers that even report CVEs) and to include a GTIN in their CVE record. The device vulnerability database would ingest CVE records for devices, allowing users to look up vulnerabilities by GTIN.

Of course, there are a lot of complications with this, but it seems to be the best way to identify devices in general.

rjb4standards
We ended up using the UPC code as a substitute for version with IOT devices for the USCTM program in a “pds” (Product Data String” used to generate a unique productid using sha256(pds) where pds contains:

Manufacturer Name/Product Name and Model/UPC code: EIGHTREE/Smart Plug Model ET10/725414718500

Resulting in a unique product ID = 354D0DEBB3983F92C7374C13C61D9F8B7645F49D3379182F702BE13F2D79C82D

This productid is used to register the product in the SAG-CTR Trust Registry, which users can check to verify trust:

https://softwareassuranceguardian.com/labellink/getTrustedProductLabel?ProductID=354D0DEBB3983F92C7374C13C61D9F8B7645F49D3379182F702BE13F2D79C82D

https://softwareassuranceguardian.com/labellink/getTrustedProductLabel?ProductID=354D0DEBB3983F92C7374C13C61D9F8B7645F49D3379182F702BE13F2D79C82D&html=1 &html=1

Tomalrich
@mjherzog Steve and I brought this up in the 2022 paper on PURL because we thought (and still think) that this is a huge need in the vulnerability management world. CVE records for devices - other than devices made by the small number of manufacturers that report CVEs - are almost nonexistent. This can't be fixed by PURL, but it might be with GTIN/GMN. I've mentioned this multiple times in my blog, as well as in my book on SBOMs.

rjb4standards
@mjherzog Just to be clear, I am not proposing any changes to PURL. I was simply pointing out that the current PURL design is preventing the identification of IoT devices.

We are finding success using a simple, unique "Product Data String" (PDS) consisting of 3 concatenated elements (SupplierName/ProductName/ProductVersion) separated by a delimiter into a single string to be sufficient for product identification purposes including IoT devices and software product. There are no inferred location semantic in this approach because they are unnecessary for simple product identification purposes. I raise this to make the PURL designers aware of the limitation that was encountered. This will likely be an obstacle for EU CRA adoption of PURL, which also supports IoT devices.

Tomalrich
@rjb4standards the PURL specification doesn't "prevent" identification of IoT devices. The current PURL types (which are not part of the core spec, of course) address only open source software available in package managers. If IoT devices (and not just their software) ever become available for download from package managers, then the current PURL types could be appropriate. However, the laws of physics would also need to be drastically modified, and I'm not sure if that can be done by any online community :).

rjb4standards
@Tomalrich IoT device vulnerability reporting is already supported by GCVE; GCVE will accept vulnerability reports for IoT devices, because GCVE is a global, product‑agnostic vulnerability identification and allocation system. Nothing in the GCVE model restricts reports to traditional software; its guidance explicitly covers vulnerabilities in any digital product, including IoT firmware, hardware, and cloud‑connected ecosystems.
✅ 1. GCVE is product‑agnostic — IoT is fully in scope
GCVE’s published guidance (GCVE‑BCP‑02) describes a vulnerability handling and disclosure process for:

That train has already left the station and the EU CRA CVE reporting platform supports IoT devices today.

[Tomalrich]

Thanks, Mike. That is fine with me. You asked, "From your previous comments I thought that there were already sufficient other mechanisms to identify hardware?" The GS1 standards (GTIN and GMN specifically) are widely used in international commerce, but in order for them to be used for vulnerability identification, they need to be supported in the CVE schema, so that CNAs can use them to identify the specific device where a vulnerability is found. The big advantage of GS1 is there should be no ambiguity at all about the device that is being identified, since these identifiers are used for ordering and invoicing. Once CNAs start using this, you could in theory scan the UPC code on a device (UPC is another GS1 standard) and go right to a vulnerability database for devices, where the vulnerabilities for that device would be displayed. Tom Alrich LLC 312-515-8996 My blog has moved! It's now at https://tomalrich.substack.com/. All 1200+ of my posts since 2013 are accessible there, as well as new posts going forward.

…

________________________________ From: Michael Herzog ***@***.***> Sent: Saturday, March 21, 2026 1:07 PM To: package-url/purl-spec ***@***.***> Cc: Tom Alrich ***@***.***>; Mention ***@***.***> Subject: Re: [package-url/purl-spec] PURL support for IoT devices (Discussion #839) @rjb4standards<https://github.com/rjb4standards> @Tomalrich<https://github.com/Tomalrich> I have moved the commentary about IoT devices here from #516<#516> and pinned this discussion to the top of the Discussions page. I edited the comments to streamline but I did not change any essential points. Please confirm that we can delete these comments from #516<#516> because they are covered here. When I delete the comments I will include a reference to this discussion. — Reply to this email directly, view it on GitHub<#839?email_source=notifications&email_token=AVCDY63KN3C5ZJLUSJTOP5T4R3K73A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRSGQZTSNZXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16243977>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AVCDY6ZLCFMT6WS7SQGFC4L4R3K73AVCNFSM6AAAAACW2FOQHKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMRUGM4TONY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Tomalrich]

@mjherzog, This discussion isn't about PURL at all, since we already agree that PURL isn't appropriate for naming devices. The discussion needs to be about how best to identify devices for vulnerability reporting purposes, so that whatever method is chosen (and I'm recommending the GS1 standards, especially GTIN and GMN, that @stevespringett suggested in this white paper https://owasp.org/assets/files/posts/A%20Proposal%20to%20Operationalize%20Component%20Identification%20for%20Vulnerability%20Management.pdf in 2022) can be incorporated into the CVE Record Format, just as PURL was last year.

If you think this discussion should be moved out of the PURL issues altogether, we could move it somewhere else like into the OWASP mailing list. However, I'm fine if it can be left here, since at that point it's just a link that I can advertise outside of the PURL community. Please change the title of this issue to something like "Identifying IoT devices for vulnerability reporting purposes".

I'll enter a comment below that will welcome people to this new discussion, then I'll advertise the discussion in my blog (which received over 15,000 pageviews in a single day last week). Please delete all comments above, as well as this one, since they're not relevant to this discussion). I'd like my new comment to be at the top.

[Tomalrich]

Welcome to the discussion of identifying intelligent devices (including IoT devices) for vulnerability reporting purposes. The reason why I'm starting this discussion is fairly simple: While a small number of device makers, including Cisco, Schneider Electric and HPE, do an excellent job of reporting device vulnerabilities today, the great majority of device makers do not report CVEs at all. This is in part because neither CPE nor PURL (the two identifiers currently supported in the CVE Record Format) can adequately identify an intelligent device.

In 2022, @stevespringett suggested that the GS1 standards, in particular GTIN and GMN, might be appropriate identifiers for devices. This is because these two identifiers are already widely used in international trade, meaning they can be trusted to provide a correct identification of a device (UPC is also a GS1 standard, applicable to North American markets. It could be linked with GTIN, so that ultimately an application could scan a device's UPC code and list all the vulnerabilities that have been identified for that product. See this article: https://spectrumbpo.com/gtin-vs-upc/).

What do you think of this idea? Do you have another idea?

[rjb4standards]

GCVE is already collecting IoT device vulnerabilities today.