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

The world needs a software bill of materials

drrispens.medium.com

Post reply on HN
Print view View original

121–130 of 138 posts

Re: The world needs a software bill of materials

#121

Post by patcon »

mybrid wrote: post #109

Bills of Materials work with hardware because origins can be tracked. Good luck tracking the origin of electrons. I worked in manufacturing for a company the dealt solely with MilSpec (Military Specification). Crates sent to Nuclear Power plants had to X-Rayed on the shipping dock and then again at the receiving dock. If the X-Rays differed in any questionable way the shipment was rejected. However, most supply chain…

Aren't you just talking about checksums? Your xray anecdote is neat, but the software equivalent of that paranoia is even simpler and easier to operationalize if there's incentive to do so. e.g., https://reproducible-builds.org/

Re: The world needs a software bill of materials

#122

Post by PowerBar »

jacques_chester wrote: post #103
rixrax wrote: post #19

Earlier quoted context omitted.

In my mind SBOM is similar to food ingredients being listed on the packaging. FDA or someone requires them, very few read them or cares what is in there. BUT now that they are listed on every food product, those who care can read them and make informed decisions. And raise alarm when it is found that someone uses unhealthy amounts of whatever in their cakes or sausages. As for software, if I had up to date reliable S…

> might be able to do purchasing decisions based on used components, their CVE/etc. history, or sheer amount (in less being generally better, unless there is a reason to suspect the vendor e.g. rolled their own TLS instead of using one of the usual suspects). Counting CVEs is a poor indicator. It's not a pure function of how many vulnerabilities exist , it's a function of how many exist, are found and reported . Thos…

Agreed. For me CVE's serve 2 purposes. The first is to check if there are any known exploits in the currently-shipping version of a piece of software. The second is as a starting point in evaluating how the company, or community, responds to reports of exploits.

I'll take a problem from a company that published software with an embarrassingly bad security hole that thanked the reported and issued a fix immediately over a company with a hard to exploit security problem that ignored initial reports, threatened public reporters, denied its existence, and dragged their heals when the public demanded they fix it.

Re: The world needs a software bill of materials

#123

Post by dathinab »

silly-silly wrote: post #116
dathinab wrote: post #96

Any supply chain attack can be done in ways where it's externally impossible to (automatically) differentiate a malicious change from a intentional change. Which means BOM's are 100% guaranteed not to prevent supply chain attacks . At best it makes them a small bit harder. Software BOM's can have some small benefits, but preventing supply chain attacks is not one of them. And open access to source always is much more…

> signing build artifacts can be harder. Is this like signing an RPM package?

Somewhat. It's not really hard just a bit harder.

Mainly on your desktop system you can easily use a hardware security key (like a yubikey) to get a good level of signing security.

But your CI server has a good chance to not be your own hardware so you can't plug in a yubikey so to have good key security you either need to find a CI server where you have a HSM or you need to have some form of signing server/service to keep your private key save.

You also should at least consider things like "could the artifact be changed in between your CI creating it and your build signing server/IP-based HSM signing it".

There are ways to handle it, with different benefits and drawbacks. And considering and understanding this things is maybe the biggest additional amount of work.

Or you use a schema-F solution which seems reasonable without understanding it and be okey with it.

Re: The world needs a software bill of materials

#124

Post by snicker7 »

ris wrote: post #8

The solution to this problem is not bureaucracy. The solution is in the reproducible builds project, Guix and Nix.

There is a big difference between Guix and Nix and this area. Guix only accepts packages that can be fully bootstrapped, unlike Nix. It's a lot more effort, but it means everything you install in the official Guix channel ultimately comes from a ~300 byte, auditable binary seed.

Nix is more lenient when it comes to packages vendoring their own dependencies outside of Nix proper.

Re: The world needs a software bill of materials

#125

Post by silly-silly »

indymike wrote: post #111
AlphaSite wrote: post #108

Earlier quoted context omitted.

Why can’t your web app serve its BOM on an API, maybe union its BOM with the OSes BOM to get the full system. I guess with a deep service graph this could get very complex very fast.

So now every web app has to encapsulate an equivalent to the entire os repository tooling + your entire build system + whatever devops tooling needed to deploy. Bonus... A lot of build tooling is to allow for faster upgrades than the OS provides... Especially with dynamic languages.

Now imagine doing that for every package and container a linux distro provides. Welcome to hell enjoy your stay.

Re: The world needs a software bill of materials

#126

Post by AlphaSite »

indymike wrote: post #111
AlphaSite wrote: post #108

Earlier quoted context omitted.

Why can’t your web app serve its BOM on an API, maybe union its BOM with the OSes BOM to get the full system. I guess with a deep service graph this could get very complex very fast.

So now every web app has to encapsulate an equivalent to the entire os repository tooling + your entire build system + whatever devops tooling needed to deploy. Bonus... A lot of build tooling is to allow for faster upgrades than the OS provides... Especially with dynamic languages.

Oh I think you Mia understand, the is generates one bom, your build tooling generates a second at runtime your web server unions the two and that’s the actual machine BOM.

Re: The world needs a software bill of materials

#127

Post by PurpleFoxy »

Natsu wrote: post #112
rixrax wrote: post #19

Earlier quoted context omitted.

In my mind SBOM is similar to food ingredients being listed on the packaging. FDA or someone requires them, very few read them or cares what is in there. BUT now that they are listed on every food product, those who care can read them and make informed decisions. And raise alarm when it is found that someone uses unhealthy amounts of whatever in their cakes or sausages. As for software, if I had up to date reliable S…

Scanners already effectively give this, finding the vulnerable components and a list of CVEs. But it may be difficult, expensive, or too time consuming to upgrade the affected components. Or there may be blackout periods (e.g. during open enrollment for many healthcare companies) where they basically can't make any changes to the production stack. The problems with upgrades are usually centered around testing and und…

I only had a quick mess around but I found the scanners to be close to useless. I ran a docker scanner on the docker hub ruby image and it found over 1000 CVEs just listing out every cve open on Debian and ruby. None of that data was relevant to me or actionable

Re: The world needs a software bill of materials

#128

Post by indymike »

AlphaSite wrote: post #126
indymike wrote: post #111

Earlier quoted context omitted.

So now every web app has to encapsulate an equivalent to the entire os repository tooling + your entire build system + whatever devops tooling needed to deploy. Bonus... A lot of build tooling is to allow for faster upgrades than the OS provides... Especially with dynamic languages.

Oh I think you Mia understand, the is generates one bom, your build tooling generates a second at runtime your web server unions the two and that’s the actual machine BOM.

Oh, I don't think I do. I do not want to have to write code that duplicates functionality of a build system in an http server which discloses what components are behind that server, exclusively so hackers can identify that some dependency of some library in some other software on the server is insecure in real time. No thank you.

Re: The world needs a software bill of materials

#129

Post by wpietri »

arrosenberg wrote: post #87
pycal wrote: post #71

Earlier quoted context omitted.

I think on balance it actually hurts more than it helps. The author lists Equifax as a case where an organization “failed to update a web server in timely fashion (a few months)” but a software bill of materials would not have made it any more or less obvious that they were running vulnerable web software an attacker could get a foothold in, and could have made it easier for an attacker to exploit that foothold, pivo…

FYI - Compliance regulation in the US government almost never works, our government sucks at it. If you want to regulate a company like EquiFax, you have to stick to investigations and prosecutions, which the US government is quite good at. Companies can take the risk, but if they violate the law it should be big fines and jail time for the executives.

The US government has a high success rate in the cases it takes on, but it doesn't take on many cases. I think this works out pretty well for high-stakes things like securities. Most public-company CFOs are very careful because they want to have a long career that in no way involves even a risk of going to jail.

But if the crime is smaller or has less obvious impact, I wouldn't hold my breath. And a giant barrier to regulatory enforcement in tech is that the average state of practice is so very low. I'd bet that Equifax's practices were no worse than average; we just hear about it because it was such a large breach. From a regulatory perspective it's hard to hold them accountable for doing what everybody else is doing.

Post reply on HN