SLSA, an End-to-End Framework for Supply Chain Integrity
security.googleblog.com
security.googleblog.com
I'm really glad that reproducible builds are being highlighted here. Potentially they pave the way for an SLSA 5 which requires that two separate entities independently carry out the build process and store the hash of the output in an append-only log somewhere, with their signatures.
Then maybe SLSA 6 could require that every commit on the repo also be signed, and finally SLSA 7 would require that all transitive dependencies themselves be SLSA 6, including the build environments, which would be bootstrapped from a minimal binary seed.
At that point, the question of "Is this software trustworthy?" becomes almost identical to "Is the set of people who wrote and reviewed this software trustworthy?". That may not seem like a big improvement from where we are today, but hopefully it is cheaper to add honest reviewers than to compromise developers.
https://reproducible-builds.org/ https://bootstrappable.org/
I'm a maintainer of Rekor and the other Sigstore projects.
OIDC is really just the protocol, you don't even actually need to use email address-based tokens if you don't want to. We actually already support SPIFFE and machine-based identity tokens as well.
Yes! Simply being able to trace an artifact back to the set of people who wrote and reviewed it would be a major win over where we are today.
Disclosure: I'm a lead on this and a bunch of other supply chain security projects at Google.
In my own employers threat model that ranked pretty highly and I wrote about our own experiences here: https://eos.arista.com/commit-signing-with-git-at-enterprise... . With perspective I would say that the biggest thing I would add onto this is support for RFC 3161 style signed timestamps to the commit, but otherwise this solves a major issue.
I always personally struggle to recommend signing when it's so hard to do correctly. Until there's actually something workable, that supports time-stamping like you mentioned it seems like a false sense of security at best.
If you don't have trusted timestamps it is a little harder to trust the git commit timestamps. Those can be altered and you need to add additional checks like comparing with what your code review service says (which can be altered..) or requiring that timestamps increase for each commit (which has edge cases..)
Fwiw this is one of the few optimal use cases for blockchains - high value data that is lightweight on disk and network, and that needs to be stored in an append-only, replicated, tamper-evident, public database, which is both trustworthy and not requiring trust in any single entity.
Cue the XKCD comic about compromising advanced encryption with a $5 wrench: https://xkcd.com/538/
The issue isn't adding honest reviewers, it's keeping them honest. If you have a nation-state adversary that has the resources to compromise supply chains, such an adversary almost by definition also has the resources to threaten the safety of the loved ones of key engineers.
Software security with such strong technical guarantees ultimately would require going back and re-learning the same security guarantees that militaries afford and demand of key officers and scientists - security clearances, bodyguards, loss of personal freedoms and privacies (most notably financial privacy), etc.
That's my point, really. The question is what is the minimum number of engineers needed to be compromised in order for a malicious change to be introduced and not be noticed before it does its intended harm. Think of that as an equivalent to the Bus Factor, which, thanks to your prompting, I will call the Wrench Factor.
As you say, the threat model has to start considering meatspace security, but there are some advantages here relative to traditional military/industrial settings, in that we can imagine reputations being held by pseudonymous identities, and audits being assigned to random groups of them, without each other's knowledge, to prevent collusion.
There has to be some point at which an attack becomes infeasible (or at least unprofitable), if it requires simultaneously kidnapping thousands of people in multiple jurisdictions, without anyone noticing. Having various dead man's switches and zero-knowledge silent alarm protocols could do a lot to raise the cost of such attacks.
I wonder if projects with easier to remember names linger in people's minds longer.
Is this kind of phenomenon of fun names more a marketing thing? Or more a software engineers really love naming things thing?