Live data from Hacker News

The world needs a software bill of materials

drrispens.medium.com

131–138 of 138 posts

Re: The world needs a software bill of materials

#131

Earlier quoted context omitted.

I kind of buy that, but I think it's important that SBOMs be designed such that it is clear what the gold standard is. The worst outcome is a standard that enforces a bunch of annoying metadata even in the all source and build steps are public case. The other problem is I don't think people without reproducible builds can deliver a correct SBOM. There must be some severe penalties for missing dependencies or somethin…

I think it helps to think of SBOMs as extracts or projections from an underlying knowledgebase which is updateable. There's certainly no sense in saying that any SBOM is truly final. Merely "this is our best knowledge at time X".

Sure, but does a bunch of "best effort" guesses without enforcement or auditability actually converge?

My experience trying to package things in Nixpkgs by upstreams that don't care about knowing their dependencies says no. Remember that sloppiness is infectious: if I can't wrangle my deps there is little marginal benefit from trying to keep my own packages in good shape. Also Docker being total snake oil. All these things tell me it's loosing battle without a severe course correction.

Re: The world needs a software bill of materials

#132

Earlier quoted context omitted.

At my employer, we have a company-wide database of which package is installed in which version on each machine (several ten thousands of them). This allows the compliance department to follow known security issues, and they can then open tickets to the affected operating teams stating on which machines the software needs to be upgraded (or mitigations implemented), and they set deadlines based on vulnerability rating…

At my employer we do the same thing for pretty much all software shipped to customers. (X thousand packages, across 5 arches, across 5 releases) There is an ongoing effort and it becomes more complex with vendored packages, embedded jars and 'containers'. I'm assuming that the indexing is done at compile time, how far back into your dep tree do you go ?

It's currently only at the top-level package level, and so the data is simply taken from the package manager.

I want it to go one level deeper (we use dh-virtualenv to put several Python packages into one Debian package, but that's only done in a very small part of the company).

Of course then there could be C libraries packaged with the Python libraries packaged in a Debian repository, so we'd need another level eventually...

Re: The world needs a software bill of materials

#133

Earlier quoted context omitted.

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…

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

You just made my point. Compliance regulation always turns into "hard to hold them accountable for common practice." I don't think it works well in finance (see: S&L Crisis, .com crash, housing crisis, pandemic crash), we just refuse to punish the people who were guilty. When the US decides to investigate and prosecute they do well, when they try to enact compliance, it fails.

The solution in the Equifax case was to send the CEO, CTO, CFO and CISO to jail for 10 years. The next week "average practices" would have been a lot less lax.

Re: The world needs a software bill of materials

#134

Earlier quoted context omitted.

I think it helps to think of SBOMs as extracts or projections from an underlying knowledgebase which is updateable. There's certainly no sense in saying that any SBOM is truly final. Merely "this is our best knowledge at time X".

Sure, but does a bunch of "best effort" guesses without enforcement or auditability actually converge? My experience trying to package things in Nixpkgs by upstreams that don't care about knowing their dependencies says no. Remember that sloppiness is infectious: if I can't wrangle my deps there is little marginal benefit from trying to keep my own packages in good shape. Also Docker being total snake oil. All these…

I disagree about it being a losing battle. It's a classic network effect / epidemic shaped model. Once a threshold is reached, the reinforcing loop takes over.

What's needed is the money and elbow grease to get the loop turning in the first place. That's where the major companies will need to put up or shut up.

Re: The world needs a software bill of materials

#135
post #62
post #51

Earlier quoted context omitted.

Technically you are right. Question is who is going to pay for that? In my job we dealt with enterprise customers that required list of all libraries we use and what license those have. But they had buckets of money to spend on compliance.

Are you asking if customers are willing to pay more for products that feature a SBOM? I think this is more a regulation idea.

My main point is that in places where it is needed software is already regulated because there are people who made their risk management and are willing to pay for it.

Automotive and banking do a lot of dependency checking, they have a lot of quality gateways. Of course they still fail because usually they have so much software to check that they would not have enough developers in the world to check all (take into account that you also need developers competent in that area).

They have to pick their battles and cover most important parts of their operations. So now volume of software to be checked is more than we have man-hours of developers in the world. Saying that you can do that for every software system and do it at least decently is naive.

We can put regulation in place but then we have to stop all software development in the world. This way "You can, in fact, crack open the binaries and look at what's inside." is true if you have a single binary but if we speak about organization that depends on thousands of applications problem is exploding to not managable scale.

Re: The world needs a software bill of materials

#136

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.

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

Agreed. This will create lots of big, useless data though.

Re: The world needs a software bill of materials

#137
post #135
post #62

Earlier quoted context omitted.

Are you asking if customers are willing to pay more for products that feature a SBOM? I think this is more a regulation idea.

My main point is that in places where it is needed software is already regulated because there are people who made their risk management and are willing to pay for it. Automotive and banking do a lot of dependency checking, they have a lot of quality gateways. Of course they still fail because usually they have so much software to check that they would not have enough developers in the world to check all (take into a…

I strongly disagree that it's already regulated where needed. Eg cheap IoT devices.

The "stop all software development"... No. You just have the sbom as a design requirement and design it in. It's not rocket science. It's regulation, like always there will be a schedule for it, so compliance can be ready when it comes into force.

Re: The world needs a software bill of materials

#138
post #121
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/

Materials can be traced to point of origin, especially nuclear active material. There is no such tracing with software. A checksum only guarantees that two things have equal software. It does not say the difference of origin between the two.
Post reply on HN