OWASP Secrets Management Cheat Sheet: What You Need to Know

Most platform engineers will recognize this one.

It is 2am. PagerDuty fires. A production service is returning 500s. The on-call engineer traces the failure to an expired TLS certificate on an internal service mesh endpoint. The certificate was issued 14 months ago. No one remembers who issued it, which CA signed it, or what the renewal process is. The engineer finds a Confluence page with partial instructions that reference a Vault path that no longer exists.

The fallback is to SSH into the service, generate a self-signed cert, and restart. The outage lasts 47 minutes. The post-mortem reveals that three other certificates in the same cluster are due to expire within the next two weeks.

Or this one: a Terraform apply against production fails because a database credential was rotated in AWS Secrets Manager, but the Terraform state file still references the old credential. The rotation was done manually by a security engineer who followed a runbook that did not include "update Terraform state" as a step. The production deploy is blocked for two hours while three teams coordinate a fix.

These are not hypothetical edge cases. They are the kinds of operational failures that happen when secrets management is treated as a set of individual tool decisions rather than a system-level discipline.

The OWASP Secrets Management Cheat Sheet is the best publicly available starting point for building that discipline. It is part of the OWASP Cheat Sheet Series, a community-maintained collection of concise security references that covers the full secrets lifecycle: how secrets should be created, stored, accessed, rotated, revoked, audited, and managed across CI/CD pipelines, cloud providers, containers, and multi-cloud environments.

The sections below break down where the OWASP guidance is strongest, where it is thin, and how each recommendation maps to the operational reality of running infrastructure at scale.

What the OWASP Secrets Management Cheat Sheet Covers

The cheat sheet spans 11 sections: general secrets management principles, CI/CD pipelines, cloud providers, containers and orchestrators, implementation guidance, encryption, detection, incident response, and multi-cloud environments.

Types of secrets covered:

• API keys

• Database credentials

• SSH keys

• TLS certificates

• Encryption keys

• Service account tokens

• IAM permissions

• OAuth client secrets

• Signing keys

The content is most useful for the people who own how secrets flow through infrastructure: platform engineers, DevOps teams, SREs, security engineers, and infrastructure architects.

The Sprawl Problem: Why Centralization Is the First Thing to Get Right

The OWASP cheat sheet opens with centralization and standardization, and it is correct to do so. In most organizations, the secrets problem is not that individual secrets are poorly managed. It is that secrets are everywhere, managed differently in each location, with no unified view of what exists, who owns it, or when it was last rotated.

A typical enterprise with dozens of engineers might have secrets in:

• AWS Secrets Manager for production workloads on AWS

• Azure Key Vault for the Azure footprint

• GitHub Actions secrets for CI pipelines

• GitLab CI/CD variables for a team that uses GitLab

• Kubernetes Secrets in three different clusters

• Environment variables in Docker Compose files for local development

• A HashiCorp Vault instance that two teams use and no one else trusts

• A spreadsheet on SharePoint that the SRE team maintains for on-prem infrastructure

• .env files committed to private repos (yes, still)

OWASP acknowledges this reality. Centralization can mean using multiple secrets management solutions, as long as the interaction patterns and lifecycle management are standardized. The cheat sheet also makes a point that is easy to miss: the root credentials for the secrets management system itself need to be stored somewhere else. You always end up with at least two systems.

Where OWASP is strong

The emphasis on standardization over consolidation is the right framing. Telling a large organization "put everything in one tool" is not realistic advice. Different teams have different constraints. Cloud-native teams may need to use their cloud provider's native secrets management for latency or integration reasons. On-prem workloads need a solution that runs on-prem.

The point is that every team should follow the same lifecycle practices (creation, rotation, revocation, auditing, and access control) regardless of which tool they use.

Where OWASP is thin

The cheat sheet does not say much about the operational cost of sprawl during incident response. When a credential is compromised, the first question is "where is this secret used?" If the answer requires checking six different systems with six different access control models and six different audit log formats, your mean time to containment just tripled.

Access Control: The Gap Between Policy and Reality

The OWASP cheat sheet recommends fine-grained access controls at the individual secret level, and the Least Privilege principle applied to every user and service that touches the secrets management system.

This is correct, and also the recommendation most frequently ignored in practice.

Why it gets ignored

Implementing fine-grained access control is tedious work that requires ongoing maintenance. It is far easier to give the DevOps team a shared admin role than to define per-secret or per-project policies for 40 services. The result is that most organizations have access policies that were "good enough" when they were created and have drifted since then.

The more common failure mode is not that someone deliberately grants overly broad access. It is that access accumulates over time. An engineer is added to a project, gets access to its secrets, moves to another team, and the original access is never revoked. After two years, 30% of the engineers in the organization have access to secrets they no longer need and probably do not know they have.

What OWASP gets right

The emphasis on fine-grained controls is correct. Secret-level permissions are better than vault-level or project-level permissions. The cheat sheet notes that Azure Key Vault historically granted access at the vault level rather than the secret level under its legacy access policy model, which meant separate key vaults were required to segregate access.

Azure RBAC now supports secret-level role assignments, but many organizations still run the legacy model, and the OWASP guidance reflects that older default. Either way, it is a real architectural consideration that teams overlook.

What is missing from the OWASP guidance

Automated access lifecycle management. In organizations with dozens or hundreds of engineers, people change roles, leave the company, and move between teams frequently. Access reviews should be automated and tied to your identity provider. When someone is offboarded in your IdP, their secrets management access should be revoked within minutes, not added to a manual checklist that gets completed "when someone gets to it."

Approval workflows. In regulated environments, accessing certain secrets requires documented approval. This is not just an access control problem. It is a workflow problem. If the approval process requires a Jira ticket and a Slack message and a manual policy update, engineers will find workarounds. Built-in approval workflows within the secrets management platform are what close this gap.

Rotation and Dynamic Secrets: Where Automation Makes or Breaks You

The OWASP recommendations on rotation and dynamic secrets are sound: rotate secrets regularly, automate the process, use dynamic (short-lived) secrets wherever possible.

What the cheat sheet does not fully convey is how badly manual rotation breaks down at scale.

The manual rotation failure pattern

The pattern is predictable:

1. A security team sets a policy: all database credentials must be rotated every 90 days.

2. They create a runbook with 12 steps.

3. For the first two rotation cycles, it works.

4. By the third cycle, the engineer doing the rotation discovers a fourth service now depends on this credential, but it is not in the runbook.

5. The rotation breaks production.

6. After the incident, the rotation cadence quietly shifts from 90 days to "when we get around to it."

This plays out across nearly every organization that relies on manual rotation. It is not a people problem. It is a system design problem.

Dynamic secrets are the right answer (when they work)

OWASP recommends dynamic secrets where possible: credentials generated on the fly for a specific session, with a defined TTL. When an application starts, it requests database credentials. When it stops, the credentials expire.

This is the right architecture. It eliminates credential reuse, limits blast radius, and makes stolen credentials worthless after the TTL expires.

The limitation is that not every system supports dynamic credential creation. Legacy databases, third-party APIs, SaaS platforms, and many internal services still require static credentials. For those, automated rotation (not manual rotation) is the fallback.

Categorize every secret by its automation potential

Audit your secrets by two dimensions:

• Can this secret be dynamically generated? If yes, it gets dynamic secrets with short TTLs.

• Can its rotation be fully automated? If yes, it gets automated rotation on a schedule.

• Neither? That is your highest-risk inventory, and you should be actively working to shrink it.

Modern secrets management platforms that support dynamic secrets for databases, automated rotation policies, and integrations with the systems that consume those secrets are what make this feasible at scale. Without platform support, you are maintaining custom scripts for every rotation, and those scripts become their own maintenance burden.

Secrets in CI/CD: Your Pipeline Is a Production System

The OWASP cheat sheet gets one thing exactly right about CI/CD: treat your CI/CD tooling as a production environment.

Most organizations do not do this. The CI/CD pipeline is often the most privileged system in the entire infrastructure. It has credentials to deploy to production, access to secrets management systems, and the ability to modify running services. And yet it frequently has weaker access controls, less monitoring, and less hardening than the production systems it deploys to.

The three places a CI/CD secret can live

OWASP outlines three options:

1. In the CI/CD tooling itself (GitHub Actions secrets, GitLab CI/CD variables, Jenkins credentials). This is the most common approach and the most dangerous at scale. These secrets are visible to anyone with maintainer-level access to the repository. Forking a repository may or may not copy the secrets depending on the platform configuration. Pipeline output often leaks secrets through debug logging or error messages.

2. In a dedicated secrets management system that the pipeline authenticates to at runtime. This is better. The pipeline gets short-lived credentials to access the secrets it needs, scoped to the specific job. Attribution is maintained. But the pipeline still touches the secrets, which means a compromised pipeline can exfiltrate them.

3. Not in the pipeline at all. The pipeline deploys the service and tells the orchestrator (Kubernetes, ECS, etc.) which service account to use. The service itself retrieves its own secrets at startup. The pipeline never sees the production secrets. This is the best option when it is architecturally feasible.

What OWASP underemphasizes

Exfiltration risk. An attacker (or a careless developer) who can modify a pipeline definition can add a step that echoes secrets to a remote endpoint, encodes them in base64, or writes them to a file that is uploaded as a build artifact. Detection requires:

• Monitoring pipeline definitions for changes

• Reviewing pipeline output for encoded content

• Alerting on unusual network egress from CI/CD runners

Supply chain attacks on GitHub Actions. A compromised third-party action can access all secrets available to the workflow. Pinning actions to specific commit SHAs (not tags) and auditing third-party actions before use are critical practices that fall outside OWASP's current scope. GitHub's security hardening guide for Actions covers this in more detail.

Keep secrets out of the pipeline entirely

Prefer option three (service retrieves its own secrets) wherever possible. For GitHub Actions, use OIDC federation to authenticate to your secrets management platform at runtime rather than storing long-lived credentials as GitHub secrets.

Require merge request approval for any changes to pipeline definitions. Monitor pipeline output for secret leakage. Treat your CI/CD infrastructure with the same patching, hardening, and monitoring discipline you apply to production.

Kubernetes Secrets: The Default Is Not Good Enough

The OWASP guidance on containers and orchestrators is where things get most operationally relevant for teams running Kubernetes.

The default Kubernetes Secrets problem

Kubernetes Secrets are base64-encoded, not encrypted. By default, anyone with the right RBAC permissions can read every secret in a namespace. Environment variables exposed via Kubernetes are visible through kubectl describe pod and are captured by most logging agents. The etcd datastore, where secrets are stored, may or may not have encryption at rest enabled depending on the cluster configuration.

The OWASP cheat sheet recommends:

• Inject secrets via mounted volumes or sidecar containers, not environment variables

• Never bake secrets into container images

• Ensure encryption at rest for the etcd backend

• Restrict access to within the pod, not shared across deployments

All of these are correct. None of them are the default behavior of a vanilla Kubernetes cluster. The OWASP Kubernetes Security Cheat Sheet provides additional context.

The sidecar pattern

OWASP recommends the sidecar pattern for secret injection: a sidecar container authenticates to the secrets management system, retrieves the required secrets, and writes them to a shared in-memory volume (emptyDir with medium: Memory). The application reads from the volume. The sidecar can periodically refresh the secrets, supporting rotation without redeployment.

This pattern works well, but it adds operational complexity. Each pod now has an additional container that needs to be configured, monitored, and updated. For teams managing hundreds of services, a Kubernetes operator that handles secret syncing at the cluster level (rather than per-pod sidecars) is often a better fit.

The Infisical Kubernetes Operator takes this approach by syncing secrets from Infisical into Kubernetes clusters with automatic refresh when secrets are rotated upstream. This removes the need for per-pod sidecar configuration while still keeping secrets out of environment variables and container images.

The GitOps tension OWASP misses

The cheat sheet does not address the tension between GitOps and secrets management. Teams using ArgoCD or Flux to manage cluster state face a real problem: the desired state (including secret references) lives in Git, but the actual secret values should not live in Git.

Solutions like Sealed Secrets or External Secrets Operator exist to bridge this gap, but they add another layer of tooling. A secrets management platform with a native Kubernetes operator can reduce this complexity by handling the sync between the external secrets store and the cluster without requiring the secret values to pass through Git.

Multi-Cloud: The Reality That Makes Everything Harder

The OWASP multi-cloud guidance covers the expected challenges (diverse APIs, inconsistent policies, fragmented auditing) and recommends a centralized, cloud-agnostic solution.

Where the OWASP guidance is practical

The recommendation to use a centralized solution that integrates with multiple cloud providers is correct. It is also the only viable approach for organizations that run workloads across AWS, GCP, Azure, and on-prem.

Using each cloud provider's native secrets management in isolation creates three (or more) separate systems with different access control models, different rotation mechanisms, and different audit log formats.

What OWASP does not cover

Non-human identity sprawl. Machine identities (service accounts, workload identities, API tokens, certificates) now outnumber human identities in most large organizations by a factor of 10x or more. Each cloud provider has its own model for machine identity (IAM roles, service accounts, managed identities), and these do not translate across providers. A secrets management platform that also handles certificate lifecycle management and privileged access across cloud boundaries addresses this gap.

Shrinking TLS certificate lifetimes. When certificate lifetimes drop to 47 days (the current trajectory for public TLS certificates by 2029), manual certificate management becomes operationally impossible for any organization with more than a handful of certificates. Automated certificate issuance, renewal, and revocation need to be part of the secrets management strategy, not a separate discipline managed by a different team with different tools.

OWASP Secrets Management Checklist

Use this to evaluate your current posture. If you cannot check a box, that is your prioritization list.

Centralization and Standards

☐ All secrets are stored in a designated secrets management system, not in code, config files, or spreadsheets

☐ Every secret has a documented owner, purpose, and list of consumers

☐ Interaction patterns with the secrets management system are consistent across teams

☐ Root/admin credentials for the secrets management system are stored in a separate, secure location

Access Control

☐ Permissions are configured at the secret or project level, not system-wide

☐ Least privilege is enforced for every user and service

☐ Access reviews are automated and tied to the identity provider

☐ Offboarding revokes secrets management access within minutes

Rotation and Lifecycle

☐ Machine secrets are rotated on a defined, automated schedule

☐ Dynamic secrets are used for database credentials and other supported backends

☐ Rotation procedures are tested regularly in staging

☐ Expired and revoked secrets are monitored for attempted reuse

☐ Every secret has a defined expiration or rotation cadence

CI/CD Pipeline Security

☐ CI/CD infrastructure is hardened and treated as a production system

☐ Pipeline secrets are scoped per job, not per repository or organization

☐ Pipeline output is monitored for secret leakage

☐ Fork/copy operations do not propagate secrets

☐ Deployed services retrieve their own secrets at runtime where possible

☐ Third-party actions/plugins are pinned to specific commit SHAs

Kubernetes and Container Security

☐ Encryption at rest is enabled for etcd

☐ Secrets are injected via mounted volumes or operators, not environment variables

☐ No secrets are baked into container images or Docker ENV/ARG instructions

☐ RBAC restricts secret access to specific service accounts and namespaces

☐ An external secrets management platform is the source of truth, not native Kubernetes Secrets

Encryption

☐ All secrets are encrypted at rest (AES-256 GCM or equivalent)

☐ All secrets are transmitted over TLS

☐ Encryption keys are stored separately from the secrets they protect

☐ Backups are encrypted with separately managed keys

☐ Terraform state backends use encryption

Detection and Monitoring

☐ Pre-commit hooks scan for secrets before code is pushed

☐ CI/CD pipelines include secrets scanning as a blocking gate

☐ Repository scanning covers full Git history, not just HEAD

☐ Audit logs capture all secret access, creation, rotation, and deletion events

☐ Alerts are configured for anomalous secret access patterns

☐ Audit logs are retained for at least 90 days queryable, longer in cold storage

Incident Response

☐ Break-glass credentials exist, are stored separately, and are tested quarterly

☐ Documented incident response procedures exist for secret exposure

☐ Revocation can be completed within minutes

☐ A secret exposure incident has been tabletop-exercised in the past 12 months

Multi-Cloud and Hybrid

☐ A unified secrets management approach spans all cloud providers and on-prem

☐ Access controls, rotation cadences, and policies are consistent across environments

☐ Audit trails aggregate events from all environments into a single queryable system

☐ Machine identity (certificates, service account tokens) is managed alongside secrets

Start Closing the Gaps

The 2am certificate outage and the blocked Terraform deploy from the top of this article have the same root cause: secrets managed as individual decisions across disconnected tools, with no unified lifecycle. The OWASP cheat sheet defines what good looks like.

Infisical is an open-source platform that centralizes secrets, certificates, and privileged access management with out-of-the-box integrations for Kubernetes, Terraform, GitHub Actions, and 60+ other tools. It handles the operational pieces the OWASP cheat sheet describes: centralized storage, automated rotation, fine-grained access control, and audit logging across cloud, on-prem, and hybrid environments.

If your current setup relies on manual runbooks, scattered environment variables, or a spreadsheet someone made three years ago, you can try Infisical for free. Or book a walkthrough if you want to talk through your specific setup.