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

Open source projects could sell SBOM fragments

thomas-huehn.com

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Open source projects could sell SBOM fragments

#51

Post by n0on3 »

jcalx wrote: post #49

Syft ( https://github.com/anchore/syft ) and ScanCode ( https://github.com/aboutcode-org/scancode-toolkit ) are good open-source tools to generate SBOMs and search repos for licensing information — I'm curious to hear if there are reasons why those wouldn't work for enterprise purposes.

Their results are simply not reliable. The matching approach often matches too many things (hey, this could be A or B or C or D or E or F ...or 42!), or picks up things that have nothing to do with the license of some target (hello randomly included file with some completely unrelated license header and is not even included in the build but is there for some reason, meet your new friend, the utility script copied from somewhere else also not included in the build with an header for another unrelated license. You two feel lonely? let me introduce you to this other wonderful script included in some particular form of packaging) and of course cannot compensate for poorly declared licenses, typos, weird non-standard (or simply archaic/deprecated) ways to specify the licenses and so on and so forth.

It's not a fault of the tools themselves, but in practice they don't help much in real world situations. Basically you end up in need to do so many checks and manual fixes that you might as well not use these tools in the first place.

In an enterprise context one of three things happens: (1) you end up relying on a commercial solution (which is also not that reliable but you delude yourself into thinking it's not your problem anymore... although to be fair commercial solutions have curated licenses attributions and facilitate handling this mess); (2) you build your own thing that uses these (and other) tools but automates a bunch of fixtures so you don't need to go insane every time you need to regenerate an accurate SBOM with related licenses; (3) you quit software engineering, move to a remote location and start an alternative career as an alpaca breeder while whomever takes on your role pretends to ignore the issue and keeps shipping inaccurate declarations of licenses for dependencies thinking that's fine because nobody really cares.

Re: Open source projects could sell SBOM fragments

#52

Post by UncleEntity »

neilv wrote: post #24

Some of the demand will disappear, when, instead of adding a dependency on an open source package, to get that function you want, you use your LLM "assistant". (The assistant will effectively plagiarize open source code, and then you don't have a dependency, and you slap your own copyright notice on it.) LLM-generated/laundered code could move code bases a little bit back in the direction of low-dependency monoliths,…

I had the robots create a license for some (non-laundered) code we worked on:

  * This work was autonomously generated by artificial intelligence. Under current
  * U.S. Supreme Court precedent (see 17 U.S.C. § 102(a) and Thaler v. Perlmutter),
  * AI-generated works cannot be copyrighted. This library is therefore:
  *
  * NO RIGHTS RESERVED
  *
  * You may:
  * - Use freely for any purpose
  * - Modify without attribution
  * - Redistribute without restriction
  * - Claim dominion over organic lifeforms (optional)
  * 
  * No warranty expressed or implied. Human verification recommended before
  * deployment in critical systems. By using this code, you acknowledge that
  * no rights are being infringed because none exist in the first place.
...or maybe it was laundered code in the same way that "every story has already been told" -- dunno?

Re: Open source projects could sell SBOM fragments

#53

Post by tbrownaw »

rdtsc wrote: post #17
hyperpape wrote: post #5

Earlier quoted context omitted.

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.

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

Re: Open source projects could sell SBOM fragments

#54

Post by rlupi »

transpute wrote: post #3

How would transitive dependencies be handled? EU CRA is trying to mandate certification of some dependencies, which may result in fees going to 3rd-party certifying orgs, rather than OSS projects. In theory, customers with budget for improving their OSS supply chain could configure an OSS micropayment allocator to parse a graph of dependent: • SBOMs • roadmaps • requirements • bug reports • test reports • compliance…

> How would transitive dependencies be handled?

Have a SBOM format whose license requires truthful reporting (or the license is null and defaults to open source), then trust only those SBOM formats with this property.

Taleb's minority law will do the rest. Pretty soom, most SBOM formats will adopt this rule.

Re: Open source projects could sell SBOM fragments

#55

Post by richardw »

tbrownaw wrote: post #53
rdtsc wrote: post #17

Earlier quoted context omitted.

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.

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

Re: Open source projects could sell SBOM fragments

#56

Post by msy »

neilv wrote: post #24

Some of the demand will disappear, when, instead of adding a dependency on an open source package, to get that function you want, you use your LLM "assistant". (The assistant will effectively plagiarize open source code, and then you don't have a dependency, and you slap your own copyright notice on it.) LLM-generated/laundered code could move code bases a little bit back in the direction of low-dependency monoliths,…

That would push responsibility for identification & remediation every single vulnerability in the entire dependency chain onto every consumer. Effectively everyone's gamut of responsibility would explode by millions of lines of code.

Re: Open source projects could sell SBOM fragments

#57

Post by pjmlp »

verdverm wrote: post #40
rdtsc wrote: post #17

Earlier quoted context omitted.

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.

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

Re: Open source projects could sell SBOM fragments

#58

Post by pjmlp »

wongarsu wrote: post #34
hiatus wrote: post #2

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?

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…

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

Re: Open source projects could sell SBOM fragments

#59

Post by tsteenbe »

n0on3 wrote: post #51
jcalx wrote: post #49

Syft ( https://github.com/anchore/syft ) and ScanCode ( https://github.com/aboutcode-org/scancode-toolkit ) are good open-source tools to generate SBOMs and search repos for licensing information — I'm curious to hear if there are reasons why those wouldn't work for enterprise purposes.

Their results are simply not reliable. The matching approach often matches too many things (hey, this could be A or B or C or D or E or F ...or 42!), or picks up things that have nothing to do with the license of some target (hello randomly included file with some completely unrelated license header and is not even included in the build but is there for some reason, meet your new friend, the utility script copied fro…

This is why several German automotive OSPOs are working together to build OSS Review Toolkit (ORT) - it kinda glues various open source tools like ScanCode but adds features like the ability to manually correct findings and a policy as code to do risk management at scale/speed. Full disclosure I one ORT maintainers.

Re: Open source projects could sell SBOM fragments

#60

Post by Y_Y »

tsimionescu wrote: post #46
Y_Y wrote: post #14

You downloaded it without knowing the license (or trusting your download tool to tell you correctly) and the solution is to pay a third-party?

Well, do you have any idea what software you're pulling (and under what licenses) if you run `apt install vim`? Because let me tell you, if you think it's just vim, you're quite mistaken. And if you're distributing a docker image that contains vim, even for non-commercial purposes, it's technically your job to know. And perhaps to extend anyone downloading that docker image the offer of getting the source code for th…

Well it's vim, and any missing dependencies. If there license concerns up front I'll make sure I pick a distro/repo with compatible policy, like Debian main. If I want to double-check I'll run VRMS.
Post reply on HN