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
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
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
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 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
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.
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
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
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
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.
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 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.