Ecoscanner

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.

What type of scans will the Ecoscanner Platform run?

Missing Security Requirements

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

Expired domains

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.

How we scan for expired domains

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

Mitigation

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.

Subdomain takeovers

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.

How we scan for subdomain takeovers

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

Mitigation

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.

Scan Cadence

The Ecoscanner runs all above checks daily.

Ticketing

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.

FAQ

Can we have the Ecoscanner scan only our staging environment?

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.

How do we know if the scan traffic is coming from Atlassian and not from some adversary?

All scan traffic should originate from the below listed IPs and IP Ranges:

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

What would the scanning be like? How intrusive? Requests/sec? What kind of requests should we expect to see?

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

Apart from the CSRT scanner, what other types of scanning will happen? Will they be announced and open sourced like CSRT?

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.

Can we build our own scanner and ask Atlassian to run it for us and for other Marketplace apps?

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.

What will be the cadence of the scanning? What time/time zone will the scanning occur?

We will keep the scanner sections above updated with their scanning cadence

How will we get notified about the scan results?

All vulnerabilities identified from the scans will be reported via the AMS project in ecosystem.atlassian.net.

Will server/DC apps also get scanned?

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.

Can apps opt out of scanning?

Apps CANNOT opt out of scanning at this time.

How do we get in touch or contact Atlassian if the scanning somehow breaks the app? How do I get support wrt the scanning?

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.

Why are we not scanning all the security requirements? Out of all the security requirements that will be scanned, which ones will be reported as security vulnerabilities?

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.