Collaboration is an essential element when developing any type of new security methodology. It’s also essential when developers are working on code. Sharing code allows developers to be efficient but sharing code with your team and any external resources shouldn’t mean the entire organization’s code can easily be exposed.
Any collaboration platform like Bitbucket, Github, or Gitlab are essential for collaboration with one or several being used by most developers in any given organization. But without proper security measures in place, even the best ways to share can become weapons for hackers. While Atlassian has put some security measures in place to help organizations limit access to code not everyone knows which to use, or how to implement them.
We’ll go through a step by step review of Bitbucket’s security settings so your team can quickly secure your org’s Bitbucket and protect your source code.
Securing Bitbucket Access & Authentication
If you haven’t already, the most basic option (that should be a de facto policy in every company!), is to require that all teams, employees and contractors use 2-step verification (enforcing 2-step verification is a Bitbucket premium option).
Enable two-step verification in your personal account
Enforce 2-step verification in your workspace
The ability to enforce 2-step verification is a function that is available for Bitbucket Premium subscribers but is highly recommended.
SSO (Atlassian access users)
SAML single sign-on for your Bitbucket (and other Atlassian products) is available using Atlassian Access.
Limit access to specific IP addresses
With IP whitelisting enabled, users will only be able to interact (view, push, clone, etc.) with your account’s private content if they are accessing Bitbucket from an IP address you have selected and know is safe.
Groups default repository access
Groups in Bitbucket have a default repository access, which means that for every new repository you create, the group will automatically get the default access you set when it was created. The most secure option is to have that setting set to None. Note that your users may lose access to certain repositories and regaining access with require a manual adjustment.
View current access permissions of a repository
It is important to build the practice of reviewing repository access periodically to discover redundant access of users – consider it seasonal cleaning.
Repository forking & access level
Forking is the act of creating a copy of the repository. Forking is meant to allow developers to create a copy of code they can experiment on without affecting the original repository.
From a security perspective, there are two main issues with forking. The first is that the more forks there are for a repository, the harder it is to keep track of the security of each fork, and the problem of securing the repository grows exponentially the more forks a repository has. The second is that forking can easily be used to create a copy of a repository in a user’s private account.
The repository visibility level will determine whether the repository is accessible to the outside world. It is recommended to periodically review this setting, and when creating a new repository always set the value to false and change it prior to releasing repositories as open source.
Disable public repositories (Bitbucket server only)
If you have no need for public repositories, disable public repositories across the organization by changing the ‘feature.public.access’ system property.
Enable merge checks (Bitbucket premium only)
Bitbucket premium comes with built-in controls meant to enforce tempering protection through workflow definitions. The most basic of them is requiring approval before merging code to the production branch.
This ensures that a developer cannot push code that hasn’t been reviewed by another developer to the production environment. Checks and balances.
Sign commits and tags with GPG keys (Bitbucket server only)
GPG is a command-line tool used together with Git to encrypt and sign commits or tags to verify contributions in Bitbucket Server.
Review your workspace audit logs
Periodically review the audit log and make sure that there are no anomalous or suspicious activities. Under the workspace settings, you can access the audit log and view various events that happened in your Bitbucket workspace.
Inspect installed apps in your workspace
Bitbucket allows you to grant access to third-party applications that can access your data. It is important to periodically review which applications are installed in your workspace and remove the ones you don’t use or that are installed from unknown sources.
On the workspace settings review both the “Installed apps” and “Enable development mode” to make sure no unauthorized access is granted.
Be vigilant, be thorough, be secure.
In general, it’s more efficient to be able to continuously monitor and inspect the security posture across various Bitbucket settings. Cycode monitors and analyzes actual usage and then provides recommendations on where to tighten security settings and adjust the access model to fit the least privileged approach. By monitoring your organization’s SCM activity in real time and sending immediate alerts on security related incidents based on the policy that suits your organization, your org can easily avoid hacks and breaches.