> SLSA 4 is currently the highest level, requiring two-person review of all changes and a hermetic, reproducible build process.
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.
I would love to hear your thoughts on the problems with signing every commit. To be honest, I'm surprised it didn't make the initial level 1 -> 4 list since git gets you a lot of the way there.
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.
You're pretty much spot on. The problem is less about signing and more about existing PKI for git commit signing. We're working with David Huseby to help refactor the way gpg is coupled with git to enable stronger/different PKIs: https://github.com/TrustFrame/git-cryptography-protocol
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.
Thanks for sharing this. This is very interesting and I did not know about it. I'll make a note to read it and see if there are any useful contributions I can make.
One big problem is how to deal with a key getting revoked. That means every commit signed with that key is no longer valid. As I understand it, re-signing the commits requires rewriting git history, and would probably be a huge pain even if it didn't.
That's what having a trustworthy timestamp solves. A key is revoked at a known time, so being able to know if a commit was signed before or after the time of revocation lets you know what the key to use to validate should be.
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..)
As someone who spent a bunch of time with open source Grafeas early in its life around supply chain issues I am wondering- do those bits play a role in this infrastructure, or have they been supplanted?
In my head Grafeas does two things: provide a data schema, and a data store. I think they both still have some value, but the schema is probably more interesting to me at this point.
I also should have linked to Google's page about tamper-evident logs[0] (which they specifically mention can be used by package managers), and Rekor[1] (which describes itself as a "Secure Supply Chain - Transparency Log").
I'm hoping Rekor can become a place these "attestations" live for open source software artifacts, allowing us to trace all of this stuff back across build systems and environments. We have a long way to go, but it's moving very fast!
I'm a maintainer of Rekor and the other Sigstore projects.
I'm still not sold on the idea of having something bound by OIDC identities with Google/RedHat as stakeholders. Looking at the general conversation about FOSS developer identity that has been happening on OpenSSF, what are the actual chances of people with anonymous identities to be allowed commits on the tree in the future?
I understand the concern around anonymous identities and want to make sure it's always possible to use them.
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.
>and store the hash of the output in an append-only log somewhere, with their signatures.
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.
Append only logs that other sites mirror solves this problem without requiring the other blockchainy things such as peer to peer communication or proof of work.
> hopefully it is cheaper to add honest reviewers than to compromise developers
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 don't disagree, but the point is to make catching the easy stuff easy(it's not currently), and raise the alarm faster for the hard stuff(which is sometimes not even possible now).
I get the feeling that the update framework[1] fits in here somewhere, but I can't point my finger where or how. Anyone willing to give a description on how they both could work together?
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.