Rate this page:
The Ecoscanner platform is a platform used for performing security checks 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.
On November 23, 2020, we open sourced a tool called Connect Security Requirements Tester aka CSRT. This tool is built specifically to scan for missing security requirements.
Starting April 1, 2021, we will be scanning Marketplace apps for a subset of the Security Requirements.
| Security requirement | Ecoscanner check | CVSS score | Details and remediation |
|---|---|---|---|
| 1a | 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 |
| 1b | HSTS must be enabled with a minimum age of at least one year. | 6.8 (Medium) | Transport Layer Security |
| 3 | For the domains where your app descriptor file is hosted and the domains specified (as the baseURL or other URLs) in the app descriptor file, TLS certificates of these domains must be valid | 8.1 (High) | Validity of Domain Registration & TLS Certificates |
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.
The Ecoscanner runs all above checks daily.
Valid findings will be ticketed and assigned to the app owner with corresponding SLAs attached. To find out more about our vulnerability management framework, see this page.
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
As and when we introduce additional scanners, we will follow up with a CDAC post and also update this page. We will treat open sourcing on a case by case basis.
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.
Rate this page: