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

61–70 of 138 posts

Re: The world needs a software bill of materials

#61

Post by dlor »

jmull wrote: post #53
dlor wrote: post #9

My big problem with all the SBOM efforts is that any kind of compliance/accuracy will be best effort and most likely wrong, leading to more problems and blame. This is not as simple as writing down your dependencies. Most people don't even know what their full set of transitive dependencies is, or how to even go about finding it. How do you know the SBOM you get is even accurate? You can't just crack open a binary an…

> Most people don't even know what their full set of transitive dependencies is, or how to even go about finding it. I think that’s the point. Also: you really do know your direct dependencies since you need them to build your software. If the efforts to promote or require SBOM are successful, your dependencies will all have SBOM and your tooling will be update to help you generate yours.

I don't think that's true in practice. Try it. I did here: https://dlorenc.medium.com/whos-at-the-helm-1101c37bf0f1

It's basically impossible with today's tooling and practices to come up with a list of dependencies for a moderately complex application.

Re: The world needs a software bill of materials

#62

Post by fulafel »

ozim wrote: post #51
fulafel wrote: post #17

Earlier quoted context omitted.

You can, in fact, crack open the binaries and look at what's inside. The field of tooling for it is called SCA (software composition analysis).

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.

Re: The world needs a software bill of materials

#63

Post by fulafel »

dlor wrote: post #59
fulafel wrote: post #38

Earlier quoted context omitted.

I feel you're moving the goalposts a bit. Perfect is the enemy of good, etc. Also surely the tooling would get a lot of investment and improvement poured into it if the proposal went through. Anyway, if this kind of thing really took off, I could well imagine there being regulation for SaaS products having to do audits involving this, for example.

I sort of see this as a situation where an imperfect SBOM is worse than nothing. It would do nothing but add false confidence. I still haven't seen an example of a single supply-chain attack that an SBOM would have prevented.

Well, we were discussing tooling that could be used to check if the declared SBOM is correct, not producing the original SBOM.

This kind of checking with today's practices is necessarily going to be imperfect, just like the BOMs in the physical manufacturing realm where the idea originates in. But if today's 99% solution turns out to be sufficiently useful, we could start making things in a way that are 100% verifiable (stuff like reproducible builds, etc)

In security we've long ago let go of the idea of risk and turst as binary issues, the same thing applies here. Just about every other tool we have to improve security has bigger holes in it than this one.

Re: The world needs a software bill of materials

#65

Post by jacques_chester »

TeMPOraL wrote: post #54
wpietri wrote: post #5

At least on first reading, I find this unpersuasive. He correctly lists a variety of problems. But he doesn't explain how his proposed solution, listing all the components of a technological product, would make a practical difference. Creating a list is valuable only if people a) read the list, b) recognize problems, and c) do something based on that. And for some of the examples he gives, it seems pretty obvious to…

I wonder how many companies already have SBOM internally for legal reasons? I know I recently participated in building a partial one, to help the company ensure we comply with exports regulations of multiple countries. After a casual inspection, we thought we had it all covered, but I felt a bit uneasy, so I dug deeper. Only after I actually read the build scripts of the transitive dependencies, one by one, cover to…

I had a similar experience several years ago.

It got worse when I began to consider dependencies in the supply chain itself. What version of our CI system are we using? What OS base image? What version are our worker VMs on? What packages are installed on them? And on and on and on. When I began writing these sources of upstream variability down I began to find dozens of them, for what was, in dependency terms, a fairly unremarkable application.

Re: The world needs a software bill of materials

#66

Post by jacques_chester »

We need SBOMs, but these are not enough. We need supply chain attestations, but these are not enough. What we need is the combination of asset data, process data and to acknowledge that our knowledge of both is always incomplete and subject to change. I call this need a "universal asset graph" and I've been nagging folks for years to get us to it.

The sigstore project is the biggest foundation stone of what I'd wish for, at least in terms of creating a robust shared log of observations (a leader of that effort, dlor, is in this discussion). But we still have a very, very long way to go as an industry.

Re: The world needs a software bill of materials

#67

Post by jacques_chester »

TeMPOraL wrote: post #58
spacemanmatt wrote: post #14

Earlier quoted context omitted.

True story: They already do. I know one company that forked Ruby, and would likely claim every library they run under it is thereby forked for the sake of reporting.

It's a natural next step after pinning versions and keeping all dependencies cached in-house. If the rolling disaster that NPM is taught us anything, is that it's critical to have control over the update process of the code that goes into your product. Not to mention, CI runs faster if you don't have to redownload everything from GitHub on each build :). (Though then developers don't get a day off when GitHub goes do…

A good asset graph / asset transparency log / whathaveyou would help a lot. If an SBOM is asserted and timestamped, you can compare assets you download to the earlier assertion to see if they are the same.

When I worked on buildpacks we added something like this. Each buildpack carried a simple BOM of the binaries it referred to and digests for them. When it fetched dependencies it compared the digests and bombed out if there were any mismatches.

This led us to capture far more of our dependency graph than before. It is surprising how many folks will replace binaries in-place without changing version numbers. We also managed to catch bugs in our own CI/CD process.

Re: The world needs a software bill of materials

#68

Post by jacques_chester »

pdimitar wrote: post #6

No SBOM will help you if the people know they have to act but they don't -- out of malice, bureaucratic slowdown, policy restriction and what-have-you. If you don't have hardware and software that can't be tampered with and that automatically apply / enforce the SBOM, then it is essentially worthless.

I disagree. SBOMs will help to create useful pressure on upstream providers to show their work. In particular, as another commenter pointed out, failing to provide an SBOM and providing a deliberately inaccurate or incomplete SBOM are quite different. One is presumably mere incompetence, the latter opens the door to consequences for fraud.

Re: The world needs a software bill of materials

#69

Post by varispeed »

vls-xy wrote: post #45
varispeed wrote: post #21

I find it obscene that there are some important software tools that are often developed by one guy in his rented basement and big corporations make billions on the back of it without sharing a penny. We need a royalty system for open source software, so that these companies will have to start paying fair share to the developers they exploit. This will also ensure the overall safety as developers will have funds to do…

I agree, but only to an extent. From my perspective OSS contributors are not "privileged developers" who can afford to commit their spare time. Yes, software development is a privileged career, but the privilege is not really pay, but education. Anybody in the world with access to the internet and a decent education can become a software developer. It is a highly competitive global market. My suggestion to any develo…

My point is that there are many developers who would love to contribute to open source projects, but they don't have wealthy parents who pay bills, didn't inherit a flat, have families to feed and so on, so for them only viable option is to seek employment or work on their own business. People who can commit their time to work on open source are privileged and by giving their work away for free they create a situation that there is less work for people who cannot afford that. For example a company instead of hiring developers, paying salaries and taxes to create a tool they need, will instead use open source project for free and that means other developers are missing out. Ensuring that everyone gets paid levels the playing field. This is the same situation as you have with free internships - there are people whose families have money, so they can afford to get experience working for a company for free and that puts people from poor background into a disadvantage - that's why in many places unpaid internships are illegal.

Re: The world needs a software bill of materials

#70

Post by jacques_chester »

dlor wrote: post #59
fulafel wrote: post #38

Earlier quoted context omitted.

I feel you're moving the goalposts a bit. Perfect is the enemy of good, etc. Also surely the tooling would get a lot of investment and improvement poured into it if the proposal went through. Anyway, if this kind of thing really took off, I could well imagine there being regulation for SaaS products having to do audits involving this, for example.

I sort of see this as a situation where an imperfect SBOM is worse than nothing. It would do nothing but add false confidence. I still haven't seen an example of a single supply-chain attack that an SBOM would have prevented.

We already have false confidence problems. Security scanning is a billion-dollar industry based on looking up digests in a table. But because the table is maintained by third parties, their incentives are to always be over-cautious. If they give false positives, the burden falls on their customers or the upstream dependency. But false negatives fall on the vendor. So they create noise.

SBOMs from the upstream push the cost back to the upstream and (sorry, investors and founders) vitiate the necessity of those third-party scanning vendors. The incentives change and so too, I expect, would the behaviour.

Post reply on HN