Last updatedApr 1, 2019

Security guidelines and best practices for app vendors

Trust at Atlassian

We recommend that you first visit the Atlassian Trust site where we describe Atlassian's core pillars of security, reliability, privacy and compliance. We aim to be as transparent as possible by publishing details of our security practices whether that's information about our bug bounty, how we deal with security incidents, and more.

Currently the security guidelines are not mandatory, and Marketplace vendors aren't required to comply with them. We are providing these guidelines as a resource to help you improve your security profile. We also wish to communicate some of the feedback we get from our Marketplace app users.

We will give you a minimum of 30 days' notice for changes to the security guidelines or if they become mandatory in part or whole. It isn't our intention to place onerous security burdens on app vendors or create any surprises. Rather, our goal is to partner with you to create a high level of trust and security in the Marketplace for our users.

Vendor risk and security audits

When installing Marketplace apps many companies will be concerned about the extra risk they are taking on by using a new application or vendor. We have put these guidelines together to help you prepare for some of the more stringent security and risk checks that some customers might have as a part of their procurement process. This is especially prevalent in organizations that have subscribed to a certification such as ISO 27001 as vendor risk reviews are a core principle of that certification.

Plugins2 (P2) framework for server-based apps

Apps built on the Plugins2 (P2) framework are JAR files that you upload and are hosted on the Atlassian Marketplace. These files are then downloaded by customers and installed in their Atlassian server instances, including Jira Server, Confluence Server and other server-based products.

P2 security pros

  • Most server instances tend to be hosted behind a firewall, therefore limiting access to the outside world.
  • Security conscious customers can decompile your code to see information about what it does. They could potentially also monitor the traffic going both to and from the host to see what connections your app makes.
  • Customers can enact change management and decide for themselves when they want to upgrade to the latest versions of your apps.

P2 security cons

  • There are no permissions system in P2, and as such, your app will have full access to the host as any software installed would have.
  • If you find a vulnerability in your P2 app then you will need to manually release a new version and notify customers to update. Unlike cloud apps built on the Connect framework, it's not an automated process.
  • Not every customer hosts their server instance behind a firewall.

P2 app updates and importance of customer communications

On server instances, app updates must be performed manually by the customer. If vulnerabilities have been found and you have released a fix version, it is important to notify your customers that the new version needs to be installed. You should not disclose specifics about the vulnerability until you have given ample time for customers to download the new version (if you decide to disclose specifics at all).

Connect framework for cloud-based apps

Apps built for our cloud products utilize the Connect framework. Connect apps (cloud) are very different than P2 apps (server). Your Connect app interacts with the Atlassian cloud instance using only API requests and webhooks (event-based APIs).

Connect security pros

  • Using scopes, you can limit the access your app has to the customer instance. For example, your app can abstain from having administrative API rights and limit itself to just what it needs to operate.
  • If you find a vulnerability in your Connect app you can push an update to all customers automatically.

Connect security cons

  • Your cloud-based app introduces infrastructure to worry about, with additional attack vectors
  • Areas of concern include:
  • dealing with cloud infrastructure such as AWS, Azure, or Google Cloud Platform
  • hardening servers which run your application
  • leveraging additional technologies such as Docker or Kubernetes
  • logging information and alerting on logs

Security checklist

The list below is by no means a list of requirements, but rather, a list of recommended steps to take when building apps on the Atlassian platform. These are lightweight, easy-to-complete tasks that will significantly increase the security posture both in your company and in the apps you create.

Workstation and account security

Workstation and account security is the first thing you should look at before you even start building apps. Workstation and account compromise are some of the bigger threats of today as a malicious actor could use this to get access to your code repositories, your infrastructure, or your workstation directly. From a compromised workstation or account, bad actors could easily access your customers data, modify your codebase, or use this as a foothold to get access to your other services.

  • Encrypt all workstations.
  • Implement a patch management process to keep operating system and software up to date.
  • Use a reputable password manager such as LastPass or 1Password, choosing long, unique passwords on every site you visit.
  • Enforce multi-factor authentication across key accounts such as password managers, email, file sharing services and SaaS tools.
  • If you can't use MFA then always use a password manager (perfect for bot accounts, services which don't support 2FA and other edge cases).
  • Know the dangers of phishing and how to spot potential phishing emails.
  • Make sure you either have your operating system anti-virus .feature turned on or install a third-party anti-virus tool from a reputable vendor.
  • Enable the host based firewall.

Infrastructure security

Most vendors creating Marketplace apps for our cloud products use platforms such as AWS, Azure, or Google Cloud Platform. These services should be protected much in the same way workstations are but some extra steps are required due to the fact these servers are internet-facing and running your app. If a malicious actor was to gain access to the cloud account or the infrastructure itself then it could give them access to the customer data you store or to your application itself.

  • Follow recommended security steps set by your cloud provider when creating a new account.
  • Enforce multi-factor authentication across all accounts.
  • Disable unnecessary services on servers in order to reduce the attack surface.
  • Patch operating system and software.
  • Implement a patch management system to keep operating system and software up to date.
  • Encrypt data at rest (AES256 or equivalent is recommended).
  • When backing up data be sure to apply the same security controls to protect backups as you do with your databases.
  • Log information that can potentially make you aware of security breaches. Prime examples of information you should log include:
  • Pull requests that are being merged without approval.
  • 2FA devices being added/removed from your account.
  • Administrative actions such as creating or modifying existing users.
  • New instances being created.
  • User logins, especially admin users. If they are coming from strange user agent strings or IP addresses in countries you don't go. You can use these and a number of others as potential indicators of compromise on your accounts.
  • Do not log sensitive data! Watch out and make sure you don't log API tokens, passwords, or excessive personal information.
  • Review the logs, setting aside time to review them at regular intervals. An even better approach is to automate this process and trigger alerts if certain conditions are found.


Developing secure code is one of the more difficult things to do in this list. Keeping on top of application security is a constant endeavor with new vulnerabilities being found every day. Thankfully there are tools and techniques to help you keep up these changes, and the core principles of remediating these issues do not often change.

  • Enforce multi-factor authentication across all of your source code repositories. Source code management systems like Bitbucket and Github make this easy to do.
  • Understand Atlassian scopes when building Connect apps. Try to keep your scopes as lean as possible, leaving out permissions that your app doesn't need.
  • Use a dependency scanner such as OWASP Dependency-Check, SourceClear, or Snyk to find security issues in third-party libraries you are using in your code.
  • Look into creating a bug bounty program. At Atlassian we use Bugcrowd for managing our bug bounty program. This security testing program enables third-party security researchers to report vulnerabilities in our tools and earn money doing so. Read more about Atlassian's approach to external security testing.
  • Encrypt data in transit (try to support the latest TLS, and deprecate older, more vulnerable versions).
  • Encrypt all API tokens stored at rest, such as OAuth access and refresh tokens.
  • Do not hard-code API keys or credentials into your app.
  • Securely hash any passwords with a unique, random salt.
  • Carefully review the OWASP Top 10 and look out for these security risks when creating apps.

Policy, processes and documentation

Standards are available so your customers know what you do and how you do it. The two most critical policies we recommend that you have are a privacy policy and a security policy. Without these two you will likely struggle to secure larger, more risk averse customers as their procurement teams look for these sorts of documents as they evaluate new tools and vendors. Below is a list policies, processes, and documentation that you should consider implementing as your grow your business.

Must have:

  • Privacy policy
  • Security policy
  • End user license agreement (EULA)
  • Groom security champions. One or more members of your team should dedicate time to both learning about security and implementing good security practices in your organization. Without an owner to drive security you can find that security practices fall behind, resulting in technical debt down the line.
  • Create a company password policy. We recommend using the identity guidelines from NIST 800-63B. Auth0 published a simplified writeup of 800-63B making it easy to understand and implement.
  • Create an incident response plan to know what to do in the case of a security incident.
  • Create disaster recovery and businesses continuity plans to know what to do when things go south.
  • Implement change management procedures to insure changes have an approval process and provide audit trails.


Once you have a good grip on security controls and documentation you may want to look into going through a security audit. Audits are conducted by a third-party and upon completion you will receive an audit report which will give insight on areas you're doing well in, and more importantly, on areas that need improvement. These reports may be shared with prospective customers during their procurement process, providing them with insights into your company as they evaluate your security controls. There are many certifications available, including some that are country specific. We recommend that you investigate the two globally recognized certifications listed below:

  • SOC2 - useful certification that is completed by most cloud-based companies.
  • ISO 27001 - a great certification to aim for but most companies tend to start with SOC2 due to the increased scope and complexity.