Are You Making These Bitbucket Security Mistakes?
When developers build code, they often hardcode sensitive data for convenience.
Unfortunately, convenience and security are often incompatible, so security teams and developers struggle to maintain performance with secure coding best practices.
For example, a developer might hardcode credentials in a database connection string to execute queries on the database server during development. This practice is common, but it presents critical security vulnerabilities in your software should the code get promoted to a public repository in pull requests. This mistake and more are common in development environments and they should be mitigated so that you can maintain corporate security.
Atlassian Bitbucket is used in a continuous integration and continuous delivery (CI/CD) environment where developers rapidly code and automatically deploy updates during the software development lifecycle (SDLC).
Bitbucket security is often overlooked during code reviews, but the way you manage best practices in a CI/CD environment is critical to business success and continuity, especially for businesses that create software.
Saving Sensitive Information in Code
In addition to database connection strings, developers might integrate numerous third-party libraries and APIs that require credentials to access them.
To work with these third-party assets, developers hardcode credentials out of convenience.
While this might make it easier for developers to work with APIs or external assets, it increases the risk of accidentally (or purposely) pushing this sensitive data to a publicly accessible repository.
Public repositories aren’t the only recorded locations where keys are disclosed. Version control and repository change archives also keep record of secrets stored in code.
Soteri Bitbucket Security scan showing sensitive information in code.
The more locations secrets are stored, the higher the risk of a potential compromise from these secrets being stolen. As a matter of fact, attackers create scripts to scour public repositories for exposed secrets in code.
Millions of repositories expose secrets in public repositories across numerous open-source projects. Security issues targeting exposed secrets have only just recently been more prominent as more developers use Bitbucket, Github, and others for their open-source projects. With secrets in hand, attackers can use corporate API keys to run queries, authenticate into corporate web applications, or execute queries on a database hosting personally identifiable information (PII), making a data breach a source of compliance violations.
Not Using Automated Security Testing
Manual code review for project repositories might be an option for a single codebase, but it becomes impossible to keep up when you have several projects with numerous assets, resources, pipelines, files, applications, configurations, and everything else that goes into software development.
Automated security testing takes care of scanning projects for hardcoded secrets. A tool like Soteri Security for Bitbucket will automatically scan and audit Bitbucket Server or native Bitbucket Data Center integrations to detect any stored secrets.
Commit rejected by Soteri Bitbucket Security because it found a secret key in the code.
Scanning codebases for hardcoded secrets takes a proactive approach to application security, which is preferred over a reactive approach to scanning for vulnerabilities after code is deployed to production.
Other automation tools such as a static application security tool (SAST) or a dynamic application security tool (DAST) also automate scans on your software development environment. A SAST runs as developers code their projects and provide feedback before code is deployed to production so that developers can remediate security vulnerabilities immediately. A DAST runs scans on deployed code to find common security flaws often found by attackers using scripts that will automatically exploit them. Both improve the security of your overall software and infrastructure environment.
Using Bitbucket Apps That Haven't Gone Through Security Checks
It’s standard to have several third-party libraries integrated into application code, but the library or tool that you use in your development environment affects the security of your own applications. Developers should choose libraries with care and review the third-party library history. Unmanaged codebases or ones that do not go through Bitbucket security testing should be avoided.
The Atlassian Marketplace lets you know if a developer performs a security self-test on their project and if they participate in the bug bounty program. Marketplace developers willingly participate in both these security best practices to ensure that their products are checked for vulnerabilities.
Bitbucket has a “Security” section next to each project. If a developer does not participate in either of these programs, you are alerted to it. You will see either "This app is not part of the Marketplace Bug Bounty program” or "This partner has not completed the Security Self-Assessment Program" if the developer did not participate in either of these programs.
Bug bounty programs are invitations for security researchers, whitehat hackers, and other developers to find security flaws in an application in an effort to improve it. The security self-assessment program means that the developer reviewed their code for security flaws and passed Atlassian’s review for completion. For the best Bitbucket security, find a project that participates in both security testing and bug bounty programs.
Not Having a SECURITY.md File for Open-Source Code
A SECURITY.md file tells other developers, researchers, users, and anyone else interested where they can report discovered vulnerabilities. Just the presence of a SECURITY.md file tells other developers that security of your code is a priority, and you welcome any messages that indicate that there could be flaws, especially considering many open source code bases accept pull requests from third-party developers.
Adding a SECURITY.md file also directs contact to a specific email address, which also limits exposure of your issues to the public. Instead of forcing a developer to report an issue and expose a vulnerability, directing them to contact you will keep the security issue private so that you can remediate it before it’s exposed and exploited.
Once a security flaw is found, attackers write scripts to find and exploit it, leaving your customers vulnerable to a compromise. If you participate in a bug bounty program, you should follow through with rewards so that others know that it’s more rewarding to report the bug rather than maliciously exploit it.
Not Using 2-Factor Authentication
Your Bitbucket credentials are at risk from phishing, social engineering, and malware used to steal them. Once stolen, attackers attempt authenticating to various web applications, including Bitbucket. If you use the same credentials on other websites, those sites could expose your credentials and leave you vulnerable to unauthorized access to Bitbucket accounts.
One way to combat security issues with stolen credentials is to implement two-factor authentication (2FA). Suppose that an attacker manages to steal your Bitbucket credentials. They still wouldn’t be able to authenticate into your account without the two-factor validation step. You should not rely solely on 2FA, but it’s a solid defense against credential theft should you become a victim of phishing or other credential-stealing malware attacks.
The downside of two-factor authentication is that losing your smartphone blocks access to your account since you now can’t follow through on the second authentication step. Make sure you print out backup codes and keep them in a safe place before you log out of your account. With backup codes, you can recover your account and gain access to it even after you lose your smartphone to theft or unrecoverable damage.
Bitbucket Security Should Always Be a Priority
Avoiding these mistakes will greatly reduce your threat risk, and taking a proactive approach to Bitbucket security will keep you compliant. Soteri automation is a proactive approach to code security. A Soteri scan of your repositories finds any secrets stored in code so that you can take away overhead of security teams but maintain a high level of proactive defense against accidentally exposing secrets to the public.
Check out our documentation or book a demo to get started.