We do not anticipate this project being used in commercial products. See LF-Supported Projects and CRA Readiness for more information.

Each helm chart currently supports the designated application version in the Chart.yaml. There is a chance a security issue you've discovered may not be with the helm chart but with the upstream application. Please visit that application's Security policy document to find out how to report the security issue.

• Security Policy for Argo Workflows
• Security Policy for Argo Events
• Security Policy for Argo Rollouts
• Security Policy for Argo CD
• Security Policy for Argo CD Image Updater

We have enabled the ability to privately report security issues through the Security tab above.

Here are the details on how to file on how to do that

A repository owner/maintainer will respond as fast as possible to coordinate confirmation of issue and remediation.

Thank you for helping to ensure this code stays secure.

Argo Helm is maintained by volunteers, so these are targets, not guarantees. We aim to acknowledge a report within 10 business days and to share an initial assessment (validity, severity, affected charts) within 10 business days of acknowledgement.

Details stay private until a fix is released or 90 days have passed since confirmation, whichever comes first, unless the reporter and maintainers agree to a different timeline. We publish a GitHub Security Advisory with the affected chart versions and remediation steps, and credit the reporter unless they ask to stay anonymous.

Renovate tracks upstream application versions and container images. Dependabot tracks GitHub Actions. Chart dependencies (argo-cd's redis-ha) are bumped by hand. Vulnerabilities in the upstream Argo applications follow that application's security policy, linked above.

Renovate opens a pull request when a container image it tracks publishes a new version, and maintainers merge those as review time allows. Nothing in CI scans dependencies for vulnerabilities, and releases are not gated on them. argo-cd's redis and HAProxy images aren't currently bumped by Renovate and can fall behind upstream fixes (see #4098).

Dependencies must use an OSI-approved license. A dependency with a disallowed license must be replaced or removed. Disallowed licenses are any license that is not OSI-approved, including source-available licenses such as SSPL-1.0, BUSL-1.1, and Elastic-2.0. A new dependency under a strong copyleft license, such as GPL or AGPL, needs maintainer review before it is added.

zizmor audits GitHub Actions workflows, and actionlint and shellcheck check workflows and scripts, on every pull request (see .github/workflows/actions-lint.yaml). All three are required status checks.

Low, medium, and high severity findings must be fixed, or suppressed in .github/zizmor.yml with a documented reason, before the pull request merges.

The workflows in this repository keep long-lived credentials to a minimum:

• Each job gets a GitHub token limited to the permissions that job declares.
• Renovate and the PR lifecycle workflow trade the job's OIDC identity for a short-lived token through octo-sts. Their trust policies live in .github/chainguard.
• Publishing OSPS Baseline results authenticates with the job's OIDC identity and stores no credential.
• The PGP chart signing key and its passphrase are the only long-lived credentials the workflows use. They are GitHub Actions secrets, which only repository administrators can change. The publish workflow writes the key to a temporary directory and deletes it when the signing step ends.

Maintainers rotate a credential when someone with access to it leaves the project or when it may have been exposed.