Bitbucket tightens security on private code

Bitbucket tightens security on private code


Atlassian recently added IP whitelisting and two-step verification to Bitbucket, its cloud-based version control system, to give administrators stronger controls on who can view, push, or clone a private code repository.

The first step in information security is to identify the crown jewels — the information that, if stolen, will be critically damaging to the organization — then make sure they are protected. For many, that means restricting who has access to the code repository containing the application source code.

[ Docker, Amazon, TensorFlow, Windows 10, and more: See InfoWorld’s 2017 Technology of the Year Award winners. | Cut to the key news in technology trends and IT breakthroughs with the InfoWorld Daily newsletter, our summary of the top tech happenings. ]

Atlassian actually added two-step verification as an optional feature to Bitbucket back in 2015. The current change gives administrators the ability to require developers to use two-step verification in order to access restricted repositories. This way, the administrators can enforce the level of security required instead of leaving it up to individual developers.

Administrators interested in requiring developers to use two-step verification need to be on the Bitbucket Premium plan, which is currently free but will eventually become $5 per month per user. Developers can continue to use two-step verification individually on free and standard plans.

Alternatively, administrators can turn on IP whitelisting within Bitbucket Premium and get similar results. IP whitelisting lets admins restricts the IP addresses from which developers can access a Bitbucket repository. This means the developer doesn’t need to use a mobile device as part of authentication — the machine used to access the repository is already the second factor. If the IP address of the laptop or mobile device the developer is using is not on the list of approved IP addresses, then the developer can’t proceed. Thus, an attacker with the developer’s legitimate login credentials would still need to find a way to access the authorized device in order to break in to the repository.

IP whitelisting can enforce a policy that certain application source code cannot be accessed from home or other public networks. Alternatively, it can be used to ensure that developers always connect to the VPN server before going to the repository.

At the moment, IP whitelisting only supports HTTPS interactions. Administrators can choose to allow or disallow SSH traffic to private code repositories after enabling the feature.

For many organizations who’ve stayed with on-premise version control systems because they want to be able to restrict who could actually view or push to the repository, IP whitelisting provides that level of control on a cloud platform, said Alastair Wilkes, a product manager at Atlassian.

Administrators can also combine two-step verification and IP whitelisting to apply an even stronger layer of protection. In this instance, even if the attacker manages to foil two-step verification by compromising or stealing the developer’s phone, the attacker won’t be able to access the repository because the laptop will have an unrecognized IP address.