Software Supply Chain Security could be a great opportunity for open source developers to get some money out of all the big corporations that benefit from their work.
Bash binaries and source code? Freely available, as always. Bash certificate of origin, needed only by huge corporations for compliance reasons? Available for the low low price of 0.01% of your CEO's total comp.
"I" I doubt would be allowed in the threat model unless you're someone notable like a patio11 or similar. Otherwise you're just as potentially compromised as the original threat
I would think you’d also at least have to be patio11, Inc., with business liability insurance and documented processes. No individual is going to be trusted by any company that would care about this threat model.
> No individual is going to be trusted by any company that would care about this threat model.
Many (most?) companies do not care about threat models. Rather, for them, security is an exercise in box-ticking so that they can sell to other companies who, in turn, also don't care about threat models, but who do have stakeholders who want to be told that everything is fine.
There is also the question of what does it mean for a company to care about something or for a company to trust something, really it's decision makers at those companies acting together, and as the number of those people rises, it's easier for them to justify not caring about security if indeed they once did, because of the diffusion of responsibility.
Finally there are the companies that have at least one person who actually cares about security and/or the well-being of their users/customers, who is in a sufficiently powerful position that the company effectively "cares about security". These are the complement of the "many (most?) companies" in the first sentence.
> Software Supply Chain Security could be a great opportunity for open source developers to get some money out of all the big corporations that benefit from their work.
I am not so sure about that. The big reason companies get certification is for liability and indemnification.
For the software you are certifying:
Have you paid for a security audit?
Have you obtained certifications for all the open source dependencies of your software?
How much of a bond have you put up?
Do you have legal counsel that can respond to inquiries?
Are you willing to travel to testify in court?
Would you be convincing to a jury of your expertise?
This type of certification plays much more into the hands of someone like Microsoft or Google with their massive size (so they can offer indemnity) their massive in-house legal counsel, and their name recognition.
I’ve been saying that for a while. FOSS maintainers can gain financial independence and sustain their projects by "selling" supply-chain security assurance to consumers on software contents, packaging, etc.
Disclaimer: I'm building a marketplace that would enable this.
> Software Supply Chain Security could be a great opportunity for open source developers to get some money out of all the big corporations that benefit from their work
Nah. It would be used by politicians as a safe way to push regulations to get votes with those talking points and that would be used by incumbent corporations to build regulatory moats to cripple competition including open source itself.
This is definitely a sound business idea, for anyone (not only the actual developer od the Open Source software) to pursue.
I disagree with the "needed only by huge corporations" part -- present and forthcoming regulation will make this needed by everyone doing commercial transactions involving software.
Well, you can start by taking a look at regulations that start mentioning SBOMs, at first recommending their existence and use and then moving to mandating them.
Without looking things up, I can mention White House Executive Order 14028 (2021) and National Cybersecurity Strategy Implementation Plan (2023) in the US, EU's Cyber Resilience Act (2023), national legislation in Germany and Japan (2023-2024), etc.
This is a great idea! If the open sources licenses could be changed (if that's even possible!) such that only the original authors or their designees can create these signatures/attestations, then:
... If Google really wanted to ship bash (or whatever) with the certs/attestation, they'd have to cough up enough money to make the developer(s) happy. If they don't Google is out of luck, they cannot sign it themselves. So it becomes a tradeoff of how much money the original developer(s) want vs how valuable it is and/or how much it would cost Google to build their own (and thus be able to sign/attest it) if the original developers got too greedy.
I had done some "research" to find out the meanings of these terms in the past, so it is really nice to see explanations for all of them listed on one page.
My superficial understanding of the space at large is that there are good initiatives and technical solutions / flexible frameworks but progress depends on various non-technical stakeholder organisations (software consumers, eg governments, hospitals, industry) being able to come together to agree on using these.
The complexity is a big obstacle. It is really the same as with software quality standards or digital identity, there is huge untapped potential that comes from a mismatch between what is possible today and what is usable for "society at large." There is still a long way to go.
Many (most?) software supply chain attacks that I have observed in the wild over the last 10 years started with compromised user level credentials, or bad actors with (at the time) legit access.
My current thinking is there are too many ways in to protect yourself with 100% security, so better to spend time figuring out how to reduce the blast radius, and what your recovery protocol will be when you get hit.
interlopers and suspect professions are attracted to a new money source .. In a sea-change series of events that diverge actual authors from new auditors and insert paid control of the forge. In some venn-diagram described process, a few percent of actors will in fact have organic connection to the decades of disciplined work that got us here, and the rest (IMHO) will devolve into the usual suspects of low-rent security, opportunistic money handlers, corporate shills and various forms of government bureaucracies ..
multiple low-effort frat-guy startups already exist immediately.. follow-on "experienced" gambling security goons as well (in Ireland for example).
ps- it is crucial to distinguish between the NodeJS disaster zone, javascript in general, at one end.. and core *nix OS parts at the other. not the same conversation
Software Supply Chain Security could be a great opportunity for open source developers to get some money out of all the big corporations that benefit from their work.
Bash binaries and source code? Freely available, as always. Bash certificate of origin, needed only by huge corporations for compliance reasons? Available for the low low price of 0.01% of your CEO's total comp.
This might be in jest, but this is a pretty good “side gig”. Doesn’t even have to be offered by the open source maintainers.
Can be offered by anybody. “Hey I can offer full SSCS-2 compliance on these open source projects. Only $10K per month!”
"I" I doubt would be allowed in the threat model unless you're someone notable like a patio11 or similar. Otherwise you're just as potentially compromised as the original threat
I would think you’d also at least have to be patio11, Inc., with business liability insurance and documented processes. No individual is going to be trusted by any company that would care about this threat model.
> No individual is going to be trusted by any company that would care about this threat model.
Many (most?) companies do not care about threat models. Rather, for them, security is an exercise in box-ticking so that they can sell to other companies who, in turn, also don't care about threat models, but who do have stakeholders who want to be told that everything is fine.
There is also the question of what does it mean for a company to care about something or for a company to trust something, really it's decision makers at those companies acting together, and as the number of those people rises, it's easier for them to justify not caring about security if indeed they once did, because of the diffusion of responsibility.
Finally there are the companies that have at least one person who actually cares about security and/or the well-being of their users/customers, who is in a sufficiently powerful position that the company effectively "cares about security". These are the complement of the "many (most?) companies" in the first sentence.
> Software Supply Chain Security could be a great opportunity for open source developers to get some money out of all the big corporations that benefit from their work.
I am not so sure about that. The big reason companies get certification is for liability and indemnification.
For the software you are certifying:
Have you paid for a security audit?
Have you obtained certifications for all the open source dependencies of your software?
How much of a bond have you put up?
Do you have legal counsel that can respond to inquiries?
Are you willing to travel to testify in court?
Would you be convincing to a jury of your expertise?
This type of certification plays much more into the hands of someone like Microsoft or Google with their massive size (so they can offer indemnity) their massive in-house legal counsel, and their name recognition.
I’ve been saying that for a while. FOSS maintainers can gain financial independence and sustain their projects by "selling" supply-chain security assurance to consumers on software contents, packaging, etc.
Disclaimer: I'm building a marketplace that would enable this.
> Software Supply Chain Security could be a great opportunity for open source developers to get some money out of all the big corporations that benefit from their work
Nah. It would be used by politicians as a safe way to push regulations to get votes with those talking points and that would be used by incumbent corporations to build regulatory moats to cripple competition including open source itself.
This is definitely a sound business idea, for anyone (not only the actual developer od the Open Source software) to pursue.
I disagree with the "needed only by huge corporations" part -- present and forthcoming regulation will make this needed by everyone doing commercial transactions involving software.
Are you referring to federal regulations? Would love to know the details.
Well, you can start by taking a look at regulations that start mentioning SBOMs, at first recommending their existence and use and then moving to mandating them.
Without looking things up, I can mention White House Executive Order 14028 (2021) and National Cybersecurity Strategy Implementation Plan (2023) in the US, EU's Cyber Resilience Act (2023), national legislation in Germany and Japan (2023-2024), etc.
How would that work for open source? Wouldn't the company just make its own builds?
Then companies are on the hook for validating and and remediating internal builds of CVEs.
Michaelt is right and it is becoming a major source of revenue for open-core startups (eg. Chainguard)
This is a great idea! If the open sources licenses could be changed (if that's even possible!) such that only the original authors or their designees can create these signatures/attestations, then:
... If Google really wanted to ship bash (or whatever) with the certs/attestation, they'd have to cough up enough money to make the developer(s) happy. If they don't Google is out of luck, they cannot sign it themselves. So it becomes a tradeoff of how much money the original developer(s) want vs how valuable it is and/or how much it would cost Google to build their own (and thus be able to sign/attest it) if the original developers got too greedy.
AKA a free market software economy!
Yeah, this has to be the way. Suppliers get paid.
I had done some "research" to find out the meanings of these terms in the past, so it is really nice to see explanations for all of them listed on one page.
My superficial understanding of the space at large is that there are good initiatives and technical solutions / flexible frameworks but progress depends on various non-technical stakeholder organisations (software consumers, eg governments, hospitals, industry) being able to come together to agree on using these.
The complexity is a big obstacle. It is really the same as with software quality standards or digital identity, there is huge untapped potential that comes from a mismatch between what is possible today and what is usable for "society at large." There is still a long way to go.
I feel like the header where you define key terms is a space where you really, really want to check for typos.
Many (most?) software supply chain attacks that I have observed in the wild over the last 10 years started with compromised user level credentials, or bad actors with (at the time) legit access.
My current thinking is there are too many ways in to protect yourself with 100% security, so better to spend time figuring out how to reduce the blast radius, and what your recovery protocol will be when you get hit.
You can also reduce your attack surface (dependencies).
WTF is "Proverence"? I'd call it a typo except it is consistently misspelled.
I think the author means "provenance".
https://www.merriam-webster.com/dictionary/provenance
Yep they do. Provenance and especially "build provenance" are what they are referring to but definitely misspell it.
https://slsa.dev/spec/v0.1/provenance
interlopers and suspect professions are attracted to a new money source .. In a sea-change series of events that diverge actual authors from new auditors and insert paid control of the forge. In some venn-diagram described process, a few percent of actors will in fact have organic connection to the decades of disciplined work that got us here, and the rest (IMHO) will devolve into the usual suspects of low-rent security, opportunistic money handlers, corporate shills and various forms of government bureaucracies ..
multiple low-effort frat-guy startups already exist immediately.. follow-on "experienced" gambling security goons as well (in Ireland for example).
ps- it is crucial to distinguish between the NodeJS disaster zone, javascript in general, at one end.. and core *nix OS parts at the other. not the same conversation
Could you explain what you mean by "gambling security goons" in Ireland?