6 ms·

SLSA, an End-to-End Framework for Supply Chain Integrity

109 points by rbinv 5y ago

dane-pgp 5y ago
> 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.
- pabs3 5y ago
  Related links: https://reproducible-builds.org/ https://reproducible-builds.org/ https://bootstrappable.org/ https://bootstrappable.org/
  - dane-pgp 5y ago
    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"). [0] https://transparency.dev/ https://transparency.dev/ [1] https://github.com/sigstore/rekor https://github.com/sigstore/rekor
    - dlor 5y ago
      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.
      - Foxboron 5y ago
        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?
        dlor 5y ago
        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.
- dlor 5y ago
  > "Is this software trustworthy?" becomes almost identical to "Is the set of people who wrote and reviewed this software trustworthy?" 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.
  - jonahbenton 5y ago
    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?
    - dlor 5y ago
      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.
  - deleted 5y ago
    [deleted]
  - er4hn 5y ago
    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-scale/ 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.
    - dlor 5y ago
      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 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.
- jonahbenton 5y ago
  Make sure the blockchain and contracts your assets live on are secured at SLSA X.
- SkyMarshal 5y ago
  >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.
  - er4hn 5y ago
    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.
    - dlor 5y ago
      Check out sigstore.dev for an implementation of exactly this!
    - SEJeff 5y ago
      Proof of work is one approach, but so is proof of stake, which many modern blockchains use (ethereum 2 is moving to PoS from PoW)
- solatic 5y ago
  > 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/ 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.
  - zie 5y ago
    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).
  - dane-pgp 5y ago
    > key engineers 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.
kylegill 5y ago
> SLSA, pronounced “salsa” 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 5y ago
  As the person who suggested pronouncing it 'salsa' I can tell you it's just because I thought it was fun.
  - er4hn 5y ago
    Good thing the SALSA cryptographic cipher ended up being not as popular as the ChaCha variant.. which is widely used at Google ;)
TruthWillHurt 5y ago
You can always tell that they're targeting executives when they use the basic slide deck / powerpoint graphics and icons..
Couto 5y ago
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? [1]: https://theupdateframework.io/ https://theupdateframework.io/

109 points by rbinv 5y ago

> 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.

pabs3 5y ago
Related links: https://reproducible-builds.org/ https://reproducible-builds.org/ https://bootstrappable.org/ https://bootstrappable.org/
- dane-pgp 5y ago
  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"). [0] https://transparency.dev/ https://transparency.dev/ [1] https://github.com/sigstore/rekor https://github.com/sigstore/rekor
  - dlor 5y ago
    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.
    - Foxboron 5y ago
      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?
      - dlor 5y ago
        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.
dlor 5y ago
> "Is this software trustworthy?" becomes almost identical to "Is the set of people who wrote and reviewed this software trustworthy?" 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.
- jonahbenton 5y ago
  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?
  - dlor 5y ago
    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.
- deleted 5y ago
  [deleted]
- er4hn 5y ago
  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-scale/ 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.
  - dlor 5y ago
    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 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.
jonahbenton 5y ago
Make sure the blockchain and contracts your assets live on are secured at SLSA X.
SkyMarshal 5y ago
>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.
- er4hn 5y ago
  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.
  - dlor 5y ago
    Check out sigstore.dev for an implementation of exactly this!
  - SEJeff 5y ago
    Proof of work is one approach, but so is proof of stake, which many modern blockchains use (ethereum 2 is moving to PoS from PoW)
solatic 5y ago
> 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/ 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.
- zie 5y ago
  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).
- dane-pgp 5y ago
  > key engineers 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.

kylegill 5y ago

> SLSA, pronounced “salsa” 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 5y ago
As the person who suggested pronouncing it 'salsa' I can tell you it's just because I thought it was fun.
- er4hn 5y ago
  Good thing the SALSA cryptographic cipher ended up being not as popular as the ChaCha variant.. which is widely used at Google ;)

TruthWillHurt 5y ago

You can always tell that they're targeting executives when they use the basic slide deck / powerpoint graphics and icons..

Couto 5y ago

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? [1]: https://theupdateframework.io/ https://theupdateframework.io/