Security Program for Atlassian Marketplace

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.

Yes. Data is stored within AWS S3 buckets. Controls are in place to limit access. Encryption at rest and on the wire is enabled. Public S3 access is disabled. Authentication and Authorization controls are set in place using the least privileged access model.

1b. Customer Data

If you have answered YES to above, what is the jurisdiction(s) of where this data is hosted?

The data is hosted in the AWS us-east-1 region.

2. Sensitive Data

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

Yes, it is designed to be able to store sensitive information, but none of this data is currently stored

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

Ariel Partners maintains an ISO27K compliant Security Policy with standards and procedures. It is documented in our website here (opens new window)

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

We store all source code and other source artifacts in a private GitHub repository. We use GitHub for managing our release planning and development workflow via GitHub projects, items, boards, and releases. All code changes are peer reviewed via the pull request process. All issues are reviewed prior to closing. We meet weekly to show a demonstration of new functionality and conduct planning next steps. We use GitHub Actions as our CI/CD pipeline. All builds and releases are performed automatically with no human intervention. The CI/CD pipeline runs automated tests and reports failures via email and Slack messages. We maintain two AWS cloud instances for our plugin: one for development and testing, and a separate instance for production. We use the built-in GitHub dependabot to detect and fix out of date dependencies. We use gosec, eslint, prettier, and semgrep for code linting and ZAP framework for OWASP top 20 vulnerability detection. Because our solution is serverless, we do not use containers, so we don’t need to use a tool like Anchore for container vulnerability scanning. We use Jest and the React Testing Library for React unit testing, golang testing for go backend unit testing, and playwright for end-to-end testing.

5. Audits

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

Ariel Partners undertakes regular audits and reviews to ensure security controls are being implemented. We have a regular annual audit to maintain our ISO 27001 compliance, we have monthly and quarterly reviews of user access privileges, and we conduct the AWS “Well Architected” review of our Jira app on a regular basis to address issues of security and scalability.

6. Accreditation

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

Ariel Partners is certified ISO 27001 compliant.

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?

We use Tenable Nessus to perform penetration tests and vulnerability scanning.

8. Notifying Atlassian

Do you have mechanisms to notify Atlassian in case of a security breach? An 'App Security Incident' ticket (https://ecosystem.atlassian.net/servicedesk/customer/portal/14/group/39/create/129) should be filed with us immediately upon your detection of a security incident.

Yes. In the unlikely event of a security breach involving Atlassian customer information, we notify Atlassian immediately by filing an App Security Incident ticket and by notifying our Atlassian partner points of contact.

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?

All access is controlled through OneLogin, the identity provider for Single Sign On. OneLogin provides access control and audit logs for ongoing monitoring. We do not provision any IAM users in our AWS regions. All access is provided solely through OneLogin with onetime users created and destroyed for every access.

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. All Ariel Partners employees and sub-contractors are required to sign NDA and CA as a condition of their employment.

11. Managing Security Vulnerabilities

Do you have a publicly documented process for managing security vulnerabilities in your application(s)? If Yes, please provide the URL; If No, please describe how you would handle a security vulnerability being identified in your code.

Our security tooling assessment will notify us of security vulnerabilities. We use the following tools: goSec, SemGrep, eslint, and ZAP scanner. If any of these tools finds an issue, our CI/CD pipeline fails the build, and automatically sends a notification via email and slack. A GitHub issue will be logged for a developer to pick up the issue with priority. The developer will fix the security vulnerability and push a fix to the development environment. CI/CD will run a security assessment to see if no vulnerabilities exist. The application will be tested and if the vulnerability is fixed, and the application works correctly, the version will be promoted to production.

12. Disaster Recovery

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

Data and compute are replicated to multiple availability zones within the same region to protect us from physical failures. In case of a data loss event, backups will be used to restore the data. We leverage AWS Backup for disaster recovery. Data is replicated from the us-east-1 region in AWS to the us-west-1 region. If the API or compute layer within the region would go down for a considerable time, we will be alerted, and the infrastructure can be activated in another region and the databases copied or recovered in a matter of a few hours.

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?

In case of Atlassian/Jira data, the data is only used in a read-only fashion. It’s stored within an immutable object storage service. If a data loss or failure would occur, the data can automatically be retrieved again using the Atlassian/Jira API endpoints. In the event of data corruption in our compute layer, we have mechanisms in place to validate the computational/query results. If a failure would occur, the problem would be automatically detected and remediated. In case of data loss of any metadata/plugin data of a customer, point in time recovery methods are available to retrieve data from an earlier time on a per customer basis. We can do this with per-second granularity, with a 35-day timeframe. Therefore, in the unlikely event that for example a customer inadvertently deleted all of their rules, we could recover them within 35 days. Changes made before this timeframe cannot be recovered.