Open source projects could sell SBOM fragments

https://www.thomas-huehn.com/open-source-projects-could-sell-sbom-fragments/

by Tomte • 1 year ago

113 62 1 year ago

hiatus• 1 year ago

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?

hyperpape• 1 year ago

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.

rdtsc• 1 year ago

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.

mschuster912• 1 year ago

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

holowoodman2• 1 year ago

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.

josteink• 1 year ago

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.

wongarsu• 1 year ago

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

DyslexicAtheist• 1 year ago

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.

pjmlp2• 1 year ago

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

h4ck_th3_pl4n3t• 1 year ago

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.

transpute2• 1 year ago

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 rules

then distribute funds based on performance metrics defined by each customer. That could move SBOMs from cost center to revenue/operations center, without centralization.

LF OpenSSF 2024 report covers centralized efforts to improve OSS supply chains, https://openssf.org/download-the-2024-openssf-annual-report/

rlupi• 1 year ago

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.

The28thDuck• 1 year ago

Why not have some sort of VCS provider do something similar to Medium/Substack/etc. where access is generally free but frequently prompts you to subscribe/donate before access?

andrewflnr• 1 year ago

Because tooling would route around it immediately. Among other reasons, you can't have interactive prompts for support gumming up your CI (and if they're not interactive, then they're trivial to ignore). NPM does something close to this, but it's much more opt-in for the user.

_zagj• 1 year ago

Github or some other third party would Hoover up whatever money could made from this. Also, a lot of projects can be surprisingly sloppy when it comes to this. (For example, treating MIT-licensed code as if it's public domain and neglecting to include the license and copyright notice.)

arccy• 1 year ago

would you even trust the dependency if it's not reproducible? if it is reproducible, then the package manager is sufficient to generate a sbom

TheRealPomax2• 1 year ago

What's SBOM?

wbadart• 1 year ago

Software bill of materials

https://www.cisa.gov/sbom

chefandy• 1 year ago

I love how the logo looks like it could be for a powerlifting gym in 1989.

TheRealPomax2• 1 year ago

Damn, this article needs a few {{when}} and {{citation needed}} O_o

stackskipton• 1 year ago

They could but few people seem to care about SBoM past getting InfoSec to shut up about it. So I imagine return would not be worth the effort.

otterz• 1 year ago

In GNU Guix declaring the license(s) of a package is mandatory so it kinda automates the process of creating SBoM.

captn3m0• 1 year ago

True for many other distros as well, such as Debian.

Y_Y2• 1 year ago

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?

ATechGuy2• 1 year ago

Yes, that's the state of the art unfortunately. There are a number of vendors who can scan your source code and generate a list of FOSS libraries with licensing info (SBOMs). If we can find a way to get this money flowing to our fellow FOSS devs, that would be a huge win for the community.

tsimionescu• 1 year ago

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 the specific version of any GPL software it might include, which it's up to you to archive.

Y_Y2• 1 year ago

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.

tuananh• 1 year ago

it could never work with corporate using micro transactions like that

transpute2• 1 year ago

Not yet, which is why OpenSSF is disbursing millions in small amounts, on behalf of large corporates, https://openssf.org/download-the-2024-openssf-annual-report/. But digital payments are progressing as slowly and steadily as SBOMs, so they could potentially converge in the future.

ghostoftiber• 1 year ago

The providence of the SBOM is important. If you can't say "I made this" in reference to the SBOM then it's pretty much worthless.

Or, flip the script, if you're concerned enough about supply chain security to mandate an SBOM, you probably don't trust the supplier anyway.

There's the "but I signed it" crowd, but the wheels fall off when they've signed compromised artifacts too.

I just don't see a scenario where an SBOM that cannot be inspected and verified would be useful. If you have the infrastructure to do it, you're generating SBOMs anyway.

martinsnow2• 1 year ago

It's not so much about who made what. It's about knowing what versions where used and which CVEs are attached.

troymc2• 1 year ago

CVEs are very important, of course, especially nowadays, but...

Many licenses, such as the MIT license, are very open. All you have to do is include the license text and the names of the software creators, because they want attribution. In other words, it really is about who made what, even with some of the most open licenses.

Licenses matter, a lot. After all, some licenses are share-alike/viral: if you "use" code with such a license, your code might inherit that license. (I put "use" in scare quotes because this is where the lawyers get involved. It depends how exactly you use the code.)

kkarpkkarp• 1 year ago

after reading it I automatically desired to increase the number of dependencies in my OS software, not to bring any new features, but to increase the income :)

and I think it defined amount of time it would happen globally if the idea would be accepted

neilv• 1 year ago

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, like a lot of software was before the wild popularity of open source code (and, especially, modern Web dev).

pipo234• 1 year ago

This is a genuine concern, especially now that managers discovered that "llm assistence 10x-es developer productivity". (Where kLoCs are a measure of productivity and a world with more code is an obvious, axiomatic good).

phicoh• 1 year ago

Sounds like a disaster waiting to happen. There will be a bug in that LLM generated code and then what? Ask the LLM to fix the bug?

karparov• 1 year ago

That's an option.

What with a human? "Asking" FOSS maintainers might not give the result you want either. Well, depends how you ask I guess. Perhaps attaching an attractive price offer could help things along.

But depending on how LLMs improve, asking one of those could help.

UncleEntity• 1 year ago

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?

msy• 1 year ago

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.

martinsnow2• 1 year ago

At my employer we generate sboms for all libraries we use. Why would we pay for them?

troymc2• 1 year ago

It sounds like you and your fellow employees are generating those sboms while on the clock. In other words, your employer is paying for those sboms, indirectly, already. From your employer's point of view, sboms are an expense. Maybe it's a small expense, maybe it's a big one. If it gets big enough, I suppose they might consider outsourcing it.

CrimsonRain• 1 year ago

It's an automated process. Takes a day at most to set it up if you don't have it already

deng• 1 year ago

And those OSS maintainers would also, in writing, assure that if there's an error or something missing from that SBOM, they are liable for all legal fees and other costs associated with a license violation which might occur due to that error? Because otherwise, what's the point in paying for an SBOM?

In any case, since surely not all maintainers will provide this service, you need to scan your codebase anyway. And it's not that difficult, really. I recommend https://github.com/aboutcode-org/scancode-toolkit.

stevage• 1 year ago

And, uh, what is an SBOM fragment? Lots of acronyms here that don't really work out context.

jcalx• 1 year ago

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.

n0on3• 1 year ago

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.

tsteenbe• 1 year ago

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.

hun3• 1 year ago

Tangentially related: https://sqlite.org/purchase/license

Open source projects could sell SBOM fragments

Related Stories