Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Could lockfiles just be SBOMs?

nesbitt.io

Post reply on HN
Print view View original

21–30 of 64 posts

Re: Could lockfiles just be SBOMs?

#21

Post by onion2k »

Isn't one fairly major problem with using lockfiles that there could be packages in the lockfile that aren't used in the application? If I run "npm i package" that doesn't tell you whether or not 'package' is actually used in the app.

For most things that unused dependency is just annoying but if your government has mandated that you use a specific package for something (e.g. cryptography) the lockfile isn't enough to give you confidence that the app is actually doing that. You'll still need to audit the application code.

Re: Could lockfiles just be SBOMs?

#22

Post by ozim »

Lvl999Noob wrote: post #10

Personally, I would prefer that the package managers keep their own lockfiles with all their metadata. A CI process (using the package managers itself) can create the SBOM for every commit in a standardized environment. We get all the same benefits without losing anything (the package managers can keep their own formats and metadata and remove anything unneeded for the SBOM from it).

Second that. It is trivial to add SBOM generator to your pipeline - it is not trivial to make all kind of package managers to switch and each format is used for different audiences.

Re: Could lockfiles just be SBOMs?

#23

Post by ozim »

Typical software developer fallacy - well it looks the same so we can abstract and merge concept.

Well NO lock file and SBOM formats are used for different purposes and are to be consumed by different audiences. They will evolve in different speeds and ways. Ideally SBOM should not evolve and package lock should be able to change on a whim by package manager developers.

SBOMs are meant to be shared by 3’rd parties while lock files not - just because some tooling accidentally started using lock files for ingestion is just because people didn’t knew better or couldn’t explain to their customers why they should do SBOM so they did first easiest thing.

Re: Could lockfiles just be SBOMs?

#24

Post by zvr »

Ferret7446 wrote: post #13

No because SBOMs are a hot mess and not standardized at all. They're "standardized" in the same sense as HL7 (ask someone in the healthcare industry, make sure to have some sedatives on hand first). A comprehensive SBOM for something like Chromium is many dozens of MBs compressed (I forget exactly, but it's patently ridiculous). Also SBOMs should be build artifacts, so them (also) being build inputs is problematic.

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.

Re: Could lockfiles just be SBOMs?

#26

Post by zvr »

ozim wrote: post #22
Lvl999Noob wrote: post #10

Personally, I would prefer that the package managers keep their own lockfiles with all their metadata. A CI process (using the package managers itself) can create the SBOM for every commit in a standardized environment. We get all the same benefits without losing anything (the package managers can keep their own formats and metadata and remove anything unneeded for the SBOM from it).

Second that. It is trivial to add SBOM generator to your pipeline - it is not trivial to make all kind of package managers to switch and each format is used for different audiences.

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.

Re: Could lockfiles just be SBOMs?

#27

Post by Tomte »

phendrenad2 wrote: post #9

> the security world has been pushing CycloneDX and SPDX > CycloneDX supports JSON, XML, and YAML And SPDX is JSON. Are there any other examples of government-mandated non-human-readable file formats? I feel like bureaucracies have a natural tendency to water down requirements such as this and instead focuses on getting wet signatures on pen-and-paper.

Or tag-value, which is actually preferred by many practitioners. Nesting is implicit in that format, but SBOMs should be mostly flat, anyway.

Unfortunately, T-V hs been dropped in SPDX 3.0.

Re: Could lockfiles just be SBOMs?

#28

Post by zvr »

perbu wrote: post #15
notepad0x90 wrote: post #14

Wouldn't lock files require running the thing? People need to be able to verify SBOM without doing that. It's the kind of thing you check against a large fleet of devices. If someone has software installed on their laptop but hasn't run it in a year, you need to be able to measure SBOM for that. SBOM is too similar to things like authenticode and package signing for it to be some unique solution. We're too used to ho…

Want to verify the installed package, the package should provide checksums you can verify. AFAIK, the SBOM is to documents the build, not the install.

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-...

Re: Could lockfiles just be SBOMs?

#29

Post by baobun »

notepad0x90 wrote: post #19
perbu wrote: post #15

Earlier quoted context omitted.

Want to verify the installed package, the package should provide checksums you can verify. AFAIK, the SBOM is to documents the build, not the install.

The checksum just tells you what the hash is, nothing more. Supply chain attacks aren't always against the main executable either. With authenticode, the "catalog" can be signed. You're even more opposite of OP than I (OP proposes lockfiles which are at runtime). It shouldn't be for "just" any state of the software. We should be able to verify SBOM and take actions at any point. At build time, it is only useful for t…

I still don't see how lockfiles can't be SBOM.

They contain for each dependency name, version, (derivable) URL and integrity checksum, plus of course the intra-dependency relationships.

This can all be verified at any point in the lifecycle without running any of the code, provided a network connection and/or the module cache. What's missing?

> With authenticode, the "catalog" can be signed

You could trivially sign any lockfile, though I've never seen it. I think it could be neat and it might have a chance to catch on if there was more support in tooling for it. The NPM registry does support ECDSA package sigs but I guess signatures for this use should be distributed on other channels given how much of an antipattern uploading lockfiles to registry is considered in the npm community and that's an uphill. In the context of SBOMs I guess there's already a slot for it?

Re: Could lockfiles just be SBOMs?

#30

Post by isodev »

Ferret7446 wrote: post #13

No because SBOMs are a hot mess and not standardized at all. They're "standardized" in the same sense as HL7 (ask someone in the healthcare industry, make sure to have some sedatives on hand first). A comprehensive SBOM for something like Chromium is many dozens of MBs compressed (I forget exactly, but it's patently ridiculous). Also SBOMs should be build artifacts, so them (also) being build inputs is problematic.

Oh dear, HL7, I may be suffering from a form of PTSD… my therapist has heard about this “standard” at length.

But I think SBOMs are better structured. I also feel that if package managers refocus their efforts on that, the standard and its implementations can be evolved. It’s the whole perk of using standards. I think it would be a good thing

Post reply on HN