then distribute funds based on performance metrics defined by each customer. That could move SBOMs from cost center to revenue/operations center, without centralization.
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.
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.
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?
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.
$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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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).
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.
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).
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.
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?
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
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.
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.)
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.)
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?
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.
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.
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.
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:
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/
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.
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.
Paying someone else to be the Single Wringable Neck when things go wrong is not the same as paying for some binaries.
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
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.
Which is pretty much the norm.
Nobody cares, it's just another checkbox/policy. Security team is just another compliance department. It does not bring in money.
This. Thanks for highlight it!
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 this has been repeated thousands of times in history.
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.
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.
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.
(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).
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.
and I think it defined amount of time it would happen globally if the idea would be accepted
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.
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.)
https://www.cisa.gov/sbom