I don't understand all this modern "supply chain security" stuff. What is the point of getting cryptographic signatures and bills of material from people you don't know and don't trust?
Getting a BOM about people you don't know/trust lets you know who you don't know/trust: known unknowns. At the very least it present a quantifiable risk profile that you can use to push for disengaging from untrusted dependencies. At best, it's a stepping stone to start building relationships.
Some rando's BOM does not give you "known unknowns", it gives you "unknown knows"/"untrusted knows", an untrustable list of stuff they say they know, which only give you a risk profile if the potential attacker is not attacking you, and is definitely not "quantifiable risk".
If I'm using a piece of software from Alice, & Mallory is using a supply-chain attack to compromise that software, I have chosen to trust Alice without knowing who Alice has chosen to trust (unquantified risk). An SBOM tells me that Alice has chosen to trust Mallory - it doesn't necessarily tell me whether Mallory should be trusted, but it allows the risk associated with trusting Alice to be better quantified.
The next (out-of-band) step is actively engaging with & trust Mallory (or not).
The post is detailing a feature offered by GitHub to generate SBOMs from source code repositories - these will provide machine-readable inventory based on the files within the repository. You can upload a dependency graph to feed the SBOM as an out-of-band step, but trusting Alice's out-of-band dep graph is only a function of access to the source code as a source of truth.
Ultimately that's what all if this comes down to: creating a machine-readable graph from a predicable central place that tells us information we could have ascertained ourselves before anyway (just with considerably more effort).
Maybe I'm misunderstanding the discussion here?
Simple operations like rotating a key shouldn't trigger any security warnings, as long as they new key is signed by the old one, and even adding new people to a team should happen seamlessly if (a majority of) the existing team members approve that new identity being added.
Of course it doesn't solve key compromise, or someone selling their keys to someone else, but with long-lived (even pseudonymous) identities, it becomes possible to reason about the trust level of packages just based on how long an identity has been used without being compromised.
No system is perfect, and there's still a long way to go, but the existing systems make the remaining problems more tractable, and already increase the cost for attackers, which should reduce attacks.
I disagree entirely. Knowing that the random "leftpad" library you pulled it was in fact authored by "John Brown, 46 years old, from Milwaukee" does absolutely nothing for your software security.
The only way to audit your dependencies is to actually have someone you trust (e.g. works for you) go and audit your dependencies. The entire system is built on a broken premise.
It is possible to build up trust in an identity based on how long that identity has been used, and the "transitivity of trust" principle. So you wouldn't trust someone because "John sounds like a trustworthy name", and instead you'd look at how long the author's key had been associated with the library, and whether their key had previously been endorsed on other people's projects (for example having their PRs reviewed and accepted).
Admittedly this introduces a new danger that the social graphs start to become very dangerous honeypots of metadata, especially if we start letting employers vouch for their employees, but the ultimate goal here should be to use something like Verifiable Credentials with zero knowledge proofs, which will allow very strong probabilistic arguments to be made about whether an author (and all the code reviewers) have suddenly gone rogue and decided to burn their hard-earned reputations.
My point is that NOTHING about their "identity" provides trustworthiness, unless you actually know that person and you're contracting them in some way.
> build up trust in an identity based on how long that identity has been used
Why would that be true? Times and times again, we have seen popular packages take a wrong turn. An "identity" is just a key with some untrustable name on it, which can be sold or mishandled just as easily as your NPM or GitHub password.
If your entire security still relies on "this rando didn't do me wrong in the past, they're probably fine" or "they have a lot of GitHub stars", why introduce key management? What does it really get you?
If you decide to trust "the Python Foundation", what does this key do for you if you're already downloading binaries from python.org? And if you don't, how much does the fact that they have a key help you? Anyone can get a key.
Hackers can compromise python.org and sign stuff with a key advertised there. But the site is just one point. It's much harder to hack python.org and also their GitHub and Twitter account (and DNS and dozens of other supported services).
Keyoxide makes the signing key links on multiple sites thus raising a bar for accepting fake key. It's not a silver bullet obviously. Just makes the attack harder to pull and is machine readable (instead of making humans check the keys).
Once you know a vulnerability exists in a particular version of a particular piece of software, you need a way to go from there, through dependencies, to builds, and then to deployments. You can't push fixes to all the right places without knowing what those places are.
In other words, you need to correctly and completely answer questions like, "Oh, CVE-YYYY-NNNNN was just announced. What's the list of every binary on every machine of every platform we have in every environment (production, corporate network, employee cell phones) that needs a fix?"
You can do it manually, but that's basically asking for failure because you'll miss things. Also it's tedious.
Say you bought a car and this time they gave you an itemized receipt of every part in that car and the current condition of each part. It breaks down. Now when you go to take it in to a shop to investigate, you may correlate a specific defective or unmaintained part as the reason. You replace that part and move on with life.
You’ve saved time, energy, and got plenty of peace of mind.
You do not trust who you got the car from, that largely doesn’t matter. Because now you have to deal with real problems owning that car can bring.
suppose your supplier gets breached through a well known vulnerability that should have been patched by any competent vendor, e.g. log4j. you are negatively impacted and it has materially affected your business. the software component that was compromised was not in the SBOM. Now I can pursue legal action because they didn't give me accurate reporting.