Why do encrypted secrets still create operational risk in GitOps?

Why This Matters for Security Teams

Encrypted secrets in GitOps are often treated as a solved problem because the repository no longer stores plaintext. The operational risk shifts, not disappears. The real exposure moves to key custody, resealing workflows, review gates, and the timing gap between secret creation, rotation, and deployment. That gap matters when the secret protects production APIs, cloud control planes, or CI/CD tooling.

GitOps also normalises speed, which makes teams reluctant to interrupt delivery for reseal and approval steps. Over time, this creates a quiet accumulation of stale credentials that remain valid long after the application, cluster, or service account has changed. NHIMG’s Guide to the Secret Sprawl Challenge shows how quickly secrets inventory drifts once operational convenience starts driving exceptions. The pattern is consistent with what the OWASP Non-Human Identity Top 10 warns about: protecting the stored secret is only one part of governing the identity behind it.

In practice, many security teams encounter the compromise after a pipeline failure, a missed rotation, or a noisy incident review, rather than through intentional lifecycle control.

How It Works in Practice

In GitOps, encrypted secrets are usually committed as sealed values, then decrypted or unsealed by a controller, operator, or deployment process at runtime. This reduces direct exposure in Git, but it introduces a dependency chain that must remain healthy and correctly governed. The important questions become: who can unseal, where the keys live, how often they rotate, and what happens when a secret changes faster than the release cadence.

For operational teams, the risk often emerges in four places:

• Key custody: the encryption key or unsealing mechanism becomes a high-value target.
• Resealing overhead: every secret change requires extra workflow steps, which teams may delay.
• Review friction: approvers often cannot easily validate whether the encrypted value is current.
• Rollback ambiguity: older manifests may still reference credentials that remain technically valid.

That is why current guidance suggests treating encrypted secrets as a transport control, not an identity control. The stronger model is to shorten secret lifetime and prefer dynamic issuance where possible. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is clear that static credentials create long-lived operational exposure, especially when they are embedded in delivery workflows. The NIST Cybersecurity Framework 2.0 also supports continuous control review, which is a better fit than one-time encryption checks.

Where possible, teams should pair encrypted manifests with workload identity, automatic rotation, and policy-based deployment gates so the secret is issued for use rather than preserved for convenience. These controls tend to break down when multiple clusters, emergency hotfixes, and manual overrides share the same GitOps path because resealing discipline degrades fastest under release pressure.

Common Variations and Edge Cases

Tighter secret handling often increases delivery overhead, requiring organisations to balance confidentiality against operational speed. That tradeoff becomes more visible in multi-cluster environments, regulated release pipelines, and teams that still depend on human-approved promotions. Best practice is evolving, but there is no universal standard for whether every secret should be encrypted in Git, stored in an external secret manager, or replaced with ephemeral credentials.

Some teams only encrypt a subset of secrets, such as database passwords, while leaving cloud credentials, webhook tokens, or signing keys to other systems. That can be sensible, but it creates uneven governance unless the lifecycle rules are equally strict across all secret classes. If the deployment platform can decrypt secrets automatically, the repository still becomes part of the trust boundary, and the unsealing key becomes the real control point.

In high-change environments, the biggest failure mode is not decryption itself but drift: an encrypted secret can survive multiple application revisions because no one wants to break a working rollout. That is why the operational question is not simply “Is it encrypted?” but “How quickly can it be rotated, revoked, and verified?” For breach context, NHIMG’s 52 NHI Breaches Analysis and The 2024 ESG Report: Managing Non-Human Identities both reinforce that compromised non-human identities are rarely one-off events. Environments with frequent hotfixes and manual resealing shortcuts are where encrypted secrets most often stop behaving like a control and start behaving like operational debt.

Related resources from NHI Mgmt Group

• Why do encrypted secrets still create risk in cloud automation?
• Why do encrypted playbooks still create secrets risk?
• Why do credential platforms still create governance risk even when secrets are encrypted?
• Why do encrypted secrets still create risk in plugin ecosystems?