Re: [RFC] spdx30: name, version and purl for dependency downloads

["Stefano Tondo" <stondo@gmail.com>]

On Thu, 5 Nov 2026 at 21:26, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
> I'm afraid I am missing context, which is hardly surprising because I
> did no spdx work until now. What are the language dependencies? Does
> something require or recommend them? Is there a normative document
> that defines them? The email talks about how the implementation
> works, but says nothing about what the problem is.

Hi Alex,

You are right: I jumped straight into the how and never explained
the why. Let me start from the problem.

Take crucible from meta-oe. It is a Go program, and besides its own
code it compiles in 36 Go modules fetched with gomod://, one of them
golang.org/x/net v0.39.0. Now imagine the next advisory for
golang.org/x/net comes out, and whoever ships a device with crucible
on it is asked: "Is your product affected?"

The SPDX that Yocto writes for the image should answer that, but it
can't. The module is in there, but only as a downloaded file named
"golang.org.x.net@v0.39.0.zip" with the location
gomod://golang.org/x/net: no version field and no package URL, so
no scanner recognises it. cve-check does not see it either, because
it only knows the CPEs of recipes. The answer ends up being someone
reading file names by hand, for every advisory and every image.

That is what I meant by language dependencies: the packages of a
language's own package manager that a recipe compiles in without
having a recipe of their own. Rust crates (crate://), Go modules
(gomod://) and npm packages (npmsw://) are the cases Yocto can fetch
today. For the first two the problem is the one above: present, but
not identifiable. Git submodules and the dependencies listed in an
npm shrinkwrap file are worse off: they are not recorded at all.

Why this matters now, with the documents that ask for it:

- The EU Cyber Resilience Act (Regulation (EU) 2024/2847), Annex I,
  Part II, point 1, requires manufacturers to identify and document
  the components of their products, including by drawing up an SBOM
  in a commonly used, machine-readable format covering at the very
  least the top-level dependencies. It applies from December 2027 to
  products sold in the EU, so many Yocto users will have to deliver
  one.

- BSI TR-03183-2, the German technical guideline that spells out
  what such an SBOM contains, asks for the dependencies of everything
  that is delivered (section 5.1), each with a name, a version and an
  identifier such as a purl or CPE (section 5.2).

- The "2026 Minimum Elements for a Software Bill of Materials",
  published in July by CISA together with BSI, ANSSI and other
  agencies, asks for transitive dependencies and an identifier per
  component, and gives the example above as its reason: a recipient
  should be able to conclude that a new vulnerability does not affect
  them when the SBOM does not list the component.

Yocto already knows all of this at fetch time; the RFC is only about
writing it into the SPDX it already produces, without changing how
anything is fetched. I hope that makes the context clearer, and I am
happy to go into more detail on any of it.

Thanks,
Stefano