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

51–60 of 64 posts

Re: Could lockfiles just be SBOMs?

#51

Post by Yossarrian22 »

mrweasel wrote: post #35
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.

How does that work for high complexity dependencies like compression or cryptography? If HL7 wouldn’t catch xzutils is it really adding anything?

Re: Could lockfiles just be SBOMs?

#52

Post by notepad0x90 »

zvr wrote: post #28
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.

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…

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.

Re: Could lockfiles just be SBOMs?

#53

Post by notepad0x90 »

baobun wrote: post #29
notepad0x90 wrote: post #19

Earlier quoted context omitted.

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

I don't think you've addressed the requirement of having to execute the software, that was my main objection.

Another matter is that most software I know of doesn't even use lock files. Furthermore, there are lots and lots of software that would need to be updated to support your scheme, but updating them just isn't practical. It would have to be relegated to the type of software that gets regularly updated and its authors care about this stuff. I mean, we can't even get proper software authors to host a security.txt on their website reliably. It needs to work for "old" software, and "new" software would need to spend time and effort implementing this scheme. How can we get people that won't even sign their executable to sign a lock file and participate in the verification process?

Re: Could lockfiles just be SBOMs?

#54

Post by Jnr »

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.

I do exactly that in my container build pipelines and it is great. And then CI uploads those SBOMs to Dependency Track.

Depending on the language, scanning just the container is not enough, you for sure want to scan the lockfiles for full dependency list before it is compiled/packed/minified and becomes invisible to trivy/syft.

Re: Could lockfiles just be SBOMs?

#55

Post by Lvl999Noob »

Jnr wrote: post #54
ozim wrote: post #22

Earlier quoted context omitted.

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.

I do exactly that in my container build pipelines and it is great. And then CI uploads those SBOMs to Dependency Track. Depending on the language, scanning just the container is not enough, you for sure want to scan the lockfiles for full dependency list before it is compiled/packed/minified and becomes invisible to trivy/syft.

You are building everything in CI from scratch so theoretically, it should be completely possible to not need to scan lockfiles and get all the data from their respective sources (OS, runtime, dynamic libs, static deps, codegen tools, build time deps, etc)

Re: Could lockfiles just be SBOMs?

#56

Post by baobun »

notepad0x90 wrote: post #53
baobun wrote: post #29

Earlier quoted context omitted.

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

I don't think you've addressed the requirement of having to execute the software, that was my main objection. Another matter is that most software I know of doesn't even use lock files. Furthermore, there are lots and lots of software that would need to be updated to support your scheme, but updating them just isn't practical. It would have to be relegated to the type of software that gets regularly updated and its a…

> I don't think you've addressed the requirement of having to execute the software, that was my main objection.

I believe I did:

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

It does not require a JS runtime[0] - you fetch a tarball and check its integrity. You can extract it and validate the integrity of a module cache or (non-minified) distribution.

> Another matter is that most software I know of doesn't even use lock files.

I don't believe the goal should be to lower the bar until "most software I know" pass. And you don't need all the libraries you depend on to ship lockfiles/SBOMs themselves as long as you take ownership of it wrap it up in your own builds and installations, right? Besides, lockfiles are definitely the norm in js/npm land these days from what I see...

[0]: If you have a dependency with a lifecycle script which at runtime say downloads, builds and installs new components into the module tree then all bets are off. If you are doing SBOMs for anything more than theatrical checkbox compliance, such (usage of) dependencies should already have been yeeted before you got here and if not, well, I guess you have work to do. If you get to this point I'd say the process is serving its purpose in forcing you to face these.

Re: Could lockfiles just be SBOMs?

#57

Post by pornel »

Cargo.lock contains unused dependencies that aren't in the final product.

That's because it's a:

• union of all deps for all possible target platforms, • for all libraries and all binaries in the whole workspace, • and includes all optional deps for all optional features, regardless whether these features are currently enabled or not.

This means that Cargo.lock truly locks everything, and works for all platforms and configurations of a project. It's stable enough to commit into source control, as it won't get invalidated/mutated just because somebody used it on another OS or built the project with an extra flag.

But it doesn't represent what actually goes into each binary.

Re: Could lockfiles just be SBOMs?

#58

Post by notepad0x90 »

baobun wrote: post #56
notepad0x90 wrote: post #53

Earlier quoted context omitted.

I don't think you've addressed the requirement of having to execute the software, that was my main objection. Another matter is that most software I know of doesn't even use lock files. Furthermore, there are lots and lots of software that would need to be updated to support your scheme, but updating them just isn't practical. It would have to be relegated to the type of software that gets regularly updated and its a…

> I don't think you've addressed the requirement of having to execute the software, that was my main objection. I believe I did: > 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. It does not require a JS runtime[0] - you fetch a tarball and check its integrity. You can extract it and validate the integrity of a module cache…

I concede on all but the last point. For that, I think you're taking a very language or platform specific perspective. And I think I myself am highly biased by security incidents. To give examples:

1) The Notepad++ compromise is one, lots of people install it and don't even have auto-update

2) There has been lots of state-sponsored attacks in recent years that abuse software specific to a country, for example "HWP" against south korean users; sometimes this involves code-signing cert theft

3) Things like log4j have traumatized the industry badly, how do I know what software is using log4j, or some other highly depended-upon software under $randomlang

4) It's very important to detect when someone is using some weird/unusual usage of a popular software, for example things like node, nginx, docker, k8s running on windows 10/11.

I admit I too am biased, but that's my point, we need a solution that works for the messy world out there today, not an ideal world some day. Getting people to use it is like 90% of the problem, the technical part isn't a blocker. I don't care if it's a lockfile, an xml catalog, yaml, etc... can it get standardized and widely used in practice? Can it solve the problems we're all facing in this area? That's why "most software I know" is a very important requirement.

The problem at the end of the day is malicious actors abusing software, so they sort of set the requirements.

Re: Could lockfiles just be SBOMs?

#59

Post by mrweasel »

Yossarrian22 wrote: post #51
mrweasel wrote: post #35

Earlier quoted context omitted.

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.

How does that work for high complexity dependencies like compression or cryptography? If HL7 wouldn’t catch xzutils is it really adding anything?

In the case of something like xzutils, you would perhaps have listed it as low risk, as it's shipped with your OS. After the backdoor incident, you'd have adjusted the risk assessment, and utilities like it. Once you hit a certain level you might question if you truly need the entire xzutils package or if you could replace it.

In other cases you might have a library you depend on, but it's no longer maintained, so it might score really high on risk, meaning that you should probably address that dependency in your next development cycle.

So the SBOM and risk assessment wouldn't necessarily catch vulnerabilities, but it makes it simple to check if you're affect and generally help you manage/reduce your attack surface.

Re: Could lockfiles just be SBOMs?

#60

Post by zvr »

Tomte wrote: post #36
zvr wrote: post #32

Earlier quoted context omitted.

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?

Post reply on HN