Hacker News Reader

Comment by hiatus | Hacker News Reader

This doesn't make much sense to me. Why would someone want to pay each and every open source project to see the SBoM when they could pay a single provider or use an open source tool to get that info for all of their dependencies?

View on HN

Right. A significant part of the reason open source wins so handily isn't that the money for a proprietary solution is always more than it's worth, it's that you can just pull open source dependencies without going through purchasing.

Exactly. Going from $0 purchase cost to $0.01 is a nearly impossible problem in many organizations. Paradoxically, they'll find a way to waste $100k on an "enterprise" stack to do the same though.

If you're going to pay you might as well buy the best. Not saying that the enterprise stack is such a thing but that's how it's perceived.

$100k is on the cheap side, I've seen millions spent before upper management is convinced they should have gone with the open source solution that was already in place and working

I have also seen the other way around wasting large amounts on contracting for an open-source solution, and in the end the proprietary that everyone knows and loves, despite all its quirks, is the one that stays in place.

> Paradoxically, they'll find a way to waste $100k on an "enterprise" stack to do the same though.

Paying someone else to be the Single Wringable Neck when things go wrong is not the same as paying for some binaries.

This. Enterprise knows the fully baked cost of adding thousands of technologies. My last gig turned a $5k/year payment into about $100k just to avoid learning about MongoDB and the default Azure firewall. Used the same firewall as on prem, loaded up support contracts, kept team lean. It made sense in that context.

With modern package managers you can just generate your SBOM out of your lock file and call it a day. That misses dependencies that cross language boundaries, but it gets you 98% there for 10% of the effort. But what if you are writing C++, where it's the norm for libraries to vendor their dependencies, with no way to automatically detect them?

Sure, that is an opportunity for middleman to sell SBOM databases. But I could equally well see large c++ projects selling a subscription that offers an SBOM for each release, along with a couple bullet points to pad the offer (phone support, priority for feature requests and bug reports, early testing for new releases, etc).

Similar to how every SaaS has an Enterprise plan that is ridiculously expensive because big companies will pay anything to get SSO and an audit trail. And the provider adds a couple more enterprise features so nobody has to justify why they pay 5x the regular price just to get those two features. Same, idea, but with companies paying $100/month to get an SBOM and nice-to-haves for software they could get for free

> With modern package managers you can just generate your SBOM out of your

that's how most of the sbom tools work, ...

what is missing is a way to convince companies who provide an SDK that includes 3rd party dependencies to ship a machine redable SBOM as part of every release. otherwise it'll be very hard to figure out how to make sense of that data.

With C++ you use conan, or vcpkg, at least if doing modern development.

For private usage no one gives a shit about SBOM, but for enterprise usage it's absolutely required.

Enterprise also doesn't really care. It is just another box to tick and an excel sheet to fill out, correctness isn't actually required. You just need something to put in the list, so you may as well purchase something wrong but authoritative-looking in bulk.

It might be required and audited for software deployed to / interacting with government cloud. Eventually it will have to be correct too, as otherwise would be a security risk.

Yes, but that is an expense for a future faraway fiscal year.

When some new version of log4j comes about and everyone is scrambling to find out where it resides, the cybersecurity team is going to hate the crappy checkbox solution that doesn't actually work.

Which is pretty much the norm.

40% of all log4j downloads are still vulnerable versions.

Nobody cares, it's just another checkbox/policy. Security team is just another compliance department. It does not bring in money.

> Security team is just another compliance department. It does not bring in money.

This. Thanks for highlight it!

Which is why enterprises everywhere has software and tooling in place to provide this, for the exact things they do deliver.

I don’t see how anyone can «sell» this information when it’s literally available for free already.

> I don’t see how anyone can «sell» this information when it’s literally available for free already.

I think this has been repeated thousands of times in history.

> I don’t see how anyone can «sell» this information when it’s literally available for free already.

It's a channel for OSS projects to get money for corporate funding. Not all standard procedures allow for making up shit that the vendor doesn't provide, so you go and pay for the vendor's SBOM shrug

I think you are missing the point why enterprises have multiple tiers down the line of contractors who implement their software.

The point that's most important is: plausible deniability, because with formal and contractual agreements comes the responsibility shift. Enterprise buys software consultancy services because they are the ones that get the blame if it's not compliant with the legal requirements for it or when an audit fails at a later point.

Reply on news.ycombinator.com