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

31–40 of 64 posts

Re: Could lockfiles just be SBOMs?

#31

Post by zvr »

zingar wrote: post #3

In hearing the SBOM term for the first time from that article and the linked Wikipedia page. For the ignorant like me: what is it that SBOM is used for that lockfiles aren’t? Everything in the article is something that I’m used to seeing automated scanners using lockfiles for. Is it just that the two are used by different communities? What is the SBOM community?

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.

Re: Could lockfiles just be SBOMs?

#32

Post by zvr »

Tomte wrote: post #27
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.

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.

Re: Could lockfiles just be SBOMs?

#33

Post by pacificpendant »

onion2k wrote: post #21

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 t…

You’re right that SBOMs cannot be used to attest that a library is correctly used. I’m not sure if that’s a common use-case of SBOMs though. I normally see people wanting SBOMs for security transparency (customer can see if you’re maintaining your dependencies), vulnerability management (customer can know what vulnerabilities lurk in the dependencies) and license compliance (they can know you didn’t use any dependencies with licenses that cause commercial issues).

Related to your point though is that just because a dependency is vulnerable doesn’t mean the software using it is affected too. It might not use the functionality that’s vulnerable. Which means a supplier needs to share their assessment of each dependency vulnerability.

Re: Could lockfiles just be SBOMs?

#34

Post by pacificpendant »

Khaine wrote: post #12
zingar wrote: post #3

In hearing the SBOM term for the first time from that article and the linked Wikipedia page. For the ignorant like me: what is it that SBOM is used for that lockfiles aren’t? Everything in the article is something that I’m used to seeing automated scanners using lockfiles for. Is it just that the two are used by different communities? What is the SBOM community?

SBOMs are a solution intended to help solve a couple of problems: 1) help identify and remediate software that has been built with vulnerable packages (think log4j). 2) help protect against supply chain compromise as the SBOM contains hashes that allow packages to be verified

https://www.ntia.gov/sites/default/files/publications/sbom_m...

Depending on who you ask an SBOM might not need a hash. NTIA only recommend a hash.

Re: Could lockfiles just be SBOMs?

#35

Post by mrweasel »

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.

This might not be part of HL7, but I recall working on software for a healthcare product, and simply having a list of components want not enough. Each component had to be accompanied by a risk assessment. It's a really clever way of keeping your dependency count low.

Re: Could lockfiles just be SBOMs?

#36

Post by Tomte »

zvr wrote: post #32
Tomte wrote: post #27

Earlier quoted context omitted.

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.

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.

Re: Could lockfiles just be SBOMs?

#37

Post by matharmin »

SBOM may contain similar info to lockfiles, but the purposes are entirely different.

Lockfiles tells the package manager what to install. SBOM tells the user what your _built_ project contains. In some cases it could be the same, but in most cases it's not.

It's more complicated than just annotating which dependencies are development versus production dependencies. You may be installing dependencies, but not actually use them in the build (for example optional transitive dependencies). Some build tools can detect this and omit them from the SBOM, but you can't omit these from your lockfile.

Fundamentally, lockfiles are an input to your developement setup process, while SBOM is an output of the build process.

Now, there is still an argument that you can use the same _format_ for both. But there are no significant advantages to that: The SBOM is more verbose, does not diff will, will result in worse performance.

Re: Could lockfiles just be SBOMs?

#38

Post by brookman64k »

In some ecosystems like Rust/Cargo the lock file can list a superset of the dependencies that actually make it into the final executable. Crates may conditionally include or exclude dependencies based on enabled features selected by the parent crate, or on the compilation target itself. As a result, the SBOM is effectively a build artifact, and its contents can legitimately vary across platforms.

Re: Could lockfiles just be SBOMs?

#39

Post by pjmlp »

> Every package manager has its own lockfile format. Gemfile.lock, package-lock.json, yarn.lock, Cargo.lock, poetry.lock, composer.lock, go.sum. They all record roughly the same information: which packages were installed, at what versions, with what checksums, from where.

Nope, Java and .NET ecosystem don't use them.

Re: Could lockfiles just be SBOMs?

#40

Post by homebrewer »

pjmlp wrote: post #39

> Every package manager has its own lockfile format. Gemfile.lock, package-lock.json, yarn.lock, Cargo.lock, poetry.lock, composer.lock, go.sum. They all record roughly the same information: which packages were installed, at what versions, with what checksums, from where. Nope, Java and .NET ecosystem don't use them.

One can easily opt-in with modern dotnet.

https://devblogs.microsoft.com/dotnet/enable-repeatable-pack...

Post reply on HN