Bitbucket secrets management still depends on access scope

At a glance

What this is: A practical guide to Bitbucket secrets management that shows where native variables, OIDC, and external secret providers fit, and where the control model still falls short.

Why it matters: It matters because IAM, PAM, and DevSecOps teams must govern CI/CD secrets as identities with scope, lifecycle, and exfiltration risk, not as simple configuration values.

By the numbers:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Infisical's guide to Bitbucket secrets management and OIDC

Context

Bitbucket secrets management is not just about storing values in a pipeline. It is about controlling who can inject, read, inherit, and exfiltrate credentials across repository, workspace, and deployment scopes, especially where CI/CD steps need cloud access or third-party vault integration.

The governance gap appears when teams treat secured variables as equivalent to governed identities. Masking in logs, encrypted storage, and UI restrictions reduce exposure, but they do not replace lifecycle control, offboarding discipline, or runtime access boundaries for pipeline identities and write-capable users.

Key questions

Q: How should security teams reduce long-lived secrets in Bitbucket pipelines?

A: 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.

Q: Why do Bitbucket pipeline secrets still create risk even when they are masked?

A: Masking reduces casual exposure in logs, but it does not stop a user with write access from changing pipeline YAML to exfiltrate a secret. It also does not remove the risk of artifact leakage, reused scope, or forgotten credentials that remain valid long after they should have been retired.

Q: What do teams get wrong about using repository and workspace variables?

A: They often treat scope as a substitute for governance. Repository and workspace variables help organise secrets, but they do not enforce lifecycle control, offboarding, or least privilege by themselves. If the same value is copied across many pipelines, the blast radius is still shared.

Q: Who should be accountable for pipeline secrets that come from a central vault?

A: Accountability should be shared across the pipeline owner, the vault owner, and the identity team because the access path crosses all three domains. The runtime injection step, the trust policy, and the pipeline permissions each control a different part of the exposure chain.

Technical breakdown

Bitbucket variable scopes and precedence

Bitbucket resolves secrets through multiple scopes, including pipeline run-level, deployment, repository, workspace, and default variables. That precedence matters because the same variable name can resolve differently depending on where the pipeline executes, which creates an identity and entitlement problem, not just a configuration one. Repository and workspace variables are convenient, but they also broaden the number of people and systems that can indirectly influence secret use. For teams running multiple services or environments, the operational risk is drift between intended scope and actual runtime exposure.

Practical implication: define which secret belongs at which scope and review whether the current precedence order is expanding blast radius.

OIDC keyless authentication for pipelines

OpenID Connect replaces stored cloud credentials with short-lived identity tokens issued for each pipeline step. Bitbucket creates the token, the cloud provider validates it through the trust relationship, and temporary credentials are issued with scoped permissions. This shifts the control model from secret storage to federated identity and claim-based trust. The security gain comes from eliminating long-lived access keys in Bitbucket, but the trust boundary moves to the role, subject, audience, and claims policy in the destination cloud account.

Practical implication: require OIDC for cloud access in pipelines and audit the trust policy that accepts the Bitbucket-issued token.

Third-party secret providers and runtime injection

Bitbucket’s third-party secret provider model lets a pipeline fetch secrets from an external vault at runtime instead of storing them in Bitbucket. The step presents an OIDC token, the provider validates it, and only then does it return secrets to the job environment. This is a better fit for centralised vault governance, but it also introduces middleware, claim validation, and provider-side access policy as new control points. The pipeline still becomes a high-value delivery path, so write access and execution permissions remain central to the risk model.

Practical implication: treat the vault, middleware, and pipeline step as one governed access path and review each control boundary separately.

Threat narrative

Attacker objective: The attacker wants to turn pipeline visibility or write access into reusable credential exposure that can be leveraged outside the intended Bitbucket boundary.

1. entry via repository write access or insecure pipeline design that allows a user to alter the Bitbucket pipeline definition or secret handling flow.
2. credential_harvested through secured variable exposure, log leakage, artifact handling, or delegated access to scoped secrets.
3. escalation occurs when the same secret is reused across repository, workspace, or deployment scopes, increasing reach beyond the intended environment.
4. impact is credential exfiltration or cloud access abuse, including unauthorized access to downstream services or environments.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Bitbucket secrets management is really a delegated identity problem. The article frames secrets as values, but the security issue is who can cause those values to be resolved, inherited, or reused at runtime. Once write access to a repository can alter pipeline behaviour, a secured variable is no longer just stored data, it is an access path. The implication is that PAM and CI/CD governance must be designed together, not separately.

Static pipeline secrets create a standing privilege window that outlives the job that needs them. Repository, workspace, and deployment variables make administration easier, but they also preserve long-lived access paths that are hard to lifecycle-manage at scale. That aligns directly with OWASP Non-Human Identity Top 10 concerns around secret sprawl and overexposure. Practitioners should read this as evidence that scope is not the same as control.

Keyless authentication is now the baseline for cloud-bound pipelines, not an advanced option. OIDC shifts Bitbucket from storing credentials to brokering short-lived identity assertions, which better fits zero-trust access patterns for non-human identities. The most important change is not technical convenience, but reduced dependence on manually rotated secrets. Teams that still default to stored cloud keys are carrying avoidable blast radius into every deployment.

Secret sprawl is the hidden cost of convenience in CI/CD governance. When every repository, workspace, and deployment can hold its own secret, governance fragmentation becomes the default operating state. That is why a central vault and runtime retrieval model matters more than another local storage tier. The practitioner conclusion is simple: if your secret strategy depends on remembering where every copy lives, it will eventually fail.

Access reviews do not solve pipeline exfiltration when the reviewer cannot see runtime pathing. A secured variable can be masked, yet still be reachable through modified YAML, artifacts, or overly broad write permissions. That is a governance failure, not a logging failure. The implication is that review processes must cover execution rights, not just secret inventories.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to The State of Secrets Sprawl 2026.
• If you are expanding CI/CD secret handling into AI-connected tooling, review Guide to the Secret Sprawl Challenge for the lifecycle and exposure controls that pipeline masking does not replace.

What this signals

Secret handling in pipelines is converging with broader identity governance. Once CI/CD jobs can fetch secrets at runtime, the security question becomes who can authorise that fetch, who can change the trust policy, and who can still exfiltrate from the execution path. That is why pipeline identity needs the same lifecycle discipline as service accounts and other non-human identities. The OWASP Non-Human Identity Top 10 is a useful reference point for that control model.

Secret sprawl is now a governance metric, not just a hygiene issue. The fact that 24,008 unique secrets appeared in MCP configuration files in 2025 shows how quickly new runtime interfaces can become credential distribution points. If your Bitbucket programme expands into more tool-to-tool automation, you need to assume the same drift can happen there. The control target is not storage alone, it is exposure paths across the delivery chain.

Static-versus-dynamic secrets is the key concept teams should sharpen now. Static values embedded in pipeline storage create standing exposure, while dynamic retrieval narrows the window and improves attribution. That distinction should shape how teams size their vault investment and how they design deployment permissions. For a deeper control model, align the discussion with OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0.

For practitioners

• Move cloud authentication to OIDC by default Replace stored cloud provider keys in Bitbucket pipelines with short-lived OIDC trust wherever the target service supports it. Review the role trust policy, subject restrictions, and audience claims before allowing production deployments.
• Separate secret scope by operational need Keep repository variables for repo-specific configuration, workspace variables for shared values, and deployment variables for environment-bound credentials. Reassess whether shared variables are creating accidental cross-repository access.
• Restrict write access around sensitive pipelines Treat write permission on any repository that can exfiltrate secured variables as privileged access. Combine branch protections, deployment permissions, and pipeline approval controls so a contributor cannot turn YAML changes into credential export.
• Adopt third-party secret retrieval for central vaults If your organisation already uses a central secrets vault, pull credentials at runtime instead of duplicating them into Bitbucket storage. Validate the middleware, token validation path, and environment scoping before production use.
• Map pipeline secrets into your identity lifecycle Assign owners, review cadences, and offboarding triggers to every pipeline credential path, including tokens used by CI/CD jobs and external providers. Secrets that are never lifecycle-managed become permanent standing access.

Key takeaways

• Bitbucket secrets management is a control problem, not just a storage problem, because write access and pipeline behaviour can still expose secured values.
• OIDC and runtime vault retrieval materially reduce standing credential exposure, but they shift governance to trust policy, scope, and execution permissions.
• Teams that lifecycle-manage CI/CD credentials like non-human identities will reduce blast radius more effectively than teams that rely on masking alone.

Key terms

• Bitbucket Pipeline Variable: A Bitbucket pipeline variable is a named value injected into a build or deployment step as an environment variable. In practice, it is a credential delivery mechanism, so its scope, overwrite rules, and visibility controls determine how widely a secret can be reused or exposed.
• OpenID Connect For Pipelines: OpenID Connect for pipelines is a keyless authentication pattern that lets a CI/CD job present a short-lived token instead of a stored credential. The cloud or vault side validates the token claims, then issues temporary access with narrower scope and less standing exposure.
• Third-Party Secret Provider: A third-party secret provider is an external vault or middleware service that returns secrets to a pipeline at runtime after validating the job's identity. It reduces duplication inside the CI/CD platform, but it adds trust in the validation path, the provider policy, and the execution environment.
• Standing Privilege: Standing privilege is access that remains continuously available until someone removes it. In CI/CD, this often appears as long-lived keys or broadly scoped variables that can be used across many runs, which creates a larger blast radius than ephemeral, task-scoped access.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Bitbucket variable setup across repository, workspace, and deployment scopes for teams that need implementation guidance.
• Full OIDC configuration examples for AWS, GCP, Azure, and HashiCorp Vault, including the claim and trust policy details.
• Third-party secret provider setup flow, including the middleware pattern and runner configuration needed for runtime retrieval.
• Migration notes for Bitbucket app passwords to API tokens before the June 9, 2026 cutoff.

👉 Infisical's full guide covers deployment variables, third-party secret providers, and API token migration details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.