[HN Gopher] Improving software supply chain security with tamper...
___________________________________________________________________
Improving software supply chain security with tamper-proof builds
Author : _-david-_
Score : 43 points
Date : 2022-04-07 15:21 UTC (7 hours ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| aftbit wrote:
| >GitHub now supports OIDC in their workflows. Each time a
| workflow is run, a runner can mint a unique JWT token from
| GitHub's OIDC provider. The token contains verifiable information
| of the workflow identity, including the caller repository, commit
| hash, trigger, and the current (reuseable) workflow path and
| reference.
|
| 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.
| woodruffw wrote:
| > 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.
| firstSpeaker wrote:
| Supply chain protection and security is making its way into
| thoughtworks radar as well:
| https://www.thoughtworks.com/radar/techniques
| mistrial9 wrote:
| they say "Software Bill of Materials" in that newsletter,
| apparently
| rmah wrote:
| Am I the only one annoyed that they use the term "supply chain"
| for a software build process?
| firstSpeaker wrote:
| Yes.
| bushbaba wrote:
| It's a fair term for supplying software to other organizations.
| Where there's chance for it to be tampered with between the two
| orgs.
| beams_of_light wrote:
| The verbiage is being extended from hardware supply chain
| security efforts.
| traceroute66 wrote:
| I'm slightly confused. How does relying on multiple third-party
| moving parts improve your supply chain ?
|
| 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)
|
| I'm probably missing something obvious, but I just don't get how
| this helps ? In my mind it seems to add extra places for security
| issues to be introduced ?
| orthecreedence wrote:
| > I'm probably missing something obvious
|
| 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).
| woodruffw wrote:
| > I'm probably missing something obvious, but I just don't get
| how this helps ? In my mind it seems to add extra places for
| security issues to be introduced ?
|
| 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.
| ris wrote:
| There is so much going on in the world of SBOM that seems so
| wrong-headed to me, and this is a good example. So much of the
| effort seems to be going into processes and systems that do
| little more than build a chain of trust back to someone or
| something that says "yeah just trust me". Here, from what I can
| tell (and I may have got this wrong), the "guarantee" of an un-
| tamperable build seems to come from some behaviour that some
| product (GitHub Actions) _happens to_ exhibit. Today. That
| feature subtly changes tomorrow or someone finds a(nother) hole
| in GitHub Actions security model, it means nothing.
|
| 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..)
___________________________________________________________________
(page generated 2022-04-07 23:01 UTC)