In this blog, we walk through Atlassian’s cloud security practices and the controls we give you inside Bitbucket to maintain enterprise-grade security, without the overhead of managing it internally.
Security is an essential part of Atlassian’s offerings. We manage code and data for over 300,000 customers who serve hundreds of millions of users. To secure data at the scale we operate, we invest more in security than most individual organizations can.
Atlassian takes all necessary steps to protect and secure customer data from unauthorized access at the platform level. This includes data encryption, monitoring for security issues, performing regular backups and more. We also provide you with granular security controls within the product so you can configure security options per your internal policies.
Platform level security
Bitbucket Cloud is hosted on the same, secure platform that hosts Jira, Confluence and your other Atlassian products. Here are the things that we do at the platform level to protect your data and manage any security risks across our systems and people.
- Our production systems are hosted on Amazon Web Services (AWS) and hosted across multiple availability zones for optimal performance and to ensure that a failure in any single data center does not affect the availability of our products or your data.
- All code and data is encrypted in transit using TLS 1.2+ with Perfect Forward Secrecy (PFS) and at rest with AES-256 encryption to protect from any unauthorized access.
- Backups are taken daily and are stored in multiple data centers within a particular AWS region in case of a specific data center failure. We perform quarterly testing of our backups to ensure that they function as intended. While we backup data for disaster recovery purposes, you can use a backup app such as Rewind to backup for recovery due to user errors.
- We have multiple endpoint protection solutions to protect against threats such as malware.
- We use role-based access control to ensure our staff only have the access appropriate to their job role. All user accounts are approved by management prior to having access to data, applications, infrastructure or network components.
For more details, learn more about Atlassian’s security approach here.
Security settings that you can manage
Since security requirements vary across regions and industries, we offer several security settings within Bitbucket Cloud that you can configure to ensure that your access levels meet your internal compliance needs.
- IP allowlisting: With IP allowlisting, users will only be able to interact (view, push, clone, etc.) with your code if they are accessing Bitbucket from an IP address that you have selected and know is secure. This helps prevent unwanted third parties from accessing your code even if they have acquired a team member’s login credentials.
- Enforce 2FA: Another way of protecting against password leaks is by enforcing 2FA (two-step verification). This adds another layer of security by requiring that all Bitbucket users are required to use 2FA when accessing code.
- Disable public content: Bitbucket workspaces can contain both private repositories and public (open source) repositories. Public repositories are used to collaborate with users outside your organization while private repositories can only be accessed by users who are part of your workspace. You can disable users from creating public repositories within your workspace.
- Disable forking outside the workspace: By default, a user can fork code from a repository into a workspace outside of your private workspace. While there are some use cases where this helps, we also understand that you may want to prevent this to ensure that your code always stays within your private workspace. You can disable forking outside of your workspace.
- Support for self-hosted runners: If you have security requirements that require you to run your builds on-premises, you can configure your CI/CD pipelines to point to your own runners behind the firewall. We support on-premises runners across all major platforms.
- Audit logs: Bitbucket Cloud event logs are in Atlassian Guard so you can view them in one UI along with Jira and Confluence logs. Admins can track down changes in settings or permissions that affect compliance and security teams can use these logs to investigate incidents.
- Enforced signed commits via GPG or SSH keys: By enforcing signed commits, you can authenticate the user who submitted the commit to ensure that it has not been tampered with. You’ll be able to set rules to reject unsigned commits to ensure that all code being merged to production has been submitted by an authenticated user.
Code security tools that you can use to protect your customers
Beyond platform security and product security controls that we offer, our built-in CI/CD capabilities enable you to integrate code security tools into your code pipeline to ensure that your code is secure when it gets to your production systems.
Here are four things you can do to within your CI/CD pipeline to ensure that your code remains secure for your customers.
- Scan for security vulnerabilities: Bitbucket Pipelines now includes native security capabilities with a series of off-the-shelf Pipes that cover secret scanning, infrastructure-as-code scanning, and dependency scanning. When you use these pipes in your pipeline, you get alerted about security vulnerabilities before you ship code to your customers. You can also use a third-party security scan pipe such as Snyk, SonarCloud or others. See all security pipes here.
- Set workspace level merge checks: Create a list of your merge check criteria and implement them at scale at the workspace level, so it applies to merges across all repositories and projects. For example, scanning for secrets and security vulnerabilities could be applied as a workspace level check that needs to pass before the merge is approved.
- Orchestrate security at scale with dynamic pipelines: With our dynamic pipelines feature, you can have governance on all pipelines running across your organization and ensure that the required security steps are being performed before code is deployed. If not, you can dynamically insert these checks into the pipeline. This is an additional layer of security beyond merge checks that can be used in the CI and/or CD pipeline.
More resources, questions
If code security is a concern that is holding you back from moving forward with your migration to cloud, please reach out with your security questions via your Account Manager or open a support ticket (select ‘migration support’ from the dropdown). For more security resources, view our Trust Center for details on our practices.
If you’re on an active Data Center license, you can sign up for a free cloud migration trial of the Bitbucket Premium plan – sign up here – and use our cloud migration app to help you move your code to the cloud.