These are our current responses to the Atlassian Marketplace Security Self-Assessment shared with Atlassian.

Please also see our more elaborate security assessment here.

1a. Customer Data

Do you store customer data from the customer Atlassian instance? If so, please outline any protection mechanisms you will have in place to protect this customer data.

Only configuration data is stored permanently as outlined in our privacy policy. Access is only possible through AWS authentication, all users with access are required to use 2-factor authentication. Backups are taken every 6 hours. More details can be found in our security assessment.

1b. Customer Data (optional)

If you have answered Yes to Question Number 1a, what is the jurisdiction(s) of where this data is hosted?

Amazon Web Services, us-east-1 (Virginia, USA) and eu-central-1 (Frankfurt, Germany) regions, depending on the data residency used, see our documentation for more details.

2. Sensitive Data

Is your application designed to store sensitive information? (For example: Credit card data, Personally Identifiable Information, Financial data, Source code, Trading algorithms or proprietary models)

No.

3. Security Policy

Do you have an Information Security Policy with supporting Standards and Procedures? Please provide details (or provide a copy of the policy).

Yes. Security guidelines are documented and all employees and partners are obliged to adhere to them. See our security assessment for more details.

4. Release Management

Do you have formal change control and release management processes to manage code changes? Please provide details (or provide a copy of the documented process).

Yes. Any changes are planned and documented within our internal Jira. Code is committed to a git repository in Atlassian Bitbucket. All releases are uploaded to AWS, where all released versions are persisted and rollback to previous versions is easily possible. All changes are first rolled out to an internal staging environment, where changes can be tested before they are rolled out to our live environments in the different regions.

5. Audits

Do you undertake audits or other reviews to ensure that security controls are being implemented and operating effectively?

Yes. Our automated dependency check for both frontend and backend libraries is running before any deployment to production and will prevent any known vulnerability in our dependencies with an OWASP CVSS score greater than or equal to 7 to be deployed to production. We also do regular peer-reviews of code and infrastructure within our development team to ensure high code quality and security awareness. We’re also enrolled in the Atlassian Marketplace security bug bounty program, where our apps are exposed to security researchers who receive rewards for reporting exploitable vulnerabilities.

6. Accreditation

Are you accredited to any relevant security standards (e.g., SSAE16 SOC1/2/3, ISO27001, PCI DSS)?

Not yet. We plan to complete a SOC2 certification by the end of 2023.

7. Penetration Testing

Do you undertake penetration testing (or similar technical security testing, code review or vulnerability assessment); and are you able to provide copies of results/findings?

Yes. All code commits are peer-reviewed before a release. We’re also enrolled in the Atlassian Marketplace security bug bounty program, where our apps are exposed to security researchers who receive rewards for reporting exploitable vulnerabilities. Our latest penetration test report can be downloaded on the "Security and privacy" page of our documentation where we also share the security vulnerabilities that were found in the past.

8. Notifying Atlassian

Do you have mechanisms to notify Atlassian in case of a security breach? An App Security Incident ticket should be filed with us immediately upon your detection of a security incident. You must stay available to communicate with our security team during resolution and inform our team via the ticket when the incident is resolved. While you are responsible for informing your affected customers as necessary, your communication with us helps us direct customers who have reached out to Atlassian for help. It also informs us in case we need to take necessary action to prevent additional breaches.

Yes. Our servers are permanently monitored for irregular behavior such as load spikes or unusual amount of errors and warnings. At least one engineer is "on call", being notified if a potential security breach is occurring. If one is detected, Atlassian is to be notified through the "App Security Incident" ticket and more colleagues are notified to help resolve and communicate the incident as quickly as possible.

9. Employee Access

Do your employees (e.g., developers or system administrators) have access to Atlassian customer data? How is this access controlled and monitored?

Only engineers "on call" are allowed access to our production systems. They only have access using 2-factor authentication. No customer data is stored outside of our production systems.

10. Confidentiality

Are all personnel required to sign Non-Disclosure Agreement (NDA) or Confidentiality Agreements (CA) as a condition of employment to protect customer information?

Yes, as part of their contract of employment.

11. Managing Security Vulnerabilities

Do you have a publicly documented process for managing security vulnerabilities in your application(s)?

Yes. For Cloud apps, a security vulnerability should be fixed within 2 weeks of being reported. Since a new cloud version is automatically rolled-out within 10 hours by Atlassian, there's no need to support multiple versions except for the brief transition period. We publicly document the fix duration for past vulnerabilities in our documentation.
For Server and Data Center apps, a security vulnerability should be fixed within 2 weeks of being reported. All previous versions of the app containing the security vulnerability are changed to "private", so they are no longer installable by customers.

12. Disaster Recovery

Do you have Business Continuity and/or Disaster Recovery Plans? If Yes, please provide details including backup and redundancy mechanisms.

Yes. All server infrastructure is redundant within the respective regions of Amazon Web Services. Backups of DynamoDB databases are taken every 6 hours to AWS S3. In the worst-case scenario of a whole AWS region being unavailable, we would recover the DynamoDB databases in another AWS region and boot up a new ECS cluster within 24 hours, pointing the DNS entries to the new AWS region. All other outages (e.g. availability zone outage in AWS) are handled automatically by the auto-scaling and failover handling mechanisms of AWS. See also our security assessment for more specific details.

13. Data Recovery

Do you have capability to recover data for a specific customer in the case of a failure or data loss? Please outline your processes and recovery capabilities for data loss including time frames. What is the maximum data loss period a customer can expect?

Yes, backups are taken every 6 hours which is the maximum data loss period a customer can expect. Backups are stored redundantly in different AWS S3 regions. Alarms would notify us if those would stop functioning. Recovery scripts are in place to quickly recover data for a single customer or all customers.