[HN Gopher] SLSA, an End-to-End Framework for Supply Chain Integ...
___________________________________________________________________
SLSA, an End-to-End Framework for Supply Chain Integrity
Author : rbinv
Score : 88 points
Date : 2021-06-20 20:29 UTC (1 days ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| dane-pgp wrote:
| > 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.
| SkyMarshal wrote:
| _> 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 wrote:
| 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 wrote:
| Check out sigstore.dev for an implementation of exactly
| this!
| SEJeff wrote:
| 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 wrote:
| > 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.
| dlor wrote:
| > "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.
| [deleted]
| jonahbenton wrote:
| 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 wrote:
| 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.
| er4hn wrote:
| 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.
| dlor wrote:
| 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.
| er4hn wrote:
| 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.
| pabs3 wrote:
| Related links:
|
| https://reproducible-builds.org/ https://bootstrappable.org/
| dane-pgp wrote:
| 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/
|
| [1] https://github.com/sigstore/rekor
| dlor wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jonahbenton wrote:
| Make sure the blockchain and contracts your assets live on are
| secured at SLSA X.
| TruthWillHurt wrote:
| You can always tell that they're targeting executives when they
| use the basic slide deck / powerpoint graphics and icons..
| kylegill wrote:
| > 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 wrote:
| As the person who suggested pronouncing it 'salsa' I can tell
| you it's just because I thought it was fun.
| er4hn wrote:
| Good thing the SALSA cryptographic cipher ended up being not
| as popular as the ChaCha variant.. which is widely used at
| Google ;)
___________________________________________________________________
(page generated 2021-06-21 23:01 UTC)