CI: Achieve SLSA Level 3+

[agilgur5]

Summary

We should strive to achieve the highest possible supply chain security by rigorously automating, securing, and verifying all parts of the build & release pipeline.

• We are already virtually entirely automated (outside of cherry-picking for patch releases)
• We are already following most of OpenSSF best practices for the pipeline (and ci: ensure least privilege permissions for GHA tokens #12035 eliminated any gaps)
• We can do more on verification and signing of provenance

Related to part of #12031

Use Cases

SLSA Level 3+ gives a high level of confidence to users, teams, companies, and enterprises relying on Argo and the requirements create significant difficulties for attackers to orchestrate supply chain attacks. This is particularly relevant when Argo is used as a CI/CD tool, as it becomes a central area of trust.

Argo CD has already achieved SLSA Level 3 and had a third-party audit by Chainguard to verify this. Argo Workflows can be second to achieve it. Additionally, with the Nix build #10999 and/or other reproducibility improvements, we can likely achieve Level 4 as well with fully hermetic, reproducible builds.

Implementation Details

Argo CD's main change to achieve SLSA Level 3 was adding attestations with provenance in argoproj/argo-cd#12484. This goes a step beyond just signing releases / binaries / images. From "Why we need a provenance":

Signatures only prove that a image was signed by someone with access to the container registry. A provenance provides metadata on who, what, where, when, and how a software artifact was generated. It is then cryptographically signed to provide an attestation. A provenance can be used in a CI/CD system or in a Kubernetes cluster to attest that the image was published by the intended source.

• Binaries, images, and SBOM now have provenance, which can be seen in these steps in the build process: 1, 2, 3, 4, 5

  • CD also refactored out a reusable workflow for image builds as part of this. Workflows could potentially re-use that, although it is not strictly necessary. Cross-compiling instead of using a matrix could be a simplification for Workflows as well

• kargo also has a simpler release process that can be used as an example as well. See feat: attestations for container images/cli akuity/kargo#557, 1, 2.

The most complex piece of these two are probably the combining of hashes in a multi-artifact build. The specific SLSA provenance generation code references above are largely borrowed from the linked SLSA doc.

Credits

Thanks to @34fathombelow for implementing provenance attestation in CD and kargo, the initial image signing in Workflows in #9837, as well as explaining where some of the code was pulled and how it works/why it was written the way it was! Also thanks to @crenshaw-dev for suggesting I pick this up if I wanted to do more CI + Security work and that Justin and I collab 🙂

Briefly discussed in a SIG Security meeting as well.

Notes on the SLSA 1.0 spec

SLSA announced the 1.0 spec release earlier this year. SLSA Level 3+ is according to the SLSA 0.1 spec. 0.1 Level 3+ roughly corresponds to 1.0 Build L3+.

SLSA 1.0 primarily focuses on improving & simplifying guidance, updated schemas for provenance, and separation of "tracks". Build L4 is planned and a Source track is also planned. You can see some of these specifics that were split into tracks in the Chainguard CD audit mentioned above as well.

Since the changes largely reduce the current scope (Build plus Source L3 would roughly be 0.1 Level 3) and focus on spec improvements, there's nothing too significant for us to change. Source improvements would be great (I think this would mostly involve full, verified, deps lists + deps SBOMs) as the spec matures and further audits may be required as it matures as well.

---

Message from the maintainers:

Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.