Notifications
Clear all
Topic starter
08/07/2026 6:52 pm
TL;DR: The OWASP Secrets Management Cheat Sheet argues that the real problem is not isolated secret handling but fragmented lifecycle control across CI/CD, cloud, containers, and multi-cloud environments, according to Infisical. Manual rotation, weak access granularity, and inconsistent auditability turn secrets management into an operational reliability issue, not just a security checklist.
NHIMG editorial — based on content published by Infisical: OWASP Secrets Management Cheat Sheet
Questions worth separating out
Q: How should security teams reduce secrets sprawl across cloud and CI/CD environments?
A: Start by standardising how secrets are created, stored, rotated, revoked, and audited, even if multiple backends remain in use.
Q: Why do manual secret rotations keep failing in production?
A: Manual rotation fails because downstream dependencies are easy to miss and hard to update consistently.
Q: What do teams get wrong about access control for secrets?
A: They often grant broad vault-level access and assume that is enough.
Practitioner guidance
- Inventory secret consumers, not just secret stores. Build a live register of every application, pipeline, cluster, and operator that can read each secret, then tie ownership to the team that can revoke or rotate it without delay.
- Eliminate manual rotation for production credentials. Where a secret cannot be replaced with a dynamic credential, automate its rotation and test downstream dependencies in staging before changing production cadence.
- Move pipeline secret retrieval to runtime. Prefer service-side secret retrieval over embedding credentials in CI/CD variables, and restrict pipeline access to the minimum scope needed for the specific job.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- The full OWASP section-by-section breakdown for CI/CD, containers, cloud, encryption, detection, and incident response
- Concrete checklist items for encryption at rest, audit logging, and multi-cloud policy consistency
- Implementation detail on how the guidance maps to Terraform state, Kubernetes secrets, and pipeline hardening
- Practical examples of when dynamic secrets are feasible and when static credentials still need tighter rotation controls
👉 Read Infisical's OWASP Secrets Management Cheat Sheet analysis →
Secrets management in production systems: what teams miss?
Explore further
08/07/2026 7:13 pm
Secrets management is really lifecycle governance, not storage selection. The article is strongest when it treats secrets as objects that must be created, consumed, rotated, audited, and revoked across multiple environments. That is the discipline IAM teams already apply to human access reviews, but many infrastructure teams still do not apply it to machine credentials. The implication is that secrets programmes fail when they are designed as repositories instead of governed lifecycles.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who should be accountable when a secret exposure blocks production?
A: Accountability should sit with the team that owns the secret’s lifecycle, not only with the security function. That team must know where the secret is used, how it is rotated, how fast it can be revoked, and which systems will fail when it changes. If no owner can answer those questions, the control is incomplete.
👉 Read our full editorial: OWASP secrets management cheat sheet for production systems
