Hacker News Reader

Comment by narinxas | Hacker News Reader

my point has very little to do with process

it seems to me that you're arguing back that SBOMs are just a list, so how can it be a big deal?

my point is an issue about the whole reality of needing SBOMs. clearly they have something to do with supply chain trust. but I think your perspective is focused too closely on the engineering aspects of the problem.

I find that the technical realities (all of which I understand to be, in the end, some kind of engineering decision) that motivate having to share vulnerabilities of all components without revealing their designs sources (of either software, hardware, both, or neither) to be morally dubious.

so keeping in mind that hardware, by this point, is stored as code so it's code, and software also has a source code, I find it necessary by this point to open source all the things!!1!

View on HN

Open sourcing doesn't alleviate the need for an SBOM. Regardless of source availability or license type, it shouldn't be a lengthy engineering exercise to determine what software components an organization is running every time a CVE is published. The people doing patch management at large organizations are typically not software engineers, and even if they are, they don't have time to read source code. The questions they are trying to answer should be able to be answered programmatically in seconds. This isn't an engineering problem, it's an operational problem.

it's the political principles I'm critizicing.

the technical problem is really essentially a matter of trust, blockchains solved this problem in the technical sense.

the opreations of large organization are typically private property... this is a touchy issue because technology corporations are essentially the government by this point

I guess I should be glad this isn't really my problem, I'm just worried about the public and political consequences of what I see as potentially dangerous mistakes being made on the idelogical level

You're misunderstanding the factors driving this initiative. This isn't an attempt to address the problem of trust. Software can be found to have vulnerabilities even if they are highly trustworthy, and almost all vulnerabilities in commercially used software are accidental. The organizations asking for SBOMs (this is currently receiving a lot of attention due to changes the US government has made to require them for their internal use) have other mechanisms to establish trust with their software vendors.

The straw that broke the camel's back on this issue was CVE-2021-44228 -- which was a vulnerability in open source software. If you missed that debacle -- the problem wasn't that people distrust Apache or software that use Log4j. The problem was that people didn't know where all it was installed.

This was because it isn't currently a standard for software developers to provide a list of all of their dependencies, regardless of whether they're open source or not. This isn't because they are untrustworthy. It just simply isn't standard practice. SBOMs are an attempt to standardize such a list.

A blockchain isn't necessary here -- nobody is trying to lie about what version of Log4j they're depending on in a piece of software they're selling.

you're ignoring my point, well.. not exactly "ignoring", more like explaining how and why the issue I was critizicing is completely irrelevant from where you stand

however, thanks to all this dialogue, do see where my own critizicism goes amiss; and for that, thanks a lot.

Lots of open source projects distribute prebuilt binaries too.

Reply on news.ycombinator.com