Skip to content

Argo CD provider

Parses Argo CD documents from .yaml / .yml files on disk, text- only static analysis, no argocd binary, no cluster access. Recognized kinds: Application, ApplicationSet, AppProject (all under apiVersion: argoproj.io/v1alpha1), plus the core v1 ConfigMap documents named argocd-cm or argocd-rbac-cm where Argo CD's instance-wide config lives. Other documents (including Argo Workflows CRDs, which belong to the argo provider) are silently skipped.

Producer workflow

pipeline_check --pipeline argocd --argocd-path applications/

# A single Application file works too.
pipeline_check --pipeline argocd --argocd-path applications/payments.yaml

# Argo CD + Argo Workflows together; each provider's kind filter
# is disjoint so pointing both at the same dir produces disjoint
# findings, not duplicates.
pipeline_check --pipelines argo,argocd --argo-path ci/ --argocd-path ci/

All other flags (--output, --severity-threshold, --checks, --standard, …) behave the same as with the other providers.

Argo CD-specific checks

  • ARGOCD-004 walks data.policy.csv (and any data.policy.<role>.csv) on the argocd-rbac-cm ConfigMap line by line, ignoring comments and explicit denies. The unintuitive bit: argocd-rbac-cm is a plain kind: ConfigMap, not an argoproj.io CRD, so this rule fires off Kubernetes ConfigMap docs that have to be passed in alongside the Application manifests.
  • ARGOCD-007 flags Helm valueFiles / parameters that interpolate generator placeholders ({{branch}}, {{repo}}) without the ApplicationSet setting spec.goTemplate: true. Argo CD's default fasttemplate substitution is a literal string-splice and a generator-controlled value containing YAML structural characters lands verbatim in the rendered values.

What it covers

19 checks · 0 have an autofix patch (--fix).

Check Title Severity Fix
ARGOCD-001 Argo CD AppProject permits any source repository HIGH
ARGOCD-002 Argo CD AppProject permits any destination cluster or namespace HIGH
ARGOCD-003 Argo CD Application auto-sync prunes without selfHeal guardrail MEDIUM
ARGOCD-004 Argo CD RBAC policy grants wildcard authority CRITICAL
ARGOCD-005 Argo CD repository entry stores plaintext credentials CRITICAL
ARGOCD-006 Argo CD ApplicationSet PR/SCM generator without project allowlist HIGH
ARGOCD-007 Argo CD Helm parameters interpolate generator output without goTemplate HIGH
ARGOCD-008 Argo CD Application invokes a config-management plugin MEDIUM
ARGOCD-009 Argo CD anonymous access enabled CRITICAL
ARGOCD-010 Argo CD Application targetRevision uses a mutable ref HIGH
ARGOCD-011 Argo CD AppProject cluster-resource whitelist is wide open HIGH
ARGOCD-012 Argo CD AppProject defines no sync windows MEDIUM
ARGOCD-013 Argo CD Application sets no explicit revisionHistoryLimit LOW
ARGOCD-014 Argo CD web terminal enabled via exec.enabled CRITICAL
ARGOCD-015 Argo CD Kustomize build options enable the Helm plugin HIGH
ARGOCD-016 Application Helm valueFiles fetched from a remote URL HIGH
ARGOCD-017 Argo CD in-cluster Application deploys from a mutable source HIGH
ARGOCD-018 argocd-cm ships custom resource health / action Lua MEDIUM
ARGOCD-019 Argo CD Application disables drift detection on a sensitive field HIGH

ARGOCD-001: Argo CD AppProject permits any source repository

HIGH CICD-SEC-5 CICD-SEC-1 ESF-C-LEAST-PRIV CWE-862

Fires when spec.sourceRepos contains "*" (case-sensitive). Also fires when the field is missing or empty, matching Argo CD's pre-2.5 default-allow behavior.

Recommended action

Replace sourceRepos: ['*'] with the explicit list of Git remotes the project is allowed to deploy from. A wildcard means any user who can create an Application under this project can point it at any repo Argo CD's service account has credentials for, including private internal repos with secrets in their manifests.

ARGOCD-002: Argo CD AppProject permits any destination cluster or namespace

HIGH CICD-SEC-5 ESF-C-LEAST-PRIV CWE-862

Walks spec.destinations[]. Fires when any entry sets server or name to "*" or sets namespace to "*". Both axes evaluated independently; either wildcarded fails the check.

Recommended action

Replace server: '*' / namespace: '*' in spec.destinations[] with explicit cluster URLs and namespace lists. A wildcard destination lets any Application under the project deploy to kube-system on the management cluster, which converts an Application-create permission into cluster-admin.

ARGOCD-003: Argo CD Application auto-sync prunes without selfHeal guardrail

MEDIUM CICD-SEC-7 ESF-O-DEPLOY-CONTROL CWE-732

Walks spec.syncPolicy.automated on every Application. Fires when prune: true is set and selfHeal is either missing or explicitly false. Auto-sync without prune is ignored, the failure mode this rule tracks is the prune-without-detect combination.

Recommended action

If you enable syncPolicy.automated.prune: true (auto-deletes resources that disappear from git), enable selfHeal: true alongside it so any out-of-band hotfix is detected and reconciled rather than silently kept. The common failure mode is an oncall hand-applies a fix in a fire, then Argo CD prunes it on the next auto-sync because the change isn't in git, recreating the incident.

ARGOCD-004: Argo CD RBAC policy grants wildcard authority

CRITICAL CICD-SEC-2 ESF-C-LEAST-PRIV CWE-732 CWE-269

Parses the policy.csv (and any policy.<role>.csv) key on data: in the argocd-rbac-cm ConfigMap. Fires on lines tokenizing to p, <role>, *, *, *, allow, p, <role>, applications, *, */*, allow, or g, <subject>, role:admin. Comment lines (#) and explicit denies (..., deny) are ignored.

Recommended action

Scope each p, <role>, <resource>, <action>, <object>, allow line in argocd-rbac-cm policy.csv to a specific resource / action / object. Replace *, *, *, *, allow and applications, *, */*, allow patterns with explicit per-project grants (applications, get, payments/*, allow). Restrict g, …, role:admin bindings to a single named SSO group.

ARGOCD-005: Argo CD repository entry stores plaintext credentials

CRITICAL CICD-SEC-6 ESF-D-SECRETS CWE-798

Parses data.repositories (and the legacy repository.credentials key) on argocd-cm as YAML. For each entry, fires when a password, sshPrivateKey, tlsClientCertKey, or githubAppPrivateKey field is a literal non-empty string. Entries using the documented passwordSecret / sshPrivateKeySecret indirection pass.

Recommended action

Don't write password / sshPrivateKey / tlsClientCertKey values directly into the repositories block of argocd-cm. Move the entry to a separate Kubernetes Secret carrying the credential (plus the argocd.argoproj.io/secret-type: repository label) and reference it; or move the whole repo block to a Secret of type repo-creds. ConfigMap data is world-readable to every namespace member with configmaps: get.

ARGOCD-006: Argo CD ApplicationSet PR/SCM generator without project allowlist

HIGH CICD-SEC-1 CICD-SEC-4 ESF-D-CODE-INTEGRITY CWE-1357

Walks spec.generators[]. Fires when a generator entry carries a pullRequest or scmProvider key (or a git generator with directories / files) AND spec.template.spec.project is either the literal default or contains a generator-template placeholder like {{repo}} / {{branch}} / {{path[0]}}. Static project + filtered generator passes.

Recommended action

When using pullRequest or scmProvider generators, pin template.spec.project to a single static project name (not a generator-interpolated placeholder) and constrain the generator with a filters: branchMatch / labels block. Otherwise an attacker who opens a PR (or creates a repo in the matched org) materializes a new Argo CD Application under whatever project the placeholder resolves to.

ARGOCD-007: Argo CD Helm parameters interpolate generator output without goTemplate

HIGH CICD-SEC-4 CICD-SEC-1 ESF-D-INJECTION CWE-94

Walks spec.template.spec.source.helm.valueFiles[] and parameters[].value on ApplicationSets, plus the single-Application equivalent. Fires when the value contains a {{...}} placeholder and the enclosing ApplicationSet doesn't set spec.goTemplate: true. Single-Application Helm sources are checked too: a placeholder there always indicates an upstream ApplicationSet so the same flag must be set.

Recommended action

Set spec.goTemplate: true on the ApplicationSet (with goTemplateOptions: ['missingkey=error']) so generator placeholders go through Go's template engine, which respects YAML quoting. Without it, Argo CD's default fasttemplate substitution is a literal string-splice, so a generator-controlled value containing newlines, shell metacharacters, or YAML structural characters lands verbatim in the rendered Helm values.

ARGOCD-008: Argo CD Application invokes a config-management plugin

MEDIUM CICD-SEC-3 CICD-SEC-4 ESF-S-VERIFY-DEPS CWE-94

Walks spec.source.plugin on every Application and ApplicationSet template. Fires whenever a plugin: block is present; a missing or empty name is reported as plugin (unnamed). Helm and Kustomize sources are ignored (they're separately covered by ARGOCD-007 / future Kustomize rules). This is a deliberate noisy-but-correct v1, suppress per-Application once you've reviewed the CMP.

Recommended action

CMPs are arbitrary code: Argo CD execs generate.command inside the repo-server pod at every sync, with whatever manifest content the source repo ships. Audit the CMP's discover.find.command allowlist, confirm generate.command doesn't shell out to user-controlled input, and treat each plugin invocation as a build-step review item, not a Kustomize / Helm equivalent.

ARGOCD-009: Argo CD anonymous access enabled

CRITICAL CICD-SEC-2 ESF-C-LEAST-PRIV CWE-306

Reads data.users.anonymous.enabled on the argocd-cm ConfigMap. ConfigMap data values are always stringified by Kubernetes, but the YAML loader can hand us either "true" or boolean true depending on how the manifest was written, so both forms fail the check.

Recommended action

Remove the users.anonymous.enabled: "true" entry from argocd-cm (or set it to "false"). With anonymous access on, the Argo CD UI / API answers requests carrying no token, and whatever permissions role:readonly (or the default policy) grants are reachable without authentication.

ARGOCD-010: Argo CD Application targetRevision uses a mutable ref

HIGH CICD-SEC-3 CICD-SEC-5 ESF-S-PIN-DEPS ESF-S-VERIFY-DEPS CWE-1357 CWE-829

Reads spec.source.targetRevision (or each entry in spec.sources[].targetRevision for multi-source apps) and fires when the value matches a mutable-ref shape: HEAD, branch-name literals (main / master / develop / release-*), or any non-SHA non-SemVer string. Also walks ApplicationSet documents via spec.template.spec.source[s], because an ApplicationSet with a mutable ref generates Applications that all track that same mutable branch. Immutable shapes that pass:

  • 40-character hex commit SHA
  • SemVer literal (1.2.3, 1.2.3-rc.1)
  • v-prefixed SemVer (v1.2.3)

Helm chart sources (spec.source.chart set) follow the same rule: targetRevision should be a SemVer literal, not a range or branch.

Known false-positive modes

  • Some staging environments deliberately track main for fast iteration on dev workloads. The rule still fires; suppress per Application with a one-line rationale naming the environment's intentional drift posture. Production environments should not be suppressed.

Seen in the wild

  • Long-running pattern of Argo CD deployments tracking HEAD on the default branch and silently picking up every push to that branch. Force-pushes to the branch (intentional or via maintainer-account compromise) redirect the deploy without any Argo CD-side review; SHA-pinned deployments survive the same incident because the ref content is content-addressed.

Recommended action

Pin every Application source to an immutable ref. Three stable shapes:

  • targetRevision: <40-char-commit-sha> for git sources. The SHA binds to specific content; force-push and tag-move can't redirect the deploy.
  • targetRevision: v1.2.3 for git sources where signed tags are the org's release convention AND the repo enforces tag-immutability (signed tags + branch protection denying tag-rewrite). Without the protection, treat tags as mutable and pin the SHA instead.
  • targetRevision: 1.2.3 for Helm chart references where the chart repo enforces version-immutability (chart museum default, OCI registry default). SemVer pins to a published chart digest.

Branch refs (main / master / HEAD) follow the branch tip on every reconcile; whoever has push access to the branch controls what Argo CD deploys. This is the GitOps analog of GHA-001 actions/checkout@v4 and carries the same exposure window.

ARGOCD-011: Argo CD AppProject cluster-resource whitelist is wide open

HIGH CICD-SEC-1 CICD-SEC-5 ESF-C-LEAST-PRIV CWE-862 CWE-269

Reads spec.clusterResourceWhitelist from each AppProject and fires when the list contains an entry with {group: '*', kind: '*'} (the explicit wildcard). The empty-list default passes the rule (it blocks all cluster-scoped writes). Partially-wildcarded entries ({group: '*', kind: ClusterRole} or {group: rbac.authorization.k8s.io, kind: '*'}) also trip the rule because either axis being a wildcard means the other axis can't bound the blast radius.

Pairs with ARGOCD-002 (destinations wildcard, which controls where an Application can deploy). This rule controls what kinds it can deploy.

Known false-positive modes

  • Operator-installation projects that legitimately need broad cluster-resource creation rights (the only way to install some operators is via CRD + ClusterRole + ClusterRoleBinding). Suppress per project with a one-line rationale naming the operator and the install procedure that requires the broad rights.

Seen in the wild

  • Common over-provisioning pattern: a contributor adds clusterResourceWhitelist: [{group: '*', kind: '*'}] to an AppProject during an operator install, never tightens it back. Months later, an Application under that project is deployed with a malicious ClusterRoleBinding (via a compromised git commit or a typo in a values file); the binding lands without any AppProject-side gate.

Recommended action

Restrict spec.clusterResourceWhitelist to the exact (group, kind) tuples the project's Applications need. The default (an empty list) blocks all cluster-scoped writes, which is the safest posture for namespace-scoped workloads. A wildcard ({group: '*', kind: '*'}) allows the project to install ClusterRoleBindings, CustomResourceDefinitions, ValidatingAdmissionWebhooks, and PodSecurityPolicies — every category capable of cluster takeover.

Typical narrow allowlist for a workload project:

spec:
  clusterResourceWhitelist: []
  namespaceResourceWhitelist:
    - { group: '', kind: ConfigMap }
    - { group: '', kind: Service }
    - { group: apps, kind: Deployment }

Projects that legitimately install cluster-scoped resources (an operator project, a CRD-management project) should enumerate the specific kinds, never wildcards.

ARGOCD-012: Argo CD AppProject defines no sync windows

MEDIUM CICD-SEC-4 CICD-SEC-1 ESF-C-APPROVAL ESF-C-DEPLOY-MON CWE-285

Reads spec.syncWindows from each AppProject and fires when the field is missing or empty AND the project's destinations include a production-shaped namespace (literal prod, production, or any namespace name containing prod). The production-shape heuristic keeps the rule from firing on dev / staging projects where instant reconciliation is the deliberate posture.

Sync windows complement ARGOCD-003 (automated sync without selfHeal) at the schedule layer: ARGOCD-003 catches the drift-revert hazard, this catches the change-freeze hazard.

Known false-positive modes

  • Hosting / SaaS environments that intentionally deploy continuously across all hours (24/7 always-on update cadence) trip this rule. Suppress per project with a one-line rationale naming the continuous-deploy policy. Most production environments benefit from at least a weekend / overnight freeze.

Seen in the wild

  • Common change-control gap: a Friday-evening force-push to the manifests repo lands in production within minutes via Argo CD's automated sync. The on-call team is paged for the resulting outage hours later, by which point the responsible contributor is offline. Sync windows would have blocked the deploy until Monday's business hours, buying time for a manual review.

Recommended action

Define explicit spec.syncWindows entries on every AppProject that gates production deploys. A sync window is a calendar-style rule that allows or denies automated / manual sync during specific schedules. Without windows, every git commit can be reconciled to production instantly — fine for staging, dangerous for prod where off-hours change-freezes (weekend / on-call rotations / active-incident windows) are normal posture.

Example: deny automated sync outside business hours but still allow manual sync (for break-glass deploys):

spec:
  syncWindows:
    - kind: deny
      schedule: "0 18 * * *"
      duration: 14h
      applications: ['*']
      manualSync: true   # operators can still sync manually

Pair with manualSync: false on incident-window blackouts to fully freeze, and with a separate kind: allow window for the release-rehearsal cadence.

ARGOCD-013: Argo CD Application sets no explicit revisionHistoryLimit

LOW CICD-SEC-7 ESF-C-AUDIT CWE-770

Reads spec.revisionHistoryLimit and fires when the field is missing or set to null. The rule is informational-leaning LOW: storage bloat and prolonged-secret-exposure are real but slow-moving risks, not exploitable surfaces an attacker can compromise in isolation.

Known false-positive modes

  • Sandbox / experimental Applications where rollback is irrelevant trip this rule by design. Suppress per Application with a one-line rationale.

Seen in the wild

  • Stale-secret pattern in older Argo CD versions: an Application that referenced a secret directly in a manifest (later moved to a sealed-secret / external secret reference) retains the original plaintext manifest in revision history. argocd app history and the controller API surface the old manifest verbatim, including the plaintext value, until the revision history limit is reached.

Recommended action

Set spec.revisionHistoryLimit to an explicit small integer (5-20 is the typical range) on every Application. The field caps how many prior synced revisions Argo CD retains for rollback. Unbounded retention keeps stale manifests (and any secrets they referenced) accessible via the Argo CD API indefinitely and grows the controller's storage footprint without bound.

Example:

spec:
  revisionHistoryLimit: 10  # keep last 10 syncs for rollback

Pick the cap based on the application's rollback need: a stateless web service rarely benefits from more than 5 history entries; an infrastructure controller managing external state may want 20 for forensic comparison across longer windows.

ARGOCD-014: Argo CD web terminal enabled via exec.enabled

CRITICAL CICD-SEC-2 ESF-C-LEAST-PRIV CWE-284 CWE-668

Reads data.exec.enabled on the argocd-cm ConfigMap. ConfigMap data values are always stringified by Kubernetes, but the YAML loader can hand us either "true" or boolean true depending on how the manifest was written, so both forms fail the check. The terminal also needs the exec RBAC verb; this rule fires on the global toggle regardless of the RBAC scope.

Known false-positive modes

  • Platform teams that restrict the exec RBAC verb to a small break-glass role sometimes accept the terminal being enabled. The rule still fires; confirm the RBAC scope (see ARGOCD-004) before treating it as benign, and suppress per instance with a rationale naming the scoped role.

Recommended action

Set exec.enabled to "false" in argocd-cm (or drop the key, since the terminal is off by default). If a terminal is genuinely needed for break-glass debugging, gate it behind a narrowly scoped exec RBAC role bound to a single named group, and audit every session. The web terminal opens an interactive shell into any managed pod, so it sits at the top of the blast-radius ladder.

ARGOCD-015: Argo CD Kustomize build options enable the Helm plugin

HIGH CICD-SEC-4 ESF-S-PIPELINE-INTEGRITY CWE-94 CWE-829

Reads data.kustomize.buildOptions on the argocd-cm ConfigMap and fires when the value contains the --enable-helm token. kustomize build --enable-helm lets a kustomization.yaml declare helmCharts that Kustomize fetches and templates, turning a Kustomize app into a remote chart fetch-and-execute path.

Known false-positive modes

  • Some teams legitimately inflate trusted in-repo charts through Kustomize and accept the global flag. The rule still fires; confirm every Kustomize app's chart sources are pinned and trusted, then suppress with a rationale.

Recommended action

Remove --enable-helm from kustomize.buildOptions in argocd-cm. The flag is global: once set, every Kustomize Application on the instance can inflate Helm charts at build time, fetching and rendering remote charts instead of staying a plain set of manifests. If a chart is required, model it as a Helm source on the specific Application so it goes through the normal source review (ARGOCD-007 / ARGOCD-010).

ARGOCD-016: Application Helm valueFiles fetched from a remote URL

HIGH CICD-SEC-4 CICD-SEC-3 ESF-S-VERIFY-DEPS CWE-829 CWE-494

Walks every Application / ApplicationSet source and flags a helm.valueFiles entry whose value is an http:// or https:// URL. Path-form entries (a file inside the chart repo) and the multi-source $ref/path form are not flagged: those resolve against a revision-pinned Git source. Inline helm.values / valuesObject are also out of scope (they're committed with the Application).

A remote values file is an unpinned, unverified input to the Helm render, distinct from HELM-003 (the chart repository transport) and ARGOCD-007 (Helm parameter interpolation): this is the values file pulled from an arbitrary host.

Known false-positive modes

  • An internal, access-controlled values server that publishes immutable, content-addressed files may be used deliberately. Suppress per Application with a rationale; the durable fix is to track the values file in the chart's Git source or a revision-pinned $ref repo.

Seen in the wild

  • Unpinned-remote-input class: a render-time values file fetched over the network can be swapped to change what the chart deploys, the GitOps analog of pulling a build script from an attacker-controlled URL.

Recommended action

Don't point spec.source.helm.valueFiles at an http(s):// URL. A remote values file is fetched at render time from a host outside the chart's own repo, with no revision pin and no integrity check, so whoever controls that URL (or its DNS / TLS, or just the file behind it) can rewrite the values Argo CD renders the chart with, flipping image tags, injecting init containers, mounting secrets, or widening RBAC. Keep value files inside the chart's own Git-tracked source (a path in the same repo, pinned by the Application's targetRevision), or use the multi-source $ref form pointed at a revision-pinned repo you control. Argo CD's helm.valuesFileSchemes setting can hard-block remote schemes instance-wide.

ARGOCD-017: Argo CD in-cluster Application deploys from a mutable source

HIGH CICD-SEC-3 CICD-SEC-5 ESF-S-PIN-DEPS ESF-C-LEAST-PRIV CWE-1357 CWE-829

Fires when an Application's spec.destination.server is the canonical in-cluster value https://kubernetes.default.svc AND a source targetRevision is mutable (a branch, HEAD, or any non-SHA non-SemVer string). Reuses ARGOCD-010's immutable-ref helper, so 40-character commit SHAs and SemVer literals pass. Both single-source (spec.source) and multi-source (spec.sources[]) forms are checked. This is the in-cluster intersection of ARGOCD-010: ARGOCD-010 flags any mutable source, this rule raises the bar for the control-plane destination specifically.

Known false-positive modes

  • Bootstrap or app-of-apps Applications that intentionally manage the local cluster from a branch behind required-review branch protection may accept branch tracking. The rule still fires; suppress per Application with a rationale naming the branch-protection control.

Recommended action

Pin targetRevision to an immutable ref (a 40-character commit SHA or a signed, immutability-enforced tag) for any Application that targets the in-cluster API (spec.destination.server: https://kubernetes.default.svc). That destination is where Argo CD itself runs, so a push to a tracked branch can reshape the control-plane namespace with no manifest change and no Argo CD-side review. If the workload does not need to live next to Argo CD, move it to a dedicated remote cluster instead.

ARGOCD-018: argocd-cm ships custom resource health / action Lua

MEDIUM CICD-SEC-4 ESF-C-LEAST-PRIV CWE-94 CWE-829

Fires when argocd-cm carries one or more resource.customizations keys with a non-empty value, either the per-resource form (resource.customizations.health.<group_kind>, resource.customizations.actions.<group_kind>) or the legacy aggregate resource.customizations block whose value embeds health.lua / actions entries.

This is a posture / visibility signal (MEDIUM), not proof of compromise: custom health and action Lua is a normal, useful Argo CD feature. The rule surfaces the controller-side execution surface so a reviewer can confirm each script is trusted, minimal, and (for actions) narrowly scoped.

Known false-positive modes

  • Many production Argo CD instances legitimately define custom health checks for CRDs the built-ins don't cover. The rule fires on their presence; suppress per instance with a rationale once the scripts are reviewed, or scope the suppression to the specific resource keys.

Seen in the wild

  • Controller-side code-execution surface: resource-action Lua can patch managed objects, and health Lua runs against live cluster state on every reconcile, so an over-broad or attacker-supplied script in argocd-cm executes with the Argo CD controller's cluster access.

Recommended action

Treat every resource.customizations Lua block in argocd-cm as code that runs inside the Argo CD application controller. Health-check and resource-action Lua is evaluated by the controller against live cluster objects on every reconcile, so a malicious or buggy script runs with the controller's broad read (and, for actions, mutate) access to managed resources. Review each script, keep them minimal and side-effect-free (health scripts should only read obj and return a status; actions should be narrowly scoped), gate changes to argocd-cm behind the same review as RBAC changes, and prefer the built-in health checks where they suffice. Anyone who can edit argocd-cm can ship controller-side code, so the ConfigMap's write access is part of this rule's threat model.

ARGOCD-019: Argo CD Application disables drift detection on a sensitive field

HIGH CICD-SEC-5 ESF-C-LEAST-PRIV CWE-1059 CWE-778

Fires when an Application (or ApplicationSet template) sets syncPolicy.syncOptions to include Validate=false (server-side schema validation off, cluster-wide for that app), or carries a spec.ignoreDifferences entry whose jsonPointers / jqPathExpressions / kind references a security-relevant field (image, RBAC rules / subjects / roleRef, securityContext, host namespaces, service account, capabilities). A non-security ignoreDifferences (a replica count, a webhook-injected annotation) does not fire, to keep the false-positive rate low. Distinct from ARGOCD-003 (auto-sync prune / selfHeal, a reliability guardrail) and ARGOCD-010 / 017 (mutable source ref): those reason about the input; this flags the controller being told to ignore what it deploys.

Known false-positive modes

  • ignoreDifferences legitimately suppresses controller-owned drift (HPA replica counts, cert-manager-injected CA bundles, webhook defaults). Those paths don't carry the sensitive tokens this rule matches, so they pass. If a sensitive-looking path is genuinely benign in your setup, suppress per Application with a rationale.

Recommended action

Don't add spec.ignoreDifferences on a security-relevant field (a container image, a Role/ClusterRole rules, a RoleBinding subjects / roleRef, a securityContext), and don't set syncPolicy.syncOptions: [Validate=false]. Both tell Argo CD to stop enforcing the field's desired state, so an attacker who edits the live object out of band (or lands a drift the controller now ignores) keeps the change while the dashboard stays Synced / Healthy. If a field is genuinely controller-owned (an HPA-managed replica count, a webhook-injected annotation), scope the ignoreDifferences entry to exactly that non-security field and document why.

Adding a new Argo CD check

  1. Create a new module at pipeline_check/core/checks/argocd/rules/argocdNNN_<name>.py exporting a top-level RULE = Rule(...) and a check(ctx: ArgoCDContext) -> Finding function. The orchestrator auto-discovers RULE and calls check with the ArgoCDContext.
  2. Add a mapping for the new ID in pipeline_check/core/standards/data/owasp_cicd_top_10.py (and any other standard that applies).
  3. Drop unsafe/safe snippets at tests/fixtures/per_check/argocd/ARGOCD-NNN.{unsafe,safe}.yml and add a CheckCase entry in tests/test_per_check_real_examples.py::CASES.
  4. Regenerate this doc:
python scripts/gen_provider_docs.py argocd