31–40 of 64 posts
At my employer we generate sboms for all libraries we use. Why would we pay for them?
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,…
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?
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
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,…
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?
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.
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 SBO…
It's not so much about who made what. It's about knowing what versions where used and which CVEs are attached.
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.)
Earlier quoted context omitted.
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.
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.
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.