It's a significant risk in the software development environment – any user can check in sensitive information such as passwords, public keys, access keys, etc., in cleartext, right into a git repository.

Bitbucket won't trap that. It 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.

This poses an enormous security risk as this information could be passwords for network devices, private keys, or even personal credentials for highly sensitive systems. This can lead to privilege escalation, either by malicious users who have network access to the Bitbucket server, or by an external attacker who has bridged perimeter security.

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

Note: using with git-submodules

At the moment Security for Bitbucket doesn't validate changes in git-submodules recursively, scanning parent repository changes only, in case you push all changes together. If your workflow prohibits modifying/pushing sub-modules from parent repo, or if you push nested sub-modules first after such modification, your repositories will be secured and fully scanned by Security for Bitbucket hook.

Modes of Operation

Security for Bitbucket scanning can be triggered two ways:

  • A pre-receive hook can scan all code being pushed into Bitbucket, as described here. Code with failures can be blocked or simply produce a warning.

  • Full-content scans can be triggered on a per-repository or global basis, and can produce reports which can be exported.

Scan customization

Security for Bitbucket scanning can be customized in a few different ways:

Supported Secrets & Keys

Heres a list of current vulnerabilities that are detected by Security for Bitbucket Server:

Common KeysSupported
EC keys
SUPPORTED
Generic secret
SUPPORTED
Generic API keys (most general hash that an API key will match with)
SUPPORTED
PKCS8 (private keys generally used on unix machines)
SUPPORTED
Generic API keys (most general hash that an API key will match with)
SUPPORTED
SSH keys
SUPPORTED
Passwords in URL's
SUPPORTED
PGP keys
SUPPORTED
PKCS8 (private keys generally used on unix machines)
SUPPORTED
Password detection (people storing passwords in plain text)SUPPORTED
Custom key and pattern detection through advanced regex useSUPPORTED
API KeysSupported
AWS client ID's
SUPPORTED
AWS secret keys
SUPPORTED
AWS MWS keys
SUPPORTED
Facebook secret keys
SUPPORTED
Facebook client ID's
SUPPORTED
Facebook access tokens
SUPPORTED
Github keys
SUPPORTED
Google API key
SUPPORTED
Google Cloud Platform API key
SUPPORTED
Google OAUTH access token
SUPPORTED
Heroku API key
SUPPORTED
LinkedIn client ids
SUPPORTED
Mailchimp API key
SUPPORTED
Mailgun API key
SUPPORTED
Paypal BrainTree access tokens
SUPPORTED
Picatic API keys
SUPPORTED
Slack keys
SUPPORTED
Slack webhooks
SUPPORTED
Square access tokens
SUPPORTED
Square Oauth secrets
SUPPORTED
Stripe API key
SUPPORTED
Twilio API key
SUPPORTED
Twitter client ID's
SUPPORTED
Twitter secret keys
SUPPORTED