Notifications
Clear all
Topic starter
08/07/2026 7:09 pm
TL;DR: CI/CD pipelines need secrets for testing, deployment, and infrastructure updates, but platform-native storage centralises exposure and limits rotation, auditability, and access control, according to Infisical's guide. The governance problem is not automation itself but the assumption that pipeline credentials can stay static, broad, and reviewable without increasing blast radius.
NHIMG editorial — based on content published by Infisical: How to manage secrets in CI/CD pipelines?
By the numbers:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
Questions worth separating out
Q: How should security teams manage secrets in CI/CD pipelines?
A: Use separate identities for build, deploy, and runtime tasks, then store privileged credentials outside the pipeline in a secrets manager.
Q: Why do CI/CD secrets create so much blast radius when they are exposed?
A: CI/CD secrets often sit close to cloud permissions, registries, and deployment systems, so one leaked credential can unlock multiple downstream resources.
Q: What do security teams get wrong about secrets rotation in pipelines?
A: They often assume rotation alone solves the problem.
Practitioner guidance
- Separate build, deploy, and runtime identities Issue different credentials for CI testing, CD deployment, and application runtime access.
- Move privileged secrets out of the CI/CD platform Store sensitive credentials in an external secrets manager and retrieve them at runtime with short-lived authentication.
- Enforce automatic rotation and expiry Set rotation and expiration policies so secrets do not outlive the workflow that uses them.
What's in the full article
Infisical's full blog post covers the operational detail this post intentionally leaves for the source:
- Platform-native versus external secrets manager setup steps for real CI/CD environments
- Trade-offs between environment variables, federated identity, and runtime retrieval patterns
- Practical guidance on rotation, auditing, and compliance-ready secrets lifecycle controls
- Implementation detail for integrating secrets handling into common pipeline tools
👉 Read Infisical's guide on managing secrets in CI/CD pipelines →
CI/CD pipeline secrets management: are your controls keeping up?
Explore further
08/07/2026 7:33 pm
CI/CD secrets are machine identities, not deployment convenience items. Once a pipeline credential can reach test systems, cloud services, or registries, it becomes an identity object with lifecycle, audit, and offboarding requirements. Treating it as a temporary configuration value is how organisations miss the control failure that turns automation into access.
A few things that frame the scale:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
A question worth separating out:
Q: Who is accountable when a CI/CD secret leak affects production systems?
A: Accountability usually sits with the teams that own the pipeline, the secrets lifecycle, and the downstream systems that trust those credentials. A mature programme maps each credential to an owner, a purpose, and a revocation path so leaks can be traced and contained before they become a production incident.
👉 Read our full editorial: CI/CD pipeline secrets management: balancing speed and exposure
