Bitbucket sits at the center of the software supply chain for tens of thousands of engineering teams, which makes it a high-value target the moment a repository, pipeline, or access token is misconfigured. In August 2022, Atlassian disclosed CVE-2022-36804, a command injection flaw in Bitbucket Server and Data Center with a CVSS score of 9.9 that let anyone with read access to a repository execute arbitrary code on the server. That single bug affected every self-hosted Bitbucket instance running versions before 7.6.17, and CISA added it to its Known Exploited Vulnerabilities catalog within weeks of disclosure. Whether your team runs Bitbucket Cloud or Bitbucket Data Center, the same handful of settings — branch permissions, pipeline secrets, OAuth scopes, and access controls — determine whether one compromised laptop turns into a full supply chain breach. Here is a concrete, no-fluff cheat sheet for locking it down.
What made CVE-2022-36804 a wake-up call for Bitbucket security?
CVE-2022-36804 mattered because it turned ordinary repository read access into full remote code execution on the server hosting the code. The flaw lived in multiple API endpoints that passed user-controlled input — including branch names — into internal git commands without sanitizing it, so an attacker with access to a public repository, or read access to a private one, could inject shell commands. Atlassian patched it in versions 7.6.18, 7.17.10, 7.20.5, and 7.21.0, but scanners were probing internet-facing Bitbucket Data Center instances for the flaw within days of the advisory going public on August 24, 2022. The practical lesson: treat any CVSS 9.0+ advisory from Atlassian as a 48-hour patch SLA, not a "next sprint" ticket. If you run Bitbucket Data Center, subscribe to Atlassian's security advisory feed directly, and if the instance doesn't need to be internet-reachable, put it behind a VPN or IP allowlist so unauthenticated network exposure isn't doing half the attacker's work for them.
How do you lock down branch permissions and merge checks in Bitbucket?
You lock down branches by requiring a minimum of two reviewer approvals, a passing build, and zero unresolved "changes requested" comments before anything merges into main or a release branch. Bitbucket's merge checks let you enforce all three natively, and branch permissions let you restrict who can push directly, force-push, or delete a protected branch — that restriction should be limited to a small admin group, not "everyone with write access." Pair this with a CODEOWNERS file so changes to /infra, /auth, or CI config always route to the people who actually own that surface. Concretely: disable force-push on main and every release/* branch, require at least one approval from a listed code owner (not just any teammate), and turn on "reset approvals on new commits" so a reviewer's sign-off doesn't silently cover code they never actually saw.
Which Bitbucket Pipelines mistakes leak secrets and credentials?
The single most common Pipelines mistake is storing API keys and cloud credentials as a plain repository variable instead of marking them "Secured," which means they print unmasked in build logs the first time a script echoes an environment variable during debugging. Bitbucket Pipelines gives you Secured variables (encrypted at rest, masked in logs) and Deployment environment variables that can be scoped per environment — staging keys should never be readable from a pipeline targeting production, and vice versa. Add a required approver gate on the production deployment environment so a merged PR can't auto-deploy without a second set of eyes. Two more concrete fixes: since Bitbucket added OpenID Connect support for AWS and GCP in 2023, replace long-lived cloud access keys in pipeline variables with short-lived OIDC tokens wherever your cloud provider supports it, and rotate any credential that was ever pasted into a pipeline variable before Secured status existed on that repo — you can't retroactively mask what already leaked into historical log output.
How should teams manage OAuth apps, API tokens, and SSH keys in Bitbucket?
Treat every OAuth app connected to a Bitbucket workspace, and every SSH key on a developer account, as a credential with an expiration date, because workspaces accumulate stale third-party integrations and forgotten keys far faster than they get cleaned up. Atlassian began retiring Bitbucket app passwords in 2024 in favor of scoped API tokens, which is worth acting on immediately: app passwords typically grant broad, workspace-wide access, while scoped tokens can be limited to exactly the repositories and permissions a given integration needs. Audit the "Installed apps" and "OAuth consumers" lists under workspace settings quarterly and revoke anything not tied to an active, named use case. For SSH keys, set an expiration on every key at creation time, and treat any key that hasn't authenticated in 90 days as a candidate for immediate revocation — a former contractor's still-valid SSH key is one of the cheapest ways for an attacker to clone your entire codebase without tripping a single alert.
What access-control settings catch account takeover before it spreads?
Enforce two-factor authentication workspace-wide and, on Bitbucket Cloud Premium, an IP allowlist restricted to your corporate VPN or office ranges, because a stolen password without a second factor remains the most common entry point into source code repositories. Pair mandatory 2FA (or SSO with SAML and a short session timeout, such as 8 hours) with active audit log monitoring — Bitbucket Cloud Premium retains audit logs for 12 months, and that history should feed a SIEM rule that fires on new SSH key additions, new OAuth grants, or workspace permission changes outside business hours. On Bitbucket Data Center, enable the same alerting through the audit log REST API rather than relying on someone remembering to check the admin console. The goal is detection speed: an attacker who takes over one developer's session should be caught adding a persistence mechanism — a new key, a new app, a new admin — within minutes, not discovered three weeks later during a routine review.
How Safeguard Helps
Safeguard connects directly to Bitbucket Cloud and Data Center to continuously assess the exact issues in this cheat sheet — branch permission drift, unsecured pipeline variables, stale OAuth grants, and unpatched CVEs like CVE-2022-36804 — without requiring a separate scanning agent per repo. Reachability analysis then cuts the noise on top of that: instead of flagging every vulnerable dependency a Bitbucket pipeline pulls in, Safeguard traces whether the vulnerable function is actually called from your code path, so security teams triage the handful of findings that matter instead of hundreds that don't. Griffin AI, Safeguard's autonomous remediation engine, opens auto-fix pull requests directly against the affected Bitbucket branch — respecting your existing merge checks and required reviewers — so a fix ships through the same review gates as any other change. Safeguard also generates and ingests SBOMs at every pipeline run, giving you a continuously current inventory of what's actually running in production rather than a point-in-time snapshot from your last audit.