Security practices

We believe all teams have potential to do amazing things. Our mission is to unleash the potential in every team of every size and industry, and in turn, help advance humanity through the power of software.

We know that your mission is as important to you as our mission is to us, and information is at the heart of all our businesses and lives. This is why customer trust is at the center of what we do and why security is our top priority. We're transparent with our security program so you can feel informed and safe using our products and services.

Read more about our approach to security and learn about how customers can play their part.

The information on this page applies to Atlassian Cloud products Jira, Confluence, and Bitbucket unless otherwise noted.

Our security philosophy

Our approach to security is based around a couple of core themes:

We want to lead our peers in cloud and product security
Meet all customer requirements for cloud security and exceed requirements for industry security standards and certifications
Being open and transparent about our programs, processes, and metrics. This includes sharing our journey and encouraging other cloud providers to do the same, and setting new standards for customers

In this section we highlight the range of measures and initiatives we have in place to fulfill this philosophy as covered by these key themes.

We’re also proud of the fact that many of our flagship products underpin and form a critical part of our internal day-to-day processes and workflows at Atlassian. For example, our Jira and Confluence applications form key pillars of our approach to incident management and vulnerability management programs. That means we’re invested in securing our products not only because one of our key values is we “don’t #@!% our customers”, but because we use those same products ourselves.

Our team

We know most companies would say this, but we’re extremely proud of our security team. We believe we have recruited and grown a team that consists of some of the best and brightest in the industry. Our Security Team is headed up by our San Francisco based CISO and includes over 100 people based across our Sydney, Amsterdam, Bengaluru, Austin, Mountain View, San Francisco and New York offices with some remote team members. The team is continually growing in recognition of the priority Atlassian places on security. We have multiple sub-teams, including:

Product security – responsible for the security of our products and platforms
Ecosystem security – responsible for the security of our Marketplace and add-ons
Detection and Response – responsible for detecting and responding to security incidents
Red team - responsible for adversary emulation and exercising Detection and Response
Security architecture – responsible for defining the security requirements of our products and platforms
Corporate security – responsible for our internal security with respect to our corporate network and applications
Trust - responsible for tracking and responding to customer expectations and provide transparency into our processes and practices
Development and SRE – responsible for building and running tooling for the security team
Awareness and training - responsible for ensuring our employees and partners know how to work securely

While our security team continues to expand, everyone at Atlassian is part of our mission to achieve better security and this is made clear to all of our staff throughout their time with us. We want have a goal to lead our peers in cloud security, meet all customer requirements for cloud security, exceed requirements for all industry security standards and certifications and be proud to publish details about how we protect customer data. Our goals and vision are made clear to all of our staff throughout their time here at Atlassian.

Additional programs we use to support security

While we focus on the fundamentals of security , we also have a range of programs in place to ensure our approach to security remains wide-reaching, and proactive. These include:

Security Detections Program
Our security detections program compliments Atlassian’s incident response processes. Embedded within our standard incident management process, we have a separate program to proactively create searches and alerts for not only the incident types we face today, but those we will face in the threat landscape of the future.

Bug Bounty Program
Our Bug Bounty Program has consistently been recognized as one of the best in the industry, and enables us to leverage a trusted community of tens of thousands of researchers to test our products constantly and report any vulnerabilities they find.

Continually improving our security program

We are intent on ensuring our security program remains cutting edge and leading peers in the industry. We know to do that, we need to continually evaluate our current approach to security (including in comparison to our industry peers) identify opportunities for improvement.

To this end, we have undertaken (and will continue to undertake) numerous maturity assessments of our security program, using independent security consulting companies. In 2020, we also performed a peer assessment of our overall Trust and Security Program. We take the outputs from these processes, including key recommendations, and use them to address any gaps and opportunities for improvement.

We have also defined a series of programs across our various security – such as Product Security and Detection and Response – to guide our internal improvement. We have defined metrics to support each of these programs which we review through our Security Management Team. We use these metrics to identify and target areas for improvement across each of our core capabilities.

More information

While this paper will provide a broad overview of our approach to security, more detail regarding our security program is available on our Atlassian Trust Center. There’s also a range of dedicated web pages and whitepapers detailing different areas of our security program available, including:

Building security into our network architecture

Atlassian practices a layered approach to security for our networks. We implement controls at each layer of our cloud environments, dividing our infrastructure by zones, environments, and services. We have zone restrictions in place that include limiting office/staff, customer data, CI/CD and DMZ network traffic. We also have environment separation to limit connectivity between production and non-production environments, and production data is not replicated outside of production environments. Access into production networks and services is only possible from within those same networks – e.g. only a production service can access another production service.

Services must be explicitly authorized to communicate with other services through an authentication allowlist. We control access to our sensitive networks through the use of virtual private cloud (VPC) routing, firewall rules, and software defined networking, with all connections into those networks encrypted. We’ve also implemented intrusion detection in both our office and production networks to detect potential compromises.

Securing access to our networks through ZeroTrust

Atlassian secures access to its corporate network, internal applications and cloud environments through a concept called ZeroTrust. Simply stated, the core tenet of ZeroTrust is: “never trust, always verify.”

ZeroTrust moves away from traditional approaches for network security that rely solely on authentication of a user to determine whether a user can access resources on our network. Such an approach introduces the risk of an untrusted and insecure device potentially compromising security. As a result, many organizations have begun moving to a model in which only trusted devices are able to access their network using approaches such as mobile device management technologies or restricting access at a network level to a list of known devices.

While useful, these approaches lack granularity. Atlassian’s approach to ZeroTrust effectively ensures that whether users are able to access resources and services on our networks is a decision based on not only their authentication credentials, but also involves a dynamic policy decision that takes into account a range of factors to deny or allow access at a per-resource level based on the security posture of the user’s device (regardless of their location).

In simple terms, we have created three tiers of resources (based on their relative criticality and sensitivity) on our network around which ZeroTrust works:

Open tier – Any corporate user who successfully authenticates into our network can access these services
Low tier – Access to these resources is available to an authenticated corporate user only if they are accessing our network from a trusted corporate device (devices that Atlassian owns and manages) or a managed BYOD (this is a personal device that has been enrolled into Atlassian’s MDM program)
High tier – These resources are only available when accessed by an authenticated corporate user from an Atlassian issued corporate device. Access into our production services from our corporate network is only possible via a high-tier device and SAML authentication

Atlassian’s implementation of ZeroTrust works using a range of automated processes, services and components. At a high level:

Authenticated users on corporate or managed BYOD devices are granted a certificate by our Trust Engine service. The certificate includes metadata that marks whether it is for a BYOD or corporate device. These are deployed onto devices using our endpoint management solutions and reissued (or revoked) on a regular basis
When a user authenticates, their certificate is requested and presented to our infrastructure. The information from the certificate is used to verify the user’s account is valid and what type of device they have. Based on this information, the user is pushed either into our low tier network where their network and application access is restricted, or they are granted access to our high tier · Devices connected to Atlassian’s network are polled on an hourly basis and cross-referenced with our endpoint management solutions to determine ownership, device security and posture information. This includes ensuring devices meet minimum requirements including for antimalware, encryption, OS versions etc
A central database is updated with information regarding the compliance of user devices. This is used to determine whether users will be allowed or denied access to resources on our network. Devices marked as non-compliant will have their connection to our network terminated.

Atlassian has written a separate paper describing our philosophy and implementation of a ZeroTrust architecture.

Managing access to our systems and services securely

Atlassian has a well-defined process for provisioning (assigning or revoking) user access for all systems and services. We have an established workflow linking our HR management system and our access provisioning system. We use role-based access control based on predefined user profiles to ensure staff only have access appropriate to their job role. All user accounts must be approved by management prior to having access to data, applications, infrastructure or network components.

Supporting our ZeroTrust architecture, we control access to our corporate applications through a single-sign on platform. To access any of our applications, staff need to authenticate via this platform, including through the use of a second factor of authentication. Depending on the application, staff need to authenticate either using FIDO2 keys or via a mobile application authenticator provisioned to Atlassian staff – less secure authentication methods such as SMS and phone-based OTPs are not supported. Atlassian has adopted this approach to ensure our authentication process is highly resistant to phishing-based and man-in-the-middle attacks - any system that sends codes in a text message can be compromised by a skilled attacker.

Securing our endpoint devices

Corporate laptops

Devices that make up the Atlassian corporate fleet are configured to protect our data and reduce the risk of endpoint compromise. Under our Zero Trust program, devices that deviate from our approved standard are automatically prevented from accessing Atlassian systems.

Controls implemented on Atlassian corporate devices include:

Central device management - Our MDM (Mobile Device Management) solution is responsible for enforcing security configurations (including CIS benchmarks), and deploying software/updates to all Atlassian-owned devices.
Application control - Application control prevents the running of specific types of legitimate software (such as remote access solutions) that could compromise the security posture of our devices.
Endpoint firewalls - Prevents local services from being exposed to the network.
Anti-virus/endpoint detection & response (EDR) - Detects and blocks malware, collects log data and enables our security operations centre to respond to security incidents quickly.
Secure browsing environment - All browsers used by staff are configured to prevent the installation or use of malicious extensions, and block known phishing sites or sites distributing malware.
Disk encryption / screen locks - All devices are fully encrypted and set to lock after a period of inactivity.

Mobile / BYOD devices

Atlassian operates a BYOD (bring your own device) program for staff who wish to use their personal iOS or Android mobile devices to access corporate systems. All mobile devices must:

Be enrolled in our MDM (Mobile Device Management) solution
Have full disk encryption/screen locks enabled
Be running the latest Android/iOS operating system

Mobile devices operating under the BYOD program have limited access to Atlassian systems and cannot access customer data.

Keeping track of our information assets

Our production systems are located in infrastructure obtained through cloud service providers. These systems are not tracked at a hardware level due to the nature of the service. The underlying microservices that our products run on are tracked in a custom-built ‘Service’ database. This database is updated automatically when a service is deployed.

Our Workplace technology team maintains an asset inventory of all endpoints using our own Jira software for tracking purposes.

Managing changes in our environment

Our change management process is slightly different from a traditional one. Traditional change management processes rely on a pyramid-style change control hierarchy. That is, when someone wants to make a change, it has to be presented to a board that eventually approves or denies it.

We have embraced an open source style approach we call “Peer Review, Green Build” (PRGB). In contrast to a traditional change management process the PRGB approach requires that each change – be it a code change or an infrastructure change – is reviewed by one or more peers to identify any issues the change may potentially cause. We increase the number of reviewers based on the criticality of the change or the criticality of the systems that the change is going to impact, trusting our engineers to identify issues and then flag them before the change can go through. This process works well to provide a dynamic and adaptable way of managing changes in our environment. The green build portion of this control refers to a successful or clean build in our CI/ CD with the new changes included. If the change introduces components that do not successfully pass any of the integration, function, unit or security tests, the build is rejected and returns to the original change request to address any issues.

Managing configurations in our systems

We have a limited set of engineers and architects who are allowed to install software in our production environment. In most cases, software installation is not possible. Configuration management tools are utilised in our production environments to manage configurations and changes to servers. Direct changes made to those systems are set to be overwritten by the approved configuration pushed through those configuration management tools ensuring consistency. We rely on standard Amazon Machine Images (AMIs), all changes to either our AMIs or operating systems must be made via our standard change management process, we track and report on exception configurations, and we have implemented resource isolation so issues with services don’t impact other services. We also rely on our Peer Review / Green Build (PRGB) process to ensure multiple reviewers approve configuration changes pushed through configuration management tools. All builds are cryptographically signed and only signed builds are allowed to run in our production environment.

Making use of logs

We use a SIEM platform to aggregate logs from various sources, apply monitoring rules to those aggregated logs, and then flag any suspicious activity. Our internal processes define how these alerts are triaged, investigated further, and escalated appropriately. Key system logs are forwarded from each system where logs are read-only. The Atlassian Security Team creates alerts on our security analytics platform and monitors for indicators of compromise. Our SRE teams use this platform to monitor for availability or performance issues. Logs are retained for 30 days in hot backup, and 365 days in cold backup.

Key system logs are combined into both an internal log analysis system and an Intrusion Detection System.

Logs are a key component of our overall incident detection and response strategy which is covered in detail in ‘How we identify, protect against and respond to security threats’ section.

Business continuity and disaster recovery management

We care deeply about the resiliency of our products, not least because we – internally, in Atlassian – rely on the very same products. We appreciate that disruptions can happen. So we are determined to build-in processes to plan for disruptions, and handle disruption with minimal impact to our customers when they do occur. Our business continuity (BC) and disaster recovery (DR) programs capture the various activities done to meet those objectives.

Leadership involvement in BC and DR planning activities ensures the oversight required to make sure accountability for resiliency reaches all teams. Our BC and DR planning activities strive to achieve the right balance between cost, benefits and risk through an analysis of ‘recovery time objectives’ (RTO) and ‘recovery point objectives’ (RPO) of services. This analysis has led to us establishing a simple 4-tier system to help group services based on their respective recovery requirements – details of this approach can be found on our page on How Atlassian Manages Customer Data.

Our BC and (DR) programs involve the following activities:

1. building-in redundancy measures to meet resiliency requirements

2. testing and verifying those redundancy measures

3. learning from tests to continuously keep improving BC and DR measures

We build our products to best utilise redundancy capabilities, such as availability zones and regions, offered by our cloud service providers.

We continuously monitor a wide range of metrics with the aim of detecting potential issues early. Based on those matrices, alerts are configured to notify site reliability engineers (SREs) or the relevant product engineering teams when thresholds are breached so that prompt action can be taken through our incident response process. SREs also play a key role in identifying gaps in the DR program, and work with our risk and compliance team to close those gaps. Each of our teams also include a DR champion to oversee and help manage disaster recovery aspects related to that team.

Our DR tests cover process and technology aspects, including relevant process documentation. The frequency of DR tests are done in line with the criticality tier of each service – for example, backup and recovery processes for key customer facing systems are tested quarterly. We conduct manual and ad-hoc failover tests on our systems. These tests range from less complicated tabletop simulation exercises to more complicated availability zone or regional failover tests. Regardless of the complexity of the test, we are diligent in capturing and documenting test results, analysing and identifying possible improvements or gaps, and then driving them to closure with the help of Jira tickets to ensure continuous improvement of the overall process.

We conduct annual Business Impact Assessments (BIAs) to assess the risks associated with critical services. The output of these BIAs assist in driving the strategy for DR and BC efforts. As a result, critical services are able to develop effective DR and BC plans.

Backups

We operate a comprehensive backup program at Atlassian. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our Atlassian Cloud offerings, and specifically referring to customer and application data, we also have extensive backup measures in place. Atlassian uses the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.

Amazon RDS snapshots are retained for 30 days with support for point-in time recovery and are encrypted using AES-256 encryption. Backup data is not stored offsite but is replicated to multiple data centers within a particular AWS region. We also perform quarterly testing of our backups.

For Bitbucket, data is replicated to a different AWS region, and independent backups are taken daily within each region.

We do not use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted issues, projects, or sites. To avoid data loss, we recommend making regular backups. Learn more about creating backups in the support documentation for your product.

Physical security

Physical security controls in our offices are guided by our physical and environmental security policy which ensures robust physical security is implemented across our environments on premises and in the cloud. This policy covers areas such as secure working areas, securing our IT equipment wherever it may be, restricting access to our buildings and offices to appropriate personnel, and monitoring physical ingress and egress points. Our physical security practices include reception attendance during work hours, requirements for visitors to register, badge access to all non-public areas, and we partner with our office building management for after hours access and video recording at ingress and egress points - both for main entrances as well as loading areas.

Our partner data centres are SOC-2 compliant, at a minimum. These certifications address a range of security controls including physical and environmental security and protection. Access to the data centres is limited to authorized personnel, and verified by biometric identity verification measures. Physical security measures include on-premises security guards, closed circuit video monitoring, man traps, and additional intrusion protection measures.

Data centers

Atlassian products and data are hosted with the industry-leading cloud hosting provider Amazon Web Services (AWS). We make use of optimal performance with redundancy and failover options globally. We make use of multiple geographically diverse regions within AWS (US-East and USWest, European union and the Asia Pacific), and multiple availability zones within each of those regions to ensure that a failure in any single data center does not affect the availability of our products or customer data. For more information, see our separate paper on How Atlassian Manages Customer Data and our Cloud Hosting Infrastructure page.

Physical access to our data centers, where customer data is hosted, is limited to authorized personnel only, with access being verified using biometric measures. Physical security measures for our data centers include on-premise security guards, closed-circuit video monitoring, man traps, and additional intrusion protection measures.

Encryption of data

Any customer data in Atlassian cloud products is encrypted in transit over public networks using TLS 1.2+ with Perfect Forward Secrecy (PFS) to protect it from unauthorized disclosure or modification. Our implementation of TLS enforces the use of strong ciphers and key-lengths where supported by the browser.

Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie, Trello, Loom, Compass and Rovo use full disk, industry-standard AES-256 encryption at rest. Please refer to the Atlassian Trust Roadmap to keep up to date with our platform updates.

Tenant separation

While our customers share a common cloud-based IT infrastructure when using Atlassian’s products, we have measures in place to ensure they are logically separated so that the actions of one customer cannot compromise the data or service of other customers.

Atlassian’s approach to achieving this varies across our applications. In the case of Jira and Confluence cloud, we use a concept we refer to as the “tenant context” to achieve logical isolation of our customers. This is implemented both in the application code, and managed by something we have built called the “Tenant Context Service” (TCS). This concept ensures that:

Each customer’s data is kept logically segregated from other tenants when at-rest
Any requests that are processed by Jira or Confluence have a “tenantspecific” view so other tenants are not impacted

In broad terms, the TCS works by storing a "context" for individual customer tenants. The context for each tenant is associated with a unique ID stored centrally by the TCS, and includes a range of metadata associated with that tenant (such as which databases the tenant is in, what licenses the tenant has, what features they can access, and a range of other configuration information). When a customer accesses Jira or Confluence cloud, the TCS uses the tenant ID to collate that metadata, which is then linked with any operations the tenant undertakes in the application throughout their session.

The context provided by the TCS effectively acts as a ''lens'' through which any interactions with customer data occur – and this lens is always confined to one specific tenant. This ensures that one customer tenant does not access data of another tenant – nor for one tenant to affect the service of another tenant through their own actions.

More information about our cloud architecture is available as part of our cloud support resources.

Controlling access to customer data

We treat all customer data as equally sensitive and have implemented stringent controls governing this data. Awareness training is provided to our internal employees and contractors during the on-boarding process which covers the importance of and best practices for handling customer data.

Within Atlassian, only authorized Atlassians have access to customer data stored within our applications. Authentication is done via individual passphrase-protected public keys, and servers only accept incoming SSH connections from Atlassian and internal data center locations. All access is restricted to privileged groups unless requested and reviewed, with additional authentication requiring 2FA.

With stringent authentication and authorization controls in place, our global support team facilitates maintenance and support processes. Hosted applications and data are accessed for the purpose of application health monitoring and performing system or application maintenance, or upon customer request via our support system. Our customers are also provided with options regarding explicit consent as to which support engineers are appropriate to access their data through our consent control checker.

Unauthorized or inappropriate access to customer data is treated as a security incident and managed through our incident management process. This process includes instructions to notify affected customers if a breach of policy is observed.

Retention and deletion of data

We have provisions in place so that we can respond to user requests to delete personal information, and we also help end users with Atlassian accounts delete their personal information. We also have import and export tools so that our customers can access, import and export their data using Atlassian’s tools.

Customer sites are deactivated 15 days after the end of a customer’s current subscription period. Atlassian retains data for deactivated sites for 15 days (for evaluation sites) or 60 days (for paid subscription sites) after the end of the customer’s current subscription period. Note that in the case of Jira, data will only be deleted if you unsubscribe from all Jira products you were previously subscribed to.

Additional information is available on our Security Practices page or on our Data Storage FAQ.

Security awareness training

All Atlassians undergo security awareness training during the onboarding process and then on an annual basis thereafter to ensure they are aware of the latest security threats and utilise secure practices in their work.

We understand that many of the security threats faced by our team are the same security threats faced by our contractors, so we extend security awareness training to cover those contractors as well.

Our security awareness training program addresses a range of security topics including current security threats, attacks and scams, identifying and reporting phishing simulations, classification and management of data, protection of customer data and, identifying and reporting security risks. All topics covered in our security awareness training align to our compliance and regulatory requirements.

In addition to general information security training for all Atlassians, we deliver specialised training to our developers on secure coding and vulnerability management to provide secure outcomes for our company and customers. Development teams are also supported with the provision of dedicated security engineers across the organisation to help with security-related operational tasks.

We also maintain open channels of communication so that all our people have easy access to the security team for support.

Security champions program

Our security champions program includes a committed security advocate within every one of our product and service teams. This dedicated champion assumes responsibility for promoting key security practices among fellow team members, and collaborates on security issues with our central security team to facilitate improved communication flows.

Our champions are provided with advanced application security training to help them identify vulnerabilities, understand secure development practices, and write secure code.

Atlassian’s security champions meet on a regular basis to share tools and knowledge around the latest security issues and challenges they’re facing so that all our teams can benefit. The program has served as a springboard for enabling security to form an even more integral part of our culture.

Trust scorecards

We’re focused on ensuring that trust (including security, anti-abuse, compliance, etc.) is front and center of mind across our entire product suite. To this end, we’ve implemented an accountability and monitoring system referred to as “product trust scorecards” to measure the trust and security posture of all products at Atlassian. This is an automated process Atlassian has created whereby we use a broad range of criteria (e.g. current vulnerabilities, training coverage, compliance alignment, and recent security incidents) to provide an overall trust score for each of our products.

This scoring process gives each of our product teams an objective view into what areas of trust require attention, and identifies existing gaps that need to be addressed and actions to address these gaps. The trust scorecards process also enables the Atlassian trust organisation to easily keep track of how all products are tracking from a trust perspective over time, particularly as our product suite continues to scale.

Security engagements

Our product security team runs strategic engagements , which are aimed at conducting time-boxed security assessments to identify technical threats, especially in critical platform or product areas. The primary outcome is security gaps identification and remediation to consistently improve the security posture of our platform or product areas.

Targeted security assurance

The product security team also runs a security review process to provide security assurance across software projects. A risk-based process is used to prioritise where to focus assurance activities, and identify what actions are required to mitigate project risk. Depending on the identified level of risk, assurance activities include a combination of:

Threat modeling
Design review
Code review (manual and tool assisted)
Security testing
Independent assurance using expert third party researchers and consultants

As we discuss elsewhere in this paper, we also have an industry leading Bug Bounty Program which provides ongoing security assurance using a trusted, crowd-sourced group of security researchers.

Secure design through threat modelling

During the planning and design phases for our products, threat modelling to understand better security risks when projects face complex threats or involve development of security critical features. This involves a table-top/ brainstorm session between our engineers, security engineers, architects and product managers to identify and priority relevant threats. This information feeds into the design process and ensures appropriate controls are implemented. It also supports targeted review and testing in later phases of development.

Code analysis

We have an automated code analysis platform (called Security Assistant) that covers all code repositories at Atlassian. This platform runs a variety of static analysis tools (which we are continually adding to and improving) that help to ensure the overall security of our code. Any time a pull request is raised in a repository, the platform:

Finds and identifies outdated code dependencies that may introduce vulnerabilities (we discuss these in more detail in the part of this paper that discusses our approach to vulnerability management)
Identifies any accidental or inadvertent disclosure of secrets in code repositories (e.g. authentication tokens or cryptographic keys)
Undertakes an analysis to identify any problematic coding patterns that could lead to vulnerabilities in our code

Security testing

Our security testing approach is built around the concept of ‘continuous assurance’ – not only do we make use of targeted, point-in-time penetration tests, we also have an always-on testing model using a crowd-sourced bug bounty. We believe this multi-faceted approach maximises our chances of finding vulnerabilities and providing our customers with the most secure products possible. More information is available in our separate paper covering our approach to external security testing, and a summary of our testing measures is provided below:

Atlassian Security Reviews - As mentioned above, our product security team runs a security review program including security testing as a regular activity. Testing consists of code review and application security testing, targeting areas of weakness highlighted by risk assessment
Third-Party Security Testing - We use specialist security consulting firms to conduct white-box, code assisted and threat based penetration tests on high risk products and infrastructure (whether this be in our cloud environments, a new product or a fundamental re-architecture)
Atlassian’s Red Team – We have an internal red team whose role is to simulate adversaries attempting to identify and exploit vulnerabilities that exist within our systems, processes, and environments, so that we can ensure they are identified and addressed as promptly as possible
Bug Bounty - We also make use of Bugcrowd’s community of trusted security researchers to run our acclaimed bug bounty program, so that we can continually identify vulnerabilities in our products and ultimately make the cost for the bad guys in finding and exploiting those vulnerabilities higher over time. Our bug bounty program has been recognised on multiple occasions as the best in the industry. More than 25 of our products or environments – ranging across our server products, mobile apps and Cloud products – are in-scope for our bug bounty program.

Any security vulnerabilities identified in the reports below are tracked in our internal Jira as they come through the Bug Bounty intake process and any findings from the Bug Bounty will be triaged and tracked according to our Security Vulnerability Service Level Objectives (SLOs).

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)

Vulnerability management

Atlassian is constantly working to reduce the severity and frequency of vulnerabilities in our products, services and infrastructure and ensure that identified vulnerabilities are fixed as quickly as possible. To facilitate this, we have implemented a multi-faceted and continually evolving approach to vulnerability management that utilizes both automated and manual processes to identify, track, and remediate vulnerabilities across our applications and infrastructure.

We identify security vulnerabilities via a number of different sources such as automated scanners, internal security reviews, customer reports, and our public bug bounty program. Once a vulnerability has been identified, a ticket is logged in our purpose-built company-wide vulnerability tracking Jira project and assigned to the relevant system owner or engineering team. Our centralized approach allows us to leverage automation to provide proactive notifications, automated escalations, and enterprise-wide reporting to ensure that vulnerabilities are remediated in a timely fashion.

More information is available in our dedicated paper on Atlassian’s Approach to Vulnerability Management.

Infrastructure

We use a range of vulnerability detection tools that are run regularly across our infrastructure to automatically scan for and identify vulnerabilities. This includes:

Network scans – to identify active services, open ports and applications running across our environment, as well as any vulnerabilities at the network level
Continuous asset discovery – we undertake continuous asset discovery and security analysis across our external network perimeters. We also have an internally developed asset inventory and discovery mechanism
AWS Configuration Monitoring – we monitor the configuration of our AWS environments against established configuration baselines

We are continually reviewing the latest tools available and adding them to the suite we use if we believe they will enhance our vulnerability detection capabilities.

Products

As part of our development process – and in addition to our previously mentioned bug bounty program - we use a range of tools to try to identify and prevent as many vulnerabilities and bugs as possible from making their way into our products by the time our customers and users have access to them. We use a platform to facilitate the deployment of these tools across our code repositories. These include the following:

Atlassian deploys the bulk of its services using Docker container images. These images provide a packaged, self-contained environment consisting of relevant system libraries, tools, configuration settings and any other dependencies required so that our products are able to run regardless of individual machine configuration parameters. We integrate a full container security scanning process into our CI/CD pipeline for any containers that are deployed into our development, staging or production environments
Our products and services rely on numerous open source libraries. We use a combination of internally built, open source, and commercial tools to scan for and identify dependencies and compare these to a database of known security vulnerabilities

In addition, when a vulnerability is identified by one of our users during standard use of a product, we welcome notifications and respond promptly to any vulnerabilities submitted. We keep the submitter updated as we investigate and respond to the issue.

As we have also mentioned previously in this paper, we use a “Peer Review, Green Build” (PRGB) process that means that any change in code to a product is reviewed by one or more peers to identify any issues the change may potentially cause.

We have a documented bug fix policy which defines the timeframes for resolving security issues in our products, depending on the severity level of the bug.

More information about our bug fix policy is available here. Information about recently fixed bugs, as well as bugs we’re currently working on addressing for our various products, are available at our public bug tracker.

Incident response

Atlassian has a comprehensive approach to handle security incidents. We consider a security incident to be any instance where there is a negative impact to the confidentiality, integrity or availability of customers’ data, Atlassian’s data, or Atlassian’s services.

We have a clearly defined internal framework that includes documented playbooks for different incident types. The framework covers the steps we need to take at all stages of incident response to ensure our processes are consistent, repeatable and efficient. These include coverage of incident detection and analysis, incident categorization, containment, eradication and recovery. This consistency is supported through the use our own products, including Confluence, Jira and Bitbucket as part of our incident response processes:

Confluence is used to create, document and update our response processes in a central location
Jira is used to create tickets for tracking progress on the response process for security incidents (potential and actual) from start to finish
Bitbucket is used in instances where we develop code-based solutions for responding to certain edge-case problems that arise with certain incidents

Comprehensive and centralized logging and monitoring of our products and infrastructure is in place to ensure we quickly detect potential incidents, supported by a team of highly-qualified on-call incident managers who have significant experience in coordinating an effective response. We also have access to a range of external experts to assist us with investigating and responding as effectively as possible.

We have notification processes in place for our customers if their data is involved in a confirmed incident, as well as a robust post-incident review process so we can take any lessons from an incident to improve our practices to make the job of malicious actors harder in the future. For more information, please see our separate paper our Atlassian Trust Center on Our Approach to Managing Security Incidents.

Security detections program

In recognition of the need to build upon our approach to incident management in the context of an increasingly complex threat landscape, Atlassian has introduced what we call our “security detections program”. Detections are built to continuously monitor the Atlassian environment to detect malicious activity targeting Atlassian and its customers and deliver alerts to Atlassian’s Security Incident and Event Management platform .

Our Detections team focuses on the regular creation of new detections, tuning and improving existing detections, and automating detection responses. They do this across a number of dimensions, including products, attack types and log sources so as to ensure the coverage of our detections is as effective and comprehensive as possible.

The aim of the program is to ensure we not only ensure we are prepared for the threats we face today, but sufficiently anticipate and prepare for the threat landscape of the future. Our Security Automation Engineering team has also created a tool to standardize the detections we create to ensure a high level of consistency and quality amongst the detections we execute – something we believe is a first in the industry.

For more information about our Security Detections Program, please visit this page.

Red Team Program

The Atlassian Red Team's mission is to continuously increase the resilience of Atlassian against sophisticated attacks. Acting from a hostile perspective, they uncover technical, physical and social vulnerabilities to challenge our teams ability to react under real conditions. This approach enables us to develop and facilitate effective security improvements for Atlassian. Our approach helps Atlassian evaluate threats, protect our assets and respond appropriately to real attacks.

The Red Team at Atlassian focuses on full-scope adversarial emulation. We act like the attackers that are most likely to target the company, and do our best to infiltrate and compromise critical systems. After which, we notify everyone involved and work together to implement long-term sustainable solutions to the security vulnerabilities that were discovered.

Measure and improve the effectiveness of the Detection and Response program
Create significant positive change in Atlassian security posture and capabilities
Increase understanding of our vulnerability and ability to respond to real world attacks

Supplier risk management

Where Atlassian engages any third-party suppliers (including contractors and cloud service providers) we are intent on making sure those engagements do not in any way jeopardise our customers or their data. To this end, a review process is undertaken by our legal and procurement teams for any proposed third-party supplier engagements. If an engagement is determined to have any medium, high or critical risks, additional risk assessments are conducted by security, compliance, risk, and legal teams. Ongoing due diligence also occurs via subsequent reviews - either upon contract renewal or periodically depending on the risk level of the engagement.

Atlassian also requires its suppliers to comply with minimum security requirements as part of their engagement with us. These are enforced via inclusion in our supplier contracts. These requirements will vary depending on the risk level of the engagement, and includes the following:

SAML2.0/SSO integration with Atlassian’s single sign on platform
Encryption for data in transit and at rest using non-deprecated algorithms
Having sufficient logging mechanisms in place to provide Atlassian with relevant information regarding potential security incidents

The Atlassian marketplace

Atlassian’s marketplace is a platform where users of our products are able to buy apps that provide add on-functionality to Atlassian products, or enable our products to connect with third party tools. While most of the applications made available in the marketplace are produced by third-party developers, Atlassian takes a number of steps to ensure that security still forms a central part of the marketplace ecosystem. These include:

The Marketplace Bug Bounty Program – Atlassian has a best-in-class marketplace bug bounty program to increase security and trust for all Marketplace apps. Participating Marketplace Partners are able to proactively combat security risks before they arise by incentivizing security researchers to find vulnerabilities. To get a Cloud Fortified or Cloud Security Participant badge, apps must participate in this program. Learn more

Ecoscanner - Atlassian’s Ecoscanner platform performs security checks across all Marketplace cloud apps on an ongoing basis. With Ecoscanner, Atlassian continuously monitors all Marketplace cloud apps for common security vulnerabilities to ensure the security of our ecosystem. Learn more

Vulnerability Disclosure Program - The Vulnerability Disclosure Program provides another channel for customers or security researchers to report cloud app vulnerabilities to Atlassian and to Marketplace Partners. Atlassian runs this program and defines the parameters so that all cloud apps can mitigate security risks. Learn more

Cloud App Security Requirements - Atlassian has defined a minimum set of requirements that all Marketplace apps must meet. These requirements are mandatory and are aimed at enforcing security best practices across all apps. Learn more

Security Bug Fix Policy - In order to ensure the security of all apps in the Atlassian ecosystem, all Marketplace Partners are required to adhere to security bug fix SLAs for any app listed on the Atlassian Marketplace. If a vulnerability is detected, partners are required to address it in a timely manner. Learn more

Privacy and Security tab - To elevate the trust posture of Marketplace and increase visibility on security indicators, the Privacy and Security tab was introduced in the Marketplace listing UI for cloud apps. The Privacy and Security tab provides detailed information on the privacy, security, data handling, and compliance practices followed by the cloud apps. As the Security Self Assessment program(SSA) got deprecated on August 22, 2023, the Privacy and Security tab has replaced SSA as a Cloud Fortified requirement. Learn more

More information about our approach to security in the marketplace is available via our Atlassian Marketplace Trust Center.

Our policy and risk management programs

Atlassian has a Trust Management Program (TMP) which is based on the ISO 27001 Information Security Management System Standard. This program takes our customer’s security needs into consideration and arrives at a set of security requirements unique for Atlassian - taking into account controls listed across a range of international security standards.

We then consider whether those controls are contextually appropriate for our particular environment and company, and the best way to implement them. Our TMP has multiple pillars:

Our Policy Management Program (PMP) – The PMP forms the basis of our TMP. It consists of a series of security policies covering the domains listed in both the ISO 27001 standard as well as the Cloud Security Alliance’s Cloud Controls Matrix (CCM). The security policies we have created are made available internally to all of our teams to ensure they understand the bar they are expected to meet when it comes to security. The policies are updated annually and in particular whenever we observe new threats and risks that require modifications to our security approach. Excerpts of our technology policies are available here.
Our Risk Management Program (RMP) – We undertake on-going risk assessments to our environments and products in order to evaluate the current risks we face and ensure the controls we have in place effectively manage those risks. The nature of how these risk assessments are conducted will vary depending on the environment/ product being assessed – for example, in the case of our products, these will often be technical risk assessments or code reviews. However, we also consider and seek to uncover higher level business risks as well. We perform and undertake an annual risk assessment in support of our Enterprise Risk Management Program and implement projects to mitigate identified risks at least quarterly. For more information on our approach to Enterprise Risk Management, visit our Atlassian Trust Center.

Our TMP includes weekly compliance health reviews and other meetings which are documented internally, to ensure it continues to operate effectively.

Compliance with laws, regulations and standards

Our security program has been developed and implemented in accordance with various industry standards. Adhering to recognized industry standards is a fundamental aspect of our security strategy, as we recognize that they offer independent assurance to our customers that Atlassian’s security program satisfies a foundational set of security controls.

We adhere to several key standards, including:

ISO 27001	The basis of ISO 27001 is the development and implementation of an Information Security Management System (ISMS), and then implementing and managing a suite of controls covered under ‘ISO 27001: Annex A’ through that ISMS. ISO/IEC 27018 is a code of practice which provides additional implementation guidance for applicable ISO/IEC 27002 controls for the protection of Personally Identifiable Information (PII) in cloud environments. View our ISO 27001 certificate
PCI-DSS	When you pay with your credit card for Atlassian products or services, you can rest assured that we handle the security of that transaction with appropriate attention. Atlassian is a PCI-DSS compliant merchant. View our Attestations of Compliance (AoC)
CSA CCM / STAR	The CSA Security, Trust & Assurance Registry (STAR) is a free, publicly accessible registry that documents the security controls provided by various cloud computing offerings. The CSA STAR Level 1 Questionnaire for Atlassian is available for download on the Cloud Security Alliance’s STAR Registry.
SOC 2	These reports help our customers and their auditors understand the controls established to support operations and compliance at Atlassian. Atlassian has achieved SOC 2 certifications for many of our products. View our SOC2 certification reports
GDPR	We appreciate that our customers have requirements under the Global Data Protection Regulation (GDPR) that are directly impacted by their use of Atlassian products and services, which is why we have devoted significant resources toward helping our customers fulfill their requirements under the GDPR. Learn more about our approach to GDPR compliance on our Atlassian GDPR Compliance page.
FedRAMP	The Federal Risk and Authorization Management Program (FedRAMP) is a U.S. Federal government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. View individual status on the FedRAMP Marketplace for the following Atlassian products: Atlassian Government Cloud Trello Enterprise Cloud

Further to the information provided above, a comprehensive list of industry standards with which we comply is available on our Compliance Program page.

Privacy at Atlassian

Atlassian has a comprehensive and global Privacy Program in place to ensure we meet our data protection and privacy obligations and commitments. We incorporate our privacy principles into the development and use of our products, including by embracing privacy by design in everything we do:

Transparency: we’re committed to maintaining trust through transparent policies. You can find information on our privacy practices and key privacy documentation (including our Privacy Policy and Data Processing Addendum) in our Trust Center and at our Legal information.
Data transfer impact assessment: we provide information to help our customers conduct data transfer impact assessments in connection with their use of our products. Our Data Transfer Impact Assessment is available here.
Access controls and training: Atlassian staff that access and process personal data are trained on how to handle it, and are bound to maintain its confidentiality and security.
Data management tools: we provide our customers with tools to assist them in meeting their privacy obligations as it relates to data subject requests, including the right to deletion and the right to access. Information on our data management tools and processes can be found here.
News and updates: you can subscribe to receive notifications from us about updates to our legal terms and our list of sub-processors here.

Internal and external audit

We perform comprehensive security evaluations as part of our annual compliance audits (e.g., SOX, SOC 2), which also involve an independent assessment by external audit firm(s). In addition, we perform internal operational audits in areas that are deemed high risk, including a variety of security topics. The results of these audits are reported to the Audit Committee of our Board of Directors, and are fed into a continuous improvement cycle that helps us keep sharpening the overall security program.

Law enforcement and government requests for data

As part of our commitment to earning and maintaining our customers' trust, we publish an annual Atlassian Transparency Report with information about government requests for users' data as well as government requests to remove content or suspend user accounts.

Atlassian responds to government requests in accordance with our Privacy Policy, Customer Agreement, Acceptable Use Policy, and any applicable Product-Specific Terms. We also provide additional information about our policies and procedures for responding to requests for user data in our Guidelines for Law Enforcement. In responding to any government request (whether a request for user data or a request to remove content/suspend user accounts), Atlassian follows these guiding principles:

In line with our Atlassian value of “Don’t #@!% the Customer,” Atlassian reviews all government requests targeting our customers' data with strict scrutiny, including by questioning the validity of the request and challenging any request as permitted by law, including requests that are vague, over-broad, or improperly served.
The requesting government agency should first attempt to obtain the information directly from the customer or user(s) at issue.
Unless legally prohibited by law, Atlassian will notify customers of any government request targeting their data so that our customers have an opportunity to challenge the legal process, in accordance with our User Notice Policy.
In the unlikely event that Atlassian is required to comply with a government request, Atlassian will respond in accordance with applicable law (including the Stored Communications Act), and will respond as narrowly as possible to the specific request.
Atlassian will continue to advocate for reforms that allow us to provide more transparency to our customers.

Further questions and inquiries

While our security practices have provided a broad overview of our approach to security, given this is a complex area and Atlassian is doing a significant amount in this space, we haven’t been able to cover everything in detail here.

If you need more information, you can contact the Atlassian team via our support portal or ask a question in our Atlassian Trust and Security Community.

Want to dig deeper?

We’ve referred to quite a few other documents and resources on this page and we encourage you to dig into them if you want to understand more about our approach to security and trust.

Featured

Jira

Confluence

Jira Service Management

Trello

Rovo NEW

Jira Product Discovery NEW

Compass NEW

Guard NEW

Loom NEW

Developers

Jira

Bitbucket

Compass NEW

Product Managers

Jira

Confluence

Jira Product Discovery NEW

IT professionals

Jira Service Management

Guard NEW

Business Teams

Jira

Confluence

Trello

Loom NEW

Leadership Teams

Jira

Confluence

Loom NEW

Jira Align

Teams

Software

Marketing

IT

solution

By team size

By industry

Why Atlassian

Integrations

Customers

FedRAMP

Resilience

Platform

Trust center

Resources

Customer Support

Find Partners

Migration Program

University

support

learn

Jira

Jira Service Management

Confluence

Security practices

Our Approach to Security

Our security philosophy

Our team

Additional programs we use to support security

Continually improving our security program

More information

Securing our internal environment

Building security into our network architecture

Securing access to our networks through ZeroTrust

Managing access to our systems and services securely

Securing our endpoint devices

Security in our day-to-day operations

Keeping track of our information assets

Managing changes in our environment

Managing configurations in our systems

Making use of logs

Business continuity and disaster recovery management

Service availability

Backups

Physical security

Keeping data secure

Data centers

Encryption of data

Key management