Our Approach to External Security Testing
Welcome to our Security Testing hub, dedicated to providing you with comprehensive information on the security testing initiatives implemented by Atlassian to ensure the safety and protection of our products and valued customers.
Looking for something specific? Fast-track your search using one of the links below, or continue reading to delve deeper into Atlassian’s external Security Testing program.
Atlassian takes a multifaceted approach towards external security assurance of our products. We have an always-on, always-testing model leveraging a crowd-sourced bug bounty, which is complimented by regular white box penetration testing performed by external security consultancies and our internal Security Testing team.
Our philosophy and approach
Atlassian is well known for our values, which genuinely influence everything we do – including our approach to security testing. In practice, our values have led us to the following philosophies and approaches:
- Bugs are an unavoidable part of the development process - the question is not whether we have bugs but how effectively and quickly we find and address them. This doesn’t mean we like bugs or aren’t constantly innovating ways to reduce their frequency and severity, but denial is not a practical approach to software bugs.
- We support and use industry standards - standardization in our terminology and approach helps us ensure we’re covering everything and helps customers understand what and why we’re doing it. For example, standard ratings of vulnerabilities using the Common Vulnerability Scoring System (CVSS) ensures clarity for the severity of a particular vulnerability between us and our customers. We also follow the vulnerability management processes outlined in ISO 27001 and the Cloud Security Alliance (CSA).
- Third-party security researchers and penetration testers are a valuable extension of our team - if an Atlassian product has a vulnerability, it's in everyone’s interest – both ours and our customer's – to find and fix it as quickly as possible.
- Atlassian engages independent third-party penetration testers to find security vulnerabilities in our products annually and supplement our internal security team on engagements requiring highly specialized skill sets.
- Atlassian also incentives external researchers to identify vulnerabilities in our products via cash awards from our bug bounty program. With the help of external security researchers, we can scale our team far beyond traditional approaches!
- We are open and transparent about our Security Testing program - we provide Letters of Assessment (LoA) for the penetration tests performed on our products and statistics about bugs found through our bug bounty program below.
Ongoing security assurance
Penetration testing
We use specialist security services companies to complete penetration tests of our products and other systems. In addition to this, we have an internal Security Testing team who works in collaboration with third-party consultants to provide technical security assurance of high-priority projects - for example, a new product feature (e.g. Confluence Whiteboards), new infrastructure setup (e.g. our FedRAMP environment), or re-architecture (e.g. new Forge runtime).
Our approach to penetration testing in these cases is targeted and focused. Such tests will be:
- White box - The testers will be provided with design documentation and briefings from our product engineers and have the means to contact them with questions during the engagement to support their testing
- Code assisted - The testers will have full access to the relevant code base to help diagnose any unexpected system behaviour during testing and to identify potential targets
- Threat-based - Testing will focus on a particular threat scenario, such as assuming a compromised instance exists and testing lateral movement from that starting point
- Methodology driven - The testers use a range of tailored white box testing plays built upon industry-recognized methodologies such as the Open Web Application Security Project (OWASP). This ensures tests account for threats unique to Atlassian’s infrastructure and technologies.
We post Letters of Assessment (LoA) from our Penetration Testing partners available for external consumption at the bottom of this page. Due to the extensive internal information made available to the testers in conducting these assessments, we don't provide full reports. The majority of these systems and products will be included in our public bug bounty program, providing ongoing external assurance. Any findings from these assessments will be triaged and remediated according to our Public Security Vulnerability SLO.
Bug bounty
Our bug bounty program is hosted by Bugcrowd. This program ensures that our products are constantly tested for security vulnerabilities.
We believe the crowd of independent security researchers participating in our bug bounty contribute to an effective external security testing process because:
- A bug bounty is always on. Continuous testing is necessary for a truly agile development environment with frequent releases.
- A bug bounty has 60,000+ potential researchers. This provides a high aggregate capability of researcher skills to perform technical assurance.
- Bug bounty researchers develop specialized tooling and process vertically (specific bug types) and horizontally (specific bounties). This specialization provides the greatest chance of identifying obscure - but significant - vulnerabilities.
More than 25 of our products or environments – across our Data Center products, mobile apps, and Cloud products – are in-scope for our bug bounty program. Details of the number of vulnerabilities reported, our average response time, and our average payout are all included on the Bugcrowd site, with more than 2,800 researchers having registered specifically for our program.
Vulnerabilities we seek to be identified through our bug bounty program include common types captured in the Open Web Application Security Project (OWASP) and Web Application Security Consortium (WASC) threat lists.
As part of our initiative to be open and transparent, we invite anyone to visit our bug bounty program page, sign up for the program, and test us.
Marketplace Apps
Marketplace Apps are covered in separate bug bounty programs hosted by Atlassian, such as the Vulnerability Disclosure Program and the Atlassian Built Apps Bug Bounty Program.
Customer-initiated testing
We allow customer-initiated testing in line with our Terms of Use for our cloud products. We are committed to being open and will continue to publish statistics from our bug bounty program regularly.
While we believe our bug bounty programs provide a more efficient and economical approach to assessing the security of our products and services, we understand that you might want to test the security on your own. We allow for security assessments (pen tests, vulnerability assessments) to be performed by customers, and we ask that you follow a few rules to keep all of us safe.
Vulnerability reporting
If you find an issue you would like to report to Atlassian, please refer to our instructions on reporting a vulnerability.
At Atlassian, one of our values is Open Company, No Bullshit, and we believe that vulnerability disclosure is a part of that value. We aim to fix security vulnerabilities within the relevant service level objectives (SLOs). We accept disclosure requests through our bug bounty programs after an issue has been resolved and released in production. However, the request will be rejected if the report contains any customer data. If you plan to disclose outside of our bug bounty programs, we ask that you give us reasonable notice and wait until the associated SLO has passed.
Exclusions from our security testing program
Just as we are open and clear about the testing we do, we are also open and clear about the testing we don’t do ourselves or don’t currently support. Certain low-risk vulnerability types, such as enumeration and information gathering, are generally not considered significant risks.
Measuring the right things
Our security bug fix policy specifies Service Level Objective (SLO) timeframes for remediating vulnerabilities based on severity and product. When assessing vulnerabilities, we use the Common Vulnerability Scoring System, which helps communicate the severity of vulnerabilities to our customers.
In summary
Atlassian’s crowd-sourced bug bounty program, external security consultancies, and our internal Security Testing team form a comprehensive, mature, and transparent model. This ensures our products and platforms are constantly being tested and secured, providing continuous assurance to customers.
Want to dig deeper?
We’ve referred to quite a few other documents and resources in this brief paper, and we encourage you to dig into them to understand more about our approach to security testing.
Download current bug bounty reports
Any security vulnerabilities identified in the reports below are tracked in our internal Jira as they come through the Bug Bounty intake process. Any findings from the Bug Bounty will be triaged and remediated according to our Public Security Vulnerability SLO.
- Download the latest Atlassian bug bounty report (2024-10)
- Download the latest Jira Align bug bounty report (2024-10)
- Download the latest Opsgenie bug bounty report (2024-10)
- Download the latest Statuspage bug bounty report (2024-10)
- Download the latest Trello bug bounty report (2024-10)
- Download the latest Loom bug bounty report (2024-10)
Download annual bug bounty report
In addition to our quarterly bug bounty updates, we also release an annual report on our bug bounty programs. This report offers our customers insights into the progress of the program and provides detailed information about the types of vulnerabilities that have been discovered.
- Download the FY23 Atlassian Bug Bounty Report (July 2022 - June 2023)
Download Letters of Assessment (LoA)
Any security vulnerabilities identified in the reports below are tracked in our internal Jira as they come through the penetration test report process. Any findings from these assessments will be triaged and remediated according to our Public Security Vulnerability SLO.
- Letter of Assessment for Bitbucket Pipelines (2022-05)
- Letter of Assessment for Atlassian Log4j Library for Confluence and Jira (2022-12)
- Letter of Assessment for Statuspage Cloud (2022-12)
- Letter of Assessment for Atlas (2023-04)
- Letter of Assessment for Atlassian Assist (2023-07)
- Letter of Assessment for Atlassian Guard (Web Application) (2023-09)
- Letter of Assessment for Jira Service Management Data Center (2023-12)
- Letter of Assessment for Confluence Cloud (2023-12)
- Letter of Assessment for Trello (2024-01)
- Letter of Assessment for Bitbucket Cloud (2024-02)
- Letter of Assessment for Jira Work Management (2024-02)
- Letter of Assessment for Confluence Data Center (2024-02)
- Letter of Assessment for Jira Cloud Platform (2024-03)
- Letter of Assessment for Atlassian External and Internal Adversary Simulation Assessment (2024-04)
- Letter of Assessment for Bamboo Server & Data Center (2024-05)
- Letter of Assessment for Jira Product Discovery (2024-05)
- Letter of Assessment for Atlassian Analytics (Web Application) (2024-06)
- Letter of Assessment for Atlassian Guard (2024-06)
- Letter of Assessment for Jira Software Data Center (2024-06)
- Letter of Assessment for Fisheye & Crucible Server (Web Application) (2024-07)
- Letter of Assessment for Compass (Web Application) (2024-07)
- Letter of Assessment for Crowd Server & Data Center (2024-07)
- Letter of Assessment for SourceTree (2024-09)
- Letter of Assessment for Bitbucket Server and DC (2024-09)
- Letter of Assessment for Forge (2024-09)
- Letter of Assessment for Jira Service Management, Opsgenie Cloud & AirTrack (2024-09)
- Letter of Assessment for Jira Align (2024-09)
- Letter of Assessment for Loom (2024-10)