Stronger Supply Chain Security Coming to Argo
Supply Chain Security is Essential
Attacks on the Software Supply Chain are becoming more prevalent. As software development continues shifting left, finding a tool that improves your security posture without friction is highly desired. Protecting the source code, the build process, and consumers is a must. That’s why security has always been a core focus of the Argo Project and that effort continues.
Recent Security Posture Improvements
In early October 2022, the Security Slam challenged a number of projects, including Argo. Argo CD achieved a CLOMonitor Security score of 100% before the end of the challenge. Since the conclusion of that event, Argo CD has adopted the OpenSSF Scorecard to ensure the best security practices while providing transparency.
In March 2023, Argo CD completed a refactor of the release process in order to provide a SLSA Level 3 provenance for container images and CLI binaries. The CNCF also commissioned a security audit of Argo CD which was conducted by ChainGuard. The audit found that Argo CD achieved SLSA Level 3 v0.1 across the source, build, and provenance sections.
What is SLSA?
Supply chain Levels for Software Artifacts, or SLSA (salsa).
It’s a security framework, a check-list of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure in your projects, businesses or enterprises. It’s how you get from safe enough to being as resilient as possible, at any link in the chain.
The SLSA framework makes it easier for a project to get started with supply chain security and incrementally adopt higher levels of trust. Generating an attestation is a critical part in progressing to higher levels within the SLSA framework.
What are Attestations?
Imagine you are pulled over for speeding in a vehicle. The officer asks for your name and you provide it. You are then asked for your driver’s license. The information on your driver’s license (provenance), issued from a trusted and verifiable government agency (identity), attests that you are who you say you are and you are permitted to operate the vehicle.
A software attestation is a cryptographically verifiable statement about one or more software artifacts. The statement can be defined by using the in-toto attestation framework specification, which lays the foundation for generating an authenticated SLSA provenance.
What is Provenance?
There are a few misconceptions as to how a provenance and an attestation differ from one another. A provenance is a declaration of how an artifact or set of artifacts were produced via verifiable information provided by the build system, such as “where?”, “when?”, and “how?”. Whereas an attestation authenticates a provenance to be true, usually through some form of identity verification (signature).
Provenance != attestation
Provenance + signature = attestation
SLSA model of an attestation: https://slsa.dev/attestation-model
Why Do We Need Attestations?
Having an authenticated provenance makes it possible to write automated policies to trace the “who, what, when, where, and why” of a built artifact. Think of this as a modern-day checksum file.
A signed container image or a binary does not guarantee that it has not been tampered with, it only proves that the image was in the possession of the signatory when it was signed. If an attacker gains credentials to a container registry, they may produce their own signed images that a consumer is unable to verify whether they have been tampered with, which then leads to compromising the integrity of the container image. Recent changes in sigstore/cosign v2.0.0 makes forging signatures more challenging because it requires verification of the certificate identity and the certificate issuer. However, a signature does not allow the consumer to verify the metadata of how an artifact was produced.
Verifying an attestation can be done with a number of tools. In particular, the slsa-verifier tool was developed specifically for verifying a SLSA provenance. This is a powerful tool for use in your CI/CD pipelines or GitOps workflows. Admission/policy controllers can also be used with Kubernetes to verify attestations before an image is deployed.
Below is a snippet of verifying an attestation of a container image manually:
slsa-verifier verify-image quay.io/argoproj/argocd:v2.7.3@sha256:1779c395e352f3ec11471b26c8bc9eded5df7825a470d886a2cf0dedcd9655b4 \
--source-uri github.com/argoproj/argo-cd \
--print-provenance | jq
Verified build using builder https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.5.0 at commit 0d0d2a97bbb8b85e7ff2e46570ef117d2b823219
PASSED: Verified SLSA provenance
{
"_type": "https://in-toto.io/Statement/v0.1",
"predicateType": "https://slsa.dev/provenance/v0.2",
"subject": [
{
"name": "quay.io/argoproj/argocd",
"digest": {
"sha256": "1779c395e352f3ec11471b26c8bc9eded5df7825a470d886a2cf0dedcd9655b4"
}
}
],
"predicate": {
"builder": {
"id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.5.0"
},
"buildType": "https://github.com/slsa-framework/slsa-github-generator/container@v1",
"invocation": {
"configSource": {
"uri": "git+https://github.com/argoproj/argo-cd@refs/tags/v2.7.3",
"digest": {
"sha1": "e7891b899a35dca06ae94965ea5ae2a86b344848"
},
"entryPoint": ".github/workflows/release.yaml"
},
"parameters": {},
"environment": {
"github_actor": "crenshaw-dev",
"github_actor_id": "350466",
"github_base_ref": "",
"github_event_name": "push",
"github_event_payload": {
"after": "e7891b899a35dca06ae94965ea5ae2a86b344848",
"base_ref": "refs/heads/release-2.7",
"before": "0000000000000000000000000000000000000000",
"commits": [],
"compare": "https://github.com/argoproj/argo-cd/compare/v2.7.3",
"created": true,
"deleted": false,
"forced": false,
"head_commit": {
"author": {
"email": "41898282+github-actions[bot]@users.noreply.github.com",
"name": "github-actions[bot]",
"username": "github-actions[bot]"
},
"committer": {
"email": "noreply@github.com",
"name": "GitHub",
"username": "web-flow"How are the Argo CD Attestations Generated?
Argo CD is using slsa-github-generator, a set of tools that uses GitHub reusable workflows, making it easy to integrate into a build system by passing in a minimal amount of inputs. Using an OIDC token provided by GitHub, the GitHub reusable workflow generates a provenance and then signs it using sigstore/cosign. The output of the reusable workflow produces an attestation that contains a SLSA provenance which is available, authenticated, service-generated, and non-falsifiable. Thus meeting the current requirements for a SLSA Level 3 provenance.
The Future of Argo Supply Chain Security
The Argo Project will next rollout attestations to Argo Rollouts, then follow with the remaining projects. SLSA has recently announced the SLSA Version 1.0 specifications, which Argo plans to embrace. It is strongly encouraged that users adopt and verify attestations to protect the future of Supply Chain Security.
A special thanks to the maintainers of Argo for their support in including attestations into the release process.
