Close

Security in software development at Atlassian


At Atlassian, security is integrated into every phase of the development lifecycle to ensure that our code, products, and customers remain protected. We perform secure development practices across all the phases of the development life cycle. 

  • Development is supported by application security training programs and a security knowledge base maintained by the security team. 
  • At the design phase, practices include threat modeling, design review, and our regularly updated library of security standards, which ensures that the appropriate security requirements are considered. 
  • During development, we rely on a mandatory peer review process as the first line of security review. This is supported by automated static analysis checks (SAST) and manual security testing (both by internal teams and third-party experts as determined by our risk assessment process).
  • Formal operational readiness and change control processes then ensure that only approved changes are deployed to production. Post-deployment, we employ regular automated vulnerability scanning and an industry-leading bug bounty program to provide continuous assurance of our applications. We continuously measure our products' security posture over time with a security scorecard system.
Jersey

Culture

Engagement

Training

Standards

Clipboard list

Practices

Checkpoints

Security review

Security improvement

Building a culture of security

Atlassian builds a culture of security by empowering our teams through our robust security training.

Developer security training

We use both in-house developed content and third-party content for training to ensure our development teams have the necessary security knowledge to build secure applications. Our training program is continuously monitored to ensure program health and evolves to meet the changing threat landscape.

Design phase

At the design phase we use threat modeling, design review, and our library of security standards to ensure that appropriate security requirements are considered. 

Threat modeling

We use threat modeling to better understand security risks when projects face complex threats or change security-critical features. This involves a brainstorming session between our engineers, security engineers, architects, and product managers to identify and prioritize 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.

Our threat modeling includes:

  • Applying a risk-based approach to determine the need to perform threat modeling
  • A mature process for conducting threat modeling, including supporting materials and tooling
  • Training videos and reading material to assist software teams to conduct threat modeling

Development phase

Throughout the development process, we employ a number of security processes and practices to ensure that our code remains secure. 

Security review

The security team runs a security review process to provide security assurance across all software projects at Atlassian. A risk-assessment process is used to prioritize where to focus security review and identify what activities are required to mitigate project risk. Depending on the identified level of risk, assurance activities include a combination of:

  • Design review and threat modeling
  • Code review and security testing
  • Independent assurance using expert third-party researchers and consultants

Peer review

During development, all code is subject to our peer review green build (PRGB) testing process. This process requires multiple senior or lead developers to review all commits before they are pushed on production. This is further supported by automated static analysis checks (SAST) and manual security testing (both by internal teams and third-party experts as determined by our risk assessment process). Development is also supported by application security training programs and a security knowledge-base maintained by the security team. 

Separation of environments

We maintain logical and physical separation of production and non-production (development) environments for all of our critical services. Our staging environment is logically separated - but not physically separated - and is managed under production-grade change control and access processes.

Atlassian also has security policies prohibiting the use of production data in non-production environments. We maintain guidelines on how to either strip or protect restricted data - including personal data - using anonymization, hashing, and tokenization techniques.

Maintenance phase

Before we push code to production, it must pass our formal operational readiness and change control processes.

Once a system is deployed we run automated vulnerability scans regularly. As we discuss in our security practices, we have an industry-leading bug bounty program which provides ongoing continuous security assurance for our systems using a trusted, crowd-sourced group of security researchers.

Security scorecards

We’ve created an automated accountability and monitoring system known as product security scorecards, which are used to measure the security posture of all products at Atlassian. We use a broad range of security-focused criteria, such as current vulnerabilities, training coverage, and recent security incidents, to provide an overall daily security score for each of our products.

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