> SLSA 4 is currently the highest level, requiring two-person review of all changes and a hermetic, reproducible build process.<p>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.<p>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.<p>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.
> SLSA, pronounced “salsa”<p>I wonder if projects with easier to remember names linger in people's minds longer.<p>Is this kind of phenomenon of fun names more a marketing thing? Or more a software engineers really love naming things thing?
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?<p>[1]: <a href="https://theupdateframework.io/" rel="nofollow">https://theupdateframework.io/</a>