> This is just FUD. XeLaTeX/LuaLaTeX do not introduce any "complications"

Well, there are still some packages that work flawlessly with pdfLaTeX, but not completely with LuaLaTeX or XeLaTeX --- microtype is the canonical example.

Software Bill Of Materials (moving to System Bill Of Materials), as lots of comments here explain.

What is a "UK" ? ;-)

It was dropped exactly because it was flat and it was becoming completely unmanageable.

SPDX v3 is based on a graph model that can represent hierarchies natively. It can then be serialized in a file, for example, in JSON format.

But it was the best format for manually creating an SBOM.

Most SBOM use cases don‘t need the ability to put your detailed software architecture in the SBOM.

"manually creating an SBOM" is a much lower priority requirement than "easily, accurately, and completely creating an SBOM".

The whole idea is to use specific libraries to produce and consume SBOMs.

You wouldn't expect people to "manually create" JPG images, would you?

I would expect people to do a lot of manual work in SBOM and licensing, yes. Because that‘s we do now.

Think of the SBOM as a "table of contents" for the software you are receiving. Another metaphors that has been used is the "nutrition label" that you get in all packaged food.

So, it's a list of the "software components" that are inside a piece of software. And then you add metadata about each of these components: what's its name? its version? its hash? Up to now we're in lockfile territory.

But you want more information: what is the license? who supplied it? what is the security status? does it have known CVEs? are they relevant?

And then you go to special cases, like "AI" software: oh, it's a model? how was it trained? on which data? Or like software that has to be certified, to be used when safety is important.

An SBOM is capable of providing all this information. Take a look at the different parts that SPDX provides, and it's an ever expanding area.

Ah, but there are actually different types of SBOMs, that describe the software in different parts of its lifecycle. It's a completely different outcome to record the software when looking at its source, at what is being distributed, or at what is being installed, for example.

At some point we realized that we were talking across each other, since everyone was using "SBOM" to describe different contents and use cases.

The consensus was expressed around 3 years ago, and published in https://www.cisa.gov/sites/default/files/2023-04/sbom-types-...

I haven't had a chance to read that, but do you think it would be impractical to have the different types of SBOMs declared in a standardized format? My impression is that no matter what, authenticity needs to be established, so it will always fall under "cryptographic verification of information about software", it is the standardization of that which I have an issue with.

All types of SBOMs can be described in the same standardized format. SPDX 3.0 has a specific property and a set of values this one can take: https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Vocab...

The digital signing of SBOM artifacts, so that one can verify authorship and authenticity, is something external to the SBOM data, on top of them.

If you are asking about a standardized way to check these, across all computing environments, I think this is a tall order. There are obviously environments currently where this check is present, and there are environments where this is rigorously enforced: software will not load and execute unless it's signed by a specific key and the signature is valid. But the environments are so diverse, I doubt a single verification process is possible.

Yes, TLS for example uses X.509, as do lots of things. The container format, as well as the data-structure. I'm saying not just for SBOM, but for the code-signing cert aspect as well. I wouldn't mind if there was an "SBOM" usage in X.509, and CA's sell SBOM signing certs or whatever, but the sad fact is, I think some mobile platforms, macos and windows are the only place this is used.

We need for data-at-rest, what TLS has been for data-in-motion.

Exactly.

To understand what an impossible task this is, there is no need to think about different ecosystems (PyPI vs NPM vs Cargo vs ...). Even in the case of different Linux distributions, the package managers are so different that expecting them to support the same formats is a lost cause.

The format is standardized, to the highest level possible: ISO/IEC 5962:2021 defines SPDX v2.2.1. The actual standard text is available for free at the ISO website (and other places, like spdx.org).

The newer version, SPDX v3.0, will become ISO/IEC 5962:2026, and work is already underway for further versions.

What is not standardized at all are the integration of processes for producing/consuming/maintaining SBOMs in the software development world.

Oh sure, the format is standardized. The semantics aren't however, in any practical sense. What happens when you vendor/patch/fork a dependency? What happens to vulnerabilities that are not in code paths not used by your software, or only under certain flags?

HTML is standardized too, how many documents do you think use the p or i tags properly? Heck, how many documents do you think are HTML5 compliant, even ignoring the semantics?

(And even if it were, it is still much too bulky of a tool to replace lockfiles. Having to add a kilobyte to your file every time a bunch of new vulnerabilities get reported in your deps recursively sounds like a great addition to your commit history.)

> What happens when you vendor/patch/fork a dependency?

You change the supplier property (and most probably the version). This is how you distinguish between OpenSSL 3.1.4 from OpenSSL project and OpenSSL 3.5.4-1~deb13u1 from Debian project.

> What happens to vulnerabilities that are not in code paths not used by your software, or only under certain flags?

You record this information in the SBOM, using structures like "this software has this vulnerability reported, but it's not affected by it in this case" (see, for example, VexNotAffectedVulnAssessmentRelationship in SPDXv3).

I completely agree that its purpose is not to replace lockfiles.

You could also generate SPDX SBOMs, based on their AI Profile: https://spdx.github.io/spdx-spec/v3.1-dev/model/AI/AI/

Surely you mean 10 + 10 candidates (not 10x10).

Thank you for this, and congrats on your achievement!