Notifications
Clear all
Topic starter
08/07/2026 6:51 pm
TL;DR: Bitbucket’s secrets model spans repository, workspace, and deployment scopes, while OIDC and third-party secret providers reduce long-lived credential exposure in CI/CD, according to Infisical. The real governance issue is that masking is not lifecycle control, and write access can still turn secured variables into an exfiltration path.
NHIMG editorial — based on content published by Infisical: Bitbucket Secrets Management: A Complete Guide
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.
Questions worth separating out
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.
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.
Q: What do teams get wrong about using repository and workspace variables?
A: They often treat scope as a substitute for governance.
Practitioner guidance
- 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.
- 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.
- Restrict write access around sensitive pipelines Treat write permission on any repository that can exfiltrate secured variables as privileged 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.
👉 Read Infisical's guide to Bitbucket secrets management and OIDC →
Bitbucket secrets management in pipelines: are your controls keeping up?
Explore further
08/07/2026 7:12 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Bitbucket secrets management still depends on access scope
