Improving software supply chain security with tamper-proof builds
security.googleblog.com
security.googleblog.com
A quick glance through the blog post shows, for example:
- A reliance on github runners to compile (rather than in-house)
- A reliance on a third-party signing service (rather than own CA)
No, you're not. The article is actually just braindead enough to suggest that shipping your build and cryptographic signing steps to third-parties is more secure.
This isn't just wrong, it's almost criminally devious (and blatantly in service to the ever-growing surveillance state).
The entire point is integrity and a fully auditable chain of actions. Quoting the post:
> Performing these steps guarantees to the consumer that the binary was produced in the trusted builder at a given commit hash attested to in the provenance. They can trust that the information in the provenance was non-forgeable, allowing them to trust the build “recipe” and trace their artifact verifiably back to the source.
This provides a broad swath of integrity guarantees that are otherwise extremely difficult to assert for builds that you don't control: you know exactly which machine ran the build, that it wasn't tampered with or silently replaced, and that a particular OpenID identity has signed for the build. You can verify all of these steps publicly without having to keep a trusted keychain, and without having to trust that the signing/publishing parties securely store long-lived signing keys (since everything is ephemeral).
The critical thing to note here is that GitHub Actions is just the platform here. The techniques are all open, and sigstore is an open specification with an open implementation. You can do it all in-house if you'd like, or ignore it completely if everything you consume is already in-house.
That's a big assumption, but the idea is likely that there are lots of projects and lots of maintainers, too many to vet them all. (But who will vet all that source?)
Ideally, though, someone would do the builds independently and then compare the checksums.
I'm not sure I follow.
GitHub is basically a glorified git repo.
So I still have to trust the people who do the git push, no ?
If so, then I fail to see how you can do better than git PGP signing ?
git PGP signing enforces integrity at the basic level, so you've got a chain of signed git commits.
I don't understand the "trust" in saying, "well, we've got too many maintainers to track PGP keys, so instead anybody can commit and we'll abstract the trust away to the build-level where we trust Github to build it without tampering, and we trust someone else to sign it" ... because that's what I read it as.
PGP has a handful of issues: you’re now trusting maintainers to manage long-lived signing keys, and you now have to manage your own trusted ring of signers. Both of these break down when dealing with package management ecosystems without a curating authority (e.g., a Linux distribution).
(That’s also assuming people actually verify their Git repositories, which I’ve never seen. It also assumes that people make reasonable key selection choices for PGP, which has been a problem in he past.)
I've generally come to believe that supply chain security comes from reproducible builds - though, more importantly, the build transparency that enables those builds to be performed reproducibly. If I can get two disparate, differently-hosted build machines to generate an identical artifact for me, that gives me far more confidence than relying on any behaviours that GitHub Actions is supposed to have. If I can then decide to ignore the pre-built package and choose to very easily perform the full scratch-build on my own systems and inspect every part of that process, that's even more convincing.
A lot of the efforts around SBOM give me the impression that they're trying to solve the problem using lightly-digitized bureaucracy (which, as pointed out by Luis Villa in https://blog.tidelift.com/pay-to-play-dont-expect-maintainer... is a game that many FOSS maintainers may not want to play), whereas, as a Nix person myself (oh hadn't you guessed by now?) it's always struck me that this is really a build system problem and most of the work should be doable automatically.
(I guess the approaches I've been seeing are also related to the fixation we seem to have in ops/ci/cd standard practices these days with the "push" model of many individual build processes & steps "pushing" an opaque artifact to the next in a pipeline. It's an idea baked into most components from Docker to .. really every ci pipeline syntax I've seen. But it's an idea that's strewn with subtle complexities - from stale artifacts of previous failed runs to race conditions with dire consequences. In my experience life becomes a lot simpler when your destination instead understands exactly what it needs, can "pull" in exactly those resources and have them built to their specifications or build them itself..)
This doesn't seem all that different from how certificate transparency helps to build trust in DNS registries. Can you trust them to do their jobs? Well, it helps that if they do certain things wrong, someone will notice.
You're essentially describing the solution I outlined in my original post. What is the proposal in this article actually adding that's not painfully obvious?
I would love for app store vendors to put their money where their mouth is: allow reproducibly-build open source (or source-available) apps to be verified by the store and to have a clear badge in the store that indicates that you’re getting the app you think you are.
Cool, so just emit that token along with your build artifacts. Anyone who trusts Github can then verify that it was signed by them, and there is no need for any of the CA nonsense.
This works if you need to verify JWTs from relatively recent packages, but packaging has a long tail. There's no guarantee that GitHub is still publishing their expired JWK sets a decade after the last valid signature for them has gone out.
A tamper-proof solution would produce software that somehow magically foils all attempts to modify or replace it, which isn't really possible (though some malware is somewhat tamper-resistant in that sense).