> 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.
>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.
> 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.
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?
[+] [-] dane-pgp|4 years ago|reply
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.
[+] [-] dlor|4 years ago|reply
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.
[+] [-] pabs3|4 years ago|reply
https://reproducible-builds.org/ https://bootstrappable.org/
[+] [-] SkyMarshal|4 years ago|reply
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.
[+] [-] jonahbenton|4 years ago|reply
[+] [-] solatic|4 years ago|reply
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.
[+] [-] kylegill|4 years ago|reply
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?
[+] [-] inyourbits|4 years ago|reply
[+] [-] Couto|4 years ago|reply
[1]: https://theupdateframework.io/
[+] [-] TruthWillHurt|4 years ago|reply