Argo CD supports signing and provenance in two directions. You can verify the Argo CD release you install using cosign signatures and SLSA provenance, and you can make Argo CD refuse to sync from sources that fail integrity checks, such as unsigned Git commits. Together they cover the tool and the code it deploys.
How do you verify Argo CD itself?
The project's documentation says each release ships verifiable artifacts. Container images carry signatures and SLSA provenance attestations. The CLI binaries have a single attestation file per release, and the release also includes an SBOM archive with its own attestation. You check them with slsa-verifier, or with cosign, against the source repository github.com/argoproj/argo-cd and the release tag. The verify-image command checks container images, and verify-artifact checks the CLI binaries and the SBOM, using the attestation file for each.
What a pass tells you: the artifact was produced by the project's GitHub workflow from that source and tag, and the attestation is signed. You can print the provenance to see the build details. What it does not tell you: that the source code has no bugs. Provenance proves where something came from, not that it is safe.
How do you enforce verification on the cluster?
The documentation encourages verifying signatures and provenance with an admission or policy controller, so an image built by someone else is rejected before it runs. It says cosign signatures and SLSA provenance work with several admission controllers, and points to the cosign and slsa-github-generator documentation for supported ones. Doing it once by hand during an upgrade is useful. Doing it in policy on every pod is what protects you.
How do you protect the Git source Argo CD syncs?
GitOps means the repository is the control plane. Anyone who can push to the tracked branch can change production. Argo CD's source integrity feature lets you declare criteria that, when not met, prevent an application from syncing and produce a ResourceComparison error. You configure it per project in the AppProject's sourceIntegrity field. Supported today: Git GnuPG verification, which checks that commits are GnuPG signed. Each application can be subject to several checks, and sync is enabled only when all criteria are met. Multi-source applications can have different criteria per source.
Know the limits listed in the documentation. Source integrity is configured through AppProject manifests or the CLI, not the UI yet. Signature verification is not supported for ApplicationSets populated by the git generator when their project field is templated. And if enforcement is on, syncing from local sources with the CLI's local flag stops working. The older GPG signature verification feature is described as deprecated, to be removed in the next major version, with source integrity as its replacement.
Constructed example
A platform team tracks a main branch in an infrastructure repository. A contractor's laptop token is stolen, and an attacker pushes a commit that changes an image reference. With source integrity on, the new commit is unsigned, so sync fails with an error instead of rolling the change to the cluster. The team sees the failure, revokes the token and reviews the commit. Without the check, the change would have deployed within the sync interval.
What to do
- Pin the Argo CD version you run and verify its images and CLI with slsa-verifier or cosign before each upgrade.
- Store the verification step in your upgrade runbook, with the expected source and tag.
- Add an admission policy that requires signatures and provenance for images in your clusters.
- Create AppProjects with sourceIntegrity for production repositories, and distribute trusted public keys through a controlled process.
- Require signed commits and branch protection in the repository itself, so signatures mean something.
- Plan the move off the deprecated GPG signature settings.
- Test the failure path once and confirm someone is alerted.
Safeguard can generate and scan SBOMs for the images you deploy and apply policy gates in pull requests, which sits alongside these controls.
Quick check
Does a valid SLSA attestation mean the image is safe?
No. It shows where and how the artifact was built. You still need scanning for vulnerabilities in its contents.
What happens when source integrity fails?
The application cannot sync, and Argo CD reports a ResourceComparison error until the criteria are met.
Sources
- Argo CD documentation, Verification of Argo CD Artifacts
- Argo CD documentation, Source Integrity Verification
- Argo CD documentation, GnuPG signature verification
Last reviewed: 18 October 2026.
