Rate this page:
Maintaining a secure Marketplace is a collective effort, shared by Atlassian and partners. Atlassian's Security Requirements for Cloud Apps reflect the most current best practices for building secure apps and provide platform-specific guidance. They set Atlassian's baseline standard for cloud app security, and are updated annually to ensure alignment with industry standards. This page outlines how Atlassian validates that apps are following security requirements via scanning.
The Ecoscanner platform is a platform used for performing security scanning against all Marketplace cloud apps on an ongoing basis. This will help us continuously monitor our Marketplace cloud apps for common security vulnerabilities and improve the overall security posture of our ecosystem.
In order to validate that apps are meeting security requirements, we continuously launch new security scanners to expand requirements coverage. Below are some of the security requirement checks that Ecoscanner platform performs as of today.
| Security requirement | Ecoscanner check | CVSS score | Details and remediation |
|---|---|---|---|
| Connect 1.1 | An application must always use JWT as the authentication type to validate the application identity and the integrity of the request. | 5.3 (Medium) | Authentication of Application Resources |
| Connect 1.2 | A JWT token must be validated on the server-side for every authenticated request. Validate all user permissions to ensure that only permitted users can execute actions within an application. | 8.8 (High) | Authorization of Application Resources |
| Connect 1.4 | An application must always validate install/uninstall lifecycle requests. | 8.6 (High) | Signed Install Authentication |
| Connect 3 | The application must use TLS to encrypt all of its traffic and TLS version 1.2 (or higher) are required. | 7.4 (High) | Transport Layer Security |
| Connect 3 | HSTS must be enabled with a minimum age of at least one year. | 6.8 (Medium) | Transport Layer Security |
| Connect 5.1 | An application must never store secrets or authorization information in Jira Entity properties / Confluence Entity Properties. | 7.5 (High) | Insecure Storage of Secrets |
| Connect 6.1 | An application must maintain control of each domain. | 9.0 (Critical) | Domain Security |
| Connect 6.2 | An application owner must maintain valid TLS certificates of the domains where an application is hosted, and the domain must be signed by a trusted Certificate Authority | 8.1 (High) | Validity of Domain Registration & TLS Certificates |
| Connect 6.3 | An application’s DNS configuration for subdomains must reference services that are in use. | 9.0 (Critical) | Subdomain Security |
| Connect 8.0 | An application must validate and sanitize all untrusted data and treat all user input as unsafe to mitigate injection-related vulnerabilities. Untrusted data is any input that can be manipulated to contain a web attack payload. | 7.1 (High) | Input Validation (Cross-Site Scripting) |
| Forge 1 | An application must authenticate and authorize every request on all endpoints exposed. | 8.8 (High) | Authentication and Authorization |
| Forge 5 | An application must securely store and manage secrets, which include OAuth tokens, Trello tokens, sharedSecret, API keys, and encryption keys. They cannot be stored in places that are easily accessible. | 7.2 (High) | Secure Handling of Secrets |
| Forge 9 | An application must not use versions of third-party libraries and dependencies with known critical or high vulnerabilities. When vulnerabilities in these libraries and dependencies are discovered, an application owner must remediate them as quickly as possible. | High / Critical *This depends on the specific vulnerability | Open Source Security |
We open sourced a handful of security requirement testing tools namingly,
These tools are built specifically to scan for missing security requirements on Connect and Forge apps respectively.
We scan and ticket Marketplace apps developed on Connect using CSRT, Forge apps using FSRT and CVS tools. While our goal is to validate each security requirement for every app, we currently scan for a subset of the security requirements due to the fact that not all security requirements can be scanned with 100% confidence.
We also use other internal scanners to validate security requirements apart from CSRT, CVS and FSRT tools. Below are those scans that we perform using internal only tools.
Marketplace apps with a registered domain that is expired can be re-registered by a malicious user and then used to exfiltrate sensitive information from any tenant where the vulnerable app is installed.
We check the app baseUrl for domains that appear to be available for registration. For apps with expired domains, a security vulnerability ticket will be raised with the severity of Critical (9.0).
Domains for any app installed on a customer tenant must be owned and controlled by the developer of the app. Apps that are no longer maintained must be uninstalled from all customer instances.
Connect apps with an unclaimed subdomain can be taken over by a malicious user and then used to exfiltrate sensitive information from any tenant where the vulnerable app is installed.
For example, a Connect app’s baseUrl was vulnerable-app-name.herokuapp.com or was CNAMEd to vulnerable-app-name.herokuapp.com, and the app developers have not claimed that subdomain on heroku. An attacker can then create an app on heroku named vulnerable-app-name, and receive traffic that was meant for the vulnerable Connect app.
We take in a list of connect apps with their remote descriptor urls and check if their remote descriptor url and/or baseUrl are vulnerable to subdomain takeover. We use this repo with some additonal validation to check which subdomains we can take over. For apps that are vulnerable to subdomain takeover, a security vulnerability ticket will be raised with the severity of Critical (9.0).
Domains for any app installed on a customer tenant must be owned and controlled by the developer of the app. Apps that are no longer maintained must be uninstalled from all customer instances.
Hardcoding secrets in source code can cause secrets to be leaked and also lead to malicious activities like account compromise and user impersonation attacks. Secrets must be stored and retrieved securely.
We use our internal secret scanning solution built using open source secret detectors like trufflehog. Additinally, we validate detected secrets to avoid false positives. If a valid secret is found in Forge app source code, a security vulnerability ticket will be raised with the severity of High (7.2). Note: we will increase the severity accordingly incase secret is found to be publicly available.
Either manually audit your source code or consider implementing tools like trufflehog, git-secrets or similar tools in your development environment to prevent sensitive tokens being committed.
Open source is powerful, and almost all developers in the world rely on open source libraries for their applications. But it's time to stop ignoring the security risks from these libraries now that recent past had many zero day vulnerabilities that arose from third party software. Libraries/dependencies with known critical or high severity vulnerabilities must be patched or upgraded as soon as possible to mitigate the imminent threat posed to customer data.
We use Snyk tool to scan for vulnerabilities in open source libraries used by the app. Security vulnerability tickets will be raised for all critical and high sverity findings. Note: We use Snyk Priority Scoring model for scoring vulnerabilities identified by the tool.
We recommend that you use the latest stable version of any library to minimize the risk of exploitation and immediately patch libraries when zero-day vulnerabilities are disclosed. Use scanners, such as Snyk or OWASP dependency check to detect vulnerable or deprecated components used in your application environment.
The Ecoscanner runs all Connect related checks daily and all Forge related checks when a new version of the app is released. Since XSS-Check scanner is long running scan, we run it monthly.
Apps that miss security requirements will receive AMS tickets that are subject to our timeframes for resolution outlined in our Security Bug Fix Policy.
All scanning activity originating from Ecoscanner is supposed to be non-intrusive and very basic so Atlassian will continue to scan the production environment of cloud apps for now. If this changes in the future, we will communicate accordingly.
All scan traffic should originate from the below listed IPs and IP Ranges:
1 2100.25.61.160 3.214.98.112 35.172.132.4 3.221.51.2 3.217.215.43 35.174.235.12 34.211.197.111/32 50.112.197.134/32 52.42.55.113/32 54.68.221.42/32
Generally speaking, the more links in your descriptor, the more traffic you will receive. The traffic is very “bursty”. But, some approximate numbers are below:
Initial validation – Max 2 requests
Descriptor scan – Max 6 requests per link
TLS scan – No noticeable traffic at the app-level
XSS Scanner – Unlike other non-intrusive scanners in our tool suite, Cross-Site Scripting scanner tries to fuzz the form parameters in the HTML Iframe of the app. Fuzzing can generate considerable amout of traffic and you might notice random XSS payloads in your application logs.
As and when we introduce additional scanners, we will follow up with a CDAC post and also update this page. It is important to note that we cannot open source each scanner that we use for Marketplace apps since we license some scanners ourselves; but we will open source everything that we can. We will treat open sourcing on a case by case basis.
Currently Forge scanners will automatically scan the latest version of each Forge app and validate security fixes on the latest available version.
Yes, absolutely. We would totally love this. You come up with scanners and let us deal with figuring out how to run them at scale against all apps. Please feel free to create a request in our service desk describing the scanner and instructions on how to run it.
We will keep the scanner sections above updated with their scanning cadence
All vulnerabilities identified from the scans will be reported via the AMS project in ecosystem.atlassian.net.
As of now, we are not planning to scan server and DC apps. This might change in the future as the Ecoscanner platform becomes more mature.
Apps CANNOT opt out of scanning at this time.
We hope this never happens since the scanning is going to be non-intrusive (unless otherwise mentioned). In the odd case when it does end up breaking your app and you want us to look into it, please go ahead and create a request on our service desk.
We understand it is not practically possible to scan for all the requirements (because of the subjective nature of them that is different for different apps) but there are a handful of requirements that we can scan for. We are currently scanning these and reporting valid vulnerabilities identified via the AMS project. However, Atlassian is performing security tests to expand our coverage and validation of the security requirements by testing for requirements and common vulnerabilities that we currently do not scan for.
Rate this page: