Security for Bitbucket (Server)

Security for Bitbucket actively detects and traps over 30 vulnerabilities before they’re committed to source control.

It’s an issue that often gets short shrift on development teams. But with team members posting and sharing all kinds of tokens, passwords, and other sensitive information, both personal and in the course of development, it’s all too easy to expose sensitive information in a production or release environment.

It’s just organic to software development environments — any user can check in sensitive information such as passwords, IDs, and access keys, in cleartext, right into a git repository.

This poses a significant security risk — committing passwords for network devices, private keys, or even personal credentials for potentially highly sensitive systems. Not trapping this information can all too easily lead to privilege escalation, either by malicious users who have network access to the Bitbucket server, or by an external attacker who has breached perimeter security.

Bitbucket won’t trap any of that. It simply has no built-in mechanism to detect and block a commit that contains sensitive credentials that could fall into the wrong hands; the typical developer workflows make this an all-too-easy omission even by well intentioned users. Worse, the core functionality of source control is to retain information across multiple document revisions, forks, commits, and changes. Once sensitive access data gets committed, it gets duplicated and exposed. Depending on the type of file, such sensitive credentials can end up embedded in a shippable product, sometimes in cleartext form.

Our application integrates directly with Bitbucket to actively detect and block attempts to check in sensitive information, accidental or otherwise.

Specific Vulnerabilities Supported

Widely-used platforms often specify keys, IDs, and tokens that have a unique, recognizable signature format. That allows Mohami’s algorithms to detect, notify, and stop commits that contain those signature patterns.

That means we can spot keys and IDs from AWS, Google, Facebook, Github, LinkedIn, Twilio and Stripe, among others. But that capability extends to standards-based credentials as well, including SSH, PKCS8, and PGP keys.

Full List of Supported Vulnerabilities

SFB currently supports over 30 distinct vulnerabilities:

● EC keys

● Generic secret

● Generic API keys (most general hash that an API key will match with)

● PKCS8 (private keys generally used on unix machines)

● Generic API keys (most general hash that an API key will match with)

● SSH keys

● Passwords in URL’s

● PGP keys

● PKCS8 (private keys generally used on unix machines)

● AWS client ID’s

● AWS secret keys

● AWS MWS keys

● Facebook secret keys

● Facebook client ID’s

● Facebook access tokens

● Github keys

● Google API key

● Google Cloud Platform API key

● Google OAUTH access token

● Heroku API key

● LinkedIn client ids

● Mailchimp API key

● Mailgun API key

● Paypal BrainTree access tokens

● Picatic API keys

● Slack keys

● Slack webhooks

● Square access tokens

● Square Oauth secrets

● Stripe API key

● Twilio API key

● Twitter client ID’s

● Twitter secret keys

Simple Implementation and Use

Setting up the plugin is just a couple of mouse clicks away. You can enable security hooks on the repository or the project level in seconds, and once activated SFB immediately becomes a sentinel watching every new commit and trapping anything that contains supported secrets and credentials.

On finding a vulnerability, SFB flags and specifies both the relevant file and the line number with the message “Push rejected due to security vulnerabilities”.

Try it in Minutes

Don’t wait for sensitive information to be committed and become a bigger problem. Get the Security Hook for Bitbucket right now. It’s free. Find it in the Atlassian Marketplace and click the GET IT NOW button.