Use OIDC for cloud authentication wherever possible, because it replaces stored access keys with short-lived identity tokens issued per pipeline step. For anything that still needs storage, keep the secret in the narrowest possible scope and pair it with explicit environment permissions and reviewable ownership.
Why This Matters for Security Teams
Bitbucket pipelines are attractive because they centralise build logic, but they also concentrate trust. If a pipeline still depends on long-lived access keys, the blast radius is no longer limited to a single developer laptop or admin console. It extends into every build step, every branch that can trigger automation, and every place a secret may be copied, cached, or logged. That is why NHI Management Group treats pipeline secrets as a lifecycle problem, not a storage problem.
The practical issue is exposure, not just possession. Static secrets tend to survive past their intended scope, while modern CI/CD environments are designed to move quickly across repositories, environments, and integrations. NHIMG research on the Guide to the Secret Sprawl Challenge shows how duplication and fragmented ownership make this worse. The OWASP Non-Human Identity Top 10 also highlights why credentials used by software systems need tighter lifecycle controls than human accounts.
One relevant NHIMG data point from The State of Secrets in AppSec is that the average estimated time to remediate a leaked secret is 27 days, which is far too long for pipeline-issued credentials that may have already been replayed. In practice, many security teams discover secret sprawl only after a build credential has already been reused outside its intended pipeline path, rather than through deliberate lifecycle design.
How It Works in Practice
The strongest pattern is to replace stored cloud keys with OIDC-based federation wherever the target platform supports it. In Bitbucket pipelines, that means the pipeline step proves its identity at runtime and receives a short-lived token instead of retrieving a reusable secret from a vault or variable store. This aligns with the broader move toward dynamic NHI controls described in NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets.
Operationally, teams should treat each pipeline step as a distinct trust event. Use tightly scoped identities, separate credentials by environment, and bind permissions to explicit deploy targets rather than to a repository-wide token. Short TTLs matter here because the credential is meant to die with the step, not outlive the job. Where storage cannot yet be removed, keep the secret in the narrowest possible scope, avoid reusable shared variables, and ensure ownership is tied to a named environment or service account. The CI/CD pipeline exploitation case study is a useful reminder that compromise often spreads through automation boundaries that were assumed to be “internal.”
- Prefer federation over static cloud access keys.
- Issue credentials per pipeline step or per deployment action.
- Separate dev, test, and production permissions.
- Log token issuance and revocation events for auditability.
- Review which steps can access any remaining stored secrets.
For implementation guidance, the most useful control model is a policy that evaluates the requested action at runtime, rather than a broad rule that grants blanket access to the whole pipeline. These controls tend to break down when legacy build jobs require persistent credentials for multiple external systems because the job design itself still assumes long-lived identity.
Common Variations and Edge Cases
Tighter secret controls often increase pipeline complexity, so organisations have to balance reduced exposure against build friction and integration overhead. That tradeoff is real, especially when release automation touches older SaaS tools, self-hosted runners, or third-party deployment targets that do not support OIDC well.
Best practice is evolving for these cases. If an external service cannot accept federated identity, use a vault-backed secret with the shortest practical TTL, narrow environment permissions, and explicit reviewable ownership. If the secret must persist longer than a single run, rotate it on a schedule that matches the actual business need, not the convenience of the pipeline. The Reviewdog GitHub Action supply chain attack is a good example of why automation trust should be minimal even when the tool seems routine.
Teams should also watch for accidental secret reuse across branches, shared runners, and forked pull requests. If a pipeline requires broad write permissions to function, the design likely still depends on a standing privilege pattern rather than a just-in-time model. Current guidance suggests treating any credential that can be copied into multiple jobs as a candidate for removal, replacement, or strict segmentation. In mixed environments, the guidance fails when security teams modernise one pipeline stage but leave the downstream deploy step with a static release key that never expires.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Top 10 | Covers unsafe machine identities and secret exposure in automated pipelines. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses lifecycle control for non-human credentials used in CI/CD. |
| NIST AI RMF | GOVERN | Requires accountability and oversight for automated identity use in pipeline workflows. |
Replace long-lived pipeline keys with short-lived identities and rotate any remaining secrets aggressively.
