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

61–64 of 64 posts

Re: Could lockfiles just be SBOMs?

#61

Post by Tomte »

zvr wrote: post #60
Tomte wrote: post #36

Earlier quoted context omitted.

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.

Re: Could lockfiles just be SBOMs?

#62

Post by zvr »

notepad0x90 wrote: post #52
zvr wrote: post #28

Earlier quoted context omitted.

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.

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.

Re: Could lockfiles just be SBOMs?

#63

Post by notepad0x90 »

zvr wrote: post #62
notepad0x90 wrote: post #52

Earlier quoted context omitted.

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

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.

Post reply on HN