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

11–20 of 64 posts

Re: Could lockfiles just be SBOMs?

#11

Post by jlubawy »

LoganDark wrote: post #6
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?

> what is it that SBOM is used for that lockfiles aren’t? Compliance. The article mentions "the EU’s Cyber Resilience Act will push vendors toward providing SBOMs", and having package managers generate SBOMs directly would certainly be convenient for that.

The FDA also requires SBOMs as of a few years ago for medical device software.

Re: Could lockfiles just be SBOMs?

#12

Post by Khaine »

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

Re: Could lockfiles just be SBOMs?

#13

Post by Ferret7446 »

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.

Re: Could lockfiles just be SBOMs?

#14

Post by notepad0x90 »

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 how things have always been done. Too stuck in the "monkey see, monkey do" mindset. How about any piece of software, under any execution environment should not only have an SBOM declaration, but cyptographic authentication of all of its components, including any static data files.

This should be a standardized mechanism. Everyone is doing their own thing and it's creating lots of insecurity and chaos. Why can't I answer all security-related questions about the software I'm running on any device or OS using the same protocol?

Everyone would consider it absurd if we used a different TLS when talking to an Apache server or a Windows server than alternatives.

SBOM, code signing (originator of the code), capability declarations, access requirements (camera, mic, etc...) are not things that are unique to an OS or platform. And for the details that are, those are data values that should be different, not the entire method of verification.

I wonder what it would take to enact this, I'd imagine some sort of regulatory push? But we don't even have a good cross-platform and standardized way of doing this for anyone to enforce it to begin with.

Re: Could lockfiles just be SBOMs?

#15

Post by perbu »

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.

Re: Could lockfiles just be SBOMs?

#16

Post by Tomte »

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?

Software licensing information is the big use case where SPDX originated from.

In CycloneDX you can also express things like attestations/certifications, possibly down to the code review level (although I think nobody does that).

Re: Could lockfiles just be SBOMs?

#18

Post by larusso »

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 year I had to create SBOM files for our Unity projects. Of course there is nothing. For all that don’t know: UPM (Unity Package Manager) is a way to easily install packages in Unity. And as a side note, for whatever reason they decided to built on top of npm not nuget for the package infrastructure and metadata format. Anyways: Most packages we use are simply wrapper packages for other packages. Like a wrapper for a .NET library. There is no clear dependency try but based on the package ID I’m able to see them. So I wrote the SBOM files based manually with an SBOM library and added pedigree statements to the original nuget package being wrapped. Idea was if the nuget package has a security issue the UPM package also gets flagged. Showed that one of the security engineers of the software we use. As wer was cool but that is not a standard. There is also no official package specification for UPM (I also made that up as part of the purl) So yes SBOM is a standard with a huge array of ways to declare said information. And it seems most companies consuming the files don’t built general parsers but expect specific formats for X.

Re: Could lockfiles just be SBOMs?

#19

Post by notepad0x90 »

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.

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 the developer, I don't get why SBOM is relevant at all. I think you mean at deployment time (when someone installs it - they check SBOM). What I'm saying is, when you fetch the software (download, package manager, appstore,curl|sh), when you "install" it, when you run it, and when it is dormant and unused. At all of those times, SBOM should be checkable. Hashes are useless unless you want people to collect hashes for every executable constantly, including things like software updates.

The problem is, people are looking at it only from their own perspective. People interested in audits and compliance don't care about runtime policy enforcement. People worried about software supplychain compromises, care more about immediate auditability of their environment and ability to take actions.

The recent Shai-Hulud node worm is a good example. Even the best sources were telling people to check specific files at specific locations. There was just one post I found on github issues where someone was suggesting checking the node package cache. Ideally, we would be able to allow-list even js files based on real-time SBOM driven policies. We should be able to easily say "if the software version is published by $developer between dates $start and $end it is disallowed".

Re: Could lockfiles just be SBOMs?

#20

Post by ozim »

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

You forgot about the important one SBOMs are created with thought about sharing them with third parties like your customers - lock files not.
Post reply on HN