Bitbucket
Proofroom reads one Bitbucket Cloud workspace and files three kinds of evidence. Add it on Integrations → Catalogue → Bitbucket → Connect.
What each collector shows
| Collector | Kind | Default cadence | What it shows | Suggested controls |
|---|---|---|---|---|
| Reviewed merges | window | monthly | Pull requests merged in the window, per repository, with the author, who merged and who approved. The merge time comes from each pull request’s activity log. Flags No approval and Self-approved; people are told apart by their Atlassian account, not their display name. | PCI DSS 6.2.3, 6.5.1; SOC 2 CC8.1 |
| Branch protection | snapshot | quarterly | Each repository’s main branch: the branch restrictions that apply, who can push, whether force pushes are allowed and the approvals required. Restrictions on a branch type of the branching model (such as development or production) are resolved to the branch names through the repository’s branching model. Approvals count as required only with the enforce merge checks restriction (Premium); without it they are noted as requested but not enforced. The note also lists who may merge, blocked deletion, approvals reset on new commits and the other merge checks (passing builds, tasks, resolved comments and so on). | PCI DSS 6.2.3; SOC 2 CC8.1 |
| Members and 2FA | snapshot | quarterly | Every workspace member, owners marked, with whether two-step verification is on. | PCI DSS 8.3.1; SOC 2 CC6.1 |
Reviewed merges is automatic only.
Credentials
An API token (id.atlassian.com → Security → API tokens → Create API token with scopes) for a dedicated account, with:
read:repository:bitbucketandread:pullrequest:bitbucket: repositories and pull requests.read:workspace:bitbucket: workspace members and owners.admin:repository:bitbucket, and the account must be a repository admin: Bitbucket has no read-only scope for branch restrictions. Proofroom only reads them.
Or a workspace access token (Premium workspaces) with the same permissions; leave the email blank. A workspace access token cannot read workspace permissions, so owners are not marked; the evidence says so.
Two-step verification comes from the Atlassian organization admin API: an organization admin creates an API key
(Atlassian Administration → Settings → API keys) with read:directories:admin. Members whose accounts your
organization does not manage show two-step verification as unknown.
Connect
| Field | Value |
|---|---|
| Workspace | The workspace ID |
| Your Atlassian account email with an API token; blank with a workspace access token | |
| API token | From above |
| Repositories | Slugs, one per line; empty means every repository |
| Organization ID, admin API key | For Members and 2FA |
Known limits
- A pull request’s merge time is read from its activity log (two calls per merged pull request). A merged pull request whose activity log has no merge fails the run rather than be placed in a guessed window.
- API tokens expire after at most a year.