Marketplace applications permissions, data integrity and security concerns

Question

Hi,

we are planning to use a number of the Marketplace applications and I found that most of the applications require full View & Edit & Delete & Admin access to the whole subscription data.

There are several issues with this and I'm asking to understand how Atlassian customers deal with the following:

1. Data preservation.
Jira Software does not have a concept of a recycle bin. Delete operation destroys the data immediately and for good. Everybody seem to have a workaround by denying users 'delete' operation and replacing it with the new 'recycle bin' state. That is bearable. Until we connect a marketplace application that demands 'delete' permission. Now we are at a mercy of the 3rd-party developers, hoping they do not introduce a bug that would accidentally wipe out the data from our subscription.

2. Access limits. 
We take care to carefully set up the access per user group so that people see what they need to and nothing more. And then we need to give the full access to all the data to some external application, with which we are supposed to conduct a separate business, validate their EULA is ok with our business requirements etc.

3. Admin audit.
There are limits on what is written in the audit log of the Jira Software. Namely, not all administrative operations on user access are marked with the specific administrator name. There is even Jira issue on this, exists for several years.
How do we monitor the admin activity by these marketplace applications on our subscription?

4. Applications security.
The most popular test management marketplace application does not have its security self-assessment complete. What do you do in this case? Are we supposed to trust the vendor that does not do even self-assessment? They have tens of thousands of downloads. Is this ok with everyone or people just do not care or what?

5. Marketplace applications vulnerability mitigation and remediation.
This is described in Security Bug Fix Policy For Marketplace Apps.
"Cloud apps are expected to fix critical vulnerabilities within 4 weeks of being reported or triaged."

This does not comply with the BINDING OPERATIONAL DIRECTIVE 19-02 - VULNERABILITY REMEDIATION REQUIREMENTS FOR INTERNET-ACCESSIBLE SYSTEMS https://www.cisa.gov/binding-operational-directive-19-02 which allows 15 days for remediation of the critical severity vulnerabilities

How does this work for compliance sensitive customers?

6. Data residency.
Data stored and operated by the Marketplace Applications is not pined to specific location.
https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/

Given we the Marketplace Applications require full access to the all the data in our subscription, it follows that the none of the data is guaranteed not to leave the customer designated location.

What am I missing here?

The above issues are of a concern for me and I welcome thoughts and clarifications from the customers and the Atlassian producers.

Thank you!

Oliver Siebenmarck {Polymetis Apps} · Answer

Hi @Inna S ,

Glad if I could help. Working for customers from all over the globe can be challenging from a compliance perspective – I can very much relate.

I don't think the community supports DM, but you can always reach me at siebenmarck (at) polymetis-apps.com

Best regards,

Oliver

Inna S · Answer

Thank you, @Oliver Siebenmarck _Polymetis Apps_ !

Your elaborate answer provides a very valuable vendor perspective that is great.

I'm new to the Jira world and so consuming tons of information now.

Disclaimer: I am not a lawyer. But I do touch the compliance where it talks about vulnerabilities and related things.

We are Israeli company, with sites in US, Europe and Asia. And our customers are about everywhere but Antarctica. Some of them ask questions about our production process, where RnD work is a significant part. Others require periodic 'reports' on how we do things etc.

Now, with the recent US presidential executive order re security of the software supply chain, the awareness started to trickle down. So I believe even companies that do not work for the US government will eventually find themselves part of the supply chain of those who do, and thus having to care about compliance.

And I do not even want to start about GDPR. Suffice is to say that if one of our employees holds EU passport and has her profile picture in Jira, to be compliant, we as a company seem to be obligated to protect their privacy by ensuring this picture does not end in the AWS data center in unexpected location.

I do not know if you can send a DM here, let me know if you want to talk.

Oliver Siebenmarck {Polymetis Apps} · Answer

Hi @Inna S ,

Your question touches a few areas that I often think about, so let me add a bit to what @marc -Collabello--Phase Locked-  already wrote. Please note though, that I'm writing this from an app vendor perspective – to definitely answer your questions, I believe someone from Atlassian would need to chip in.

First of all, not all Marketplace apps for Jira Cloud have the same technical basis; there's actually two frameworks: Connect and Forge. Connect was the first integration framework and allows for a lot more features than Forge.

The Forge platform has only been around for less than three years and still lags behind feature-wise – basically you cannot build everything you can build with Connect.

However, Forge apps run on Atlassian infrastructure and can be build so that the app vendor has no access to any of the instance's data. This can have huge implications on trust, but does not necessarily makes Forge apps more secure than their Connect counterparts.

> 1. Data preservation.

You are right, there is no user-managed backup in Jira. There is an app (Revyz), but that's a) still in the making and b) yet another party to trust.

Also, you can do manually create backups as outlined here:

https://support.atlassian.com/jira-cloud-administration/docs/export-issues/

I know a few companies who do this, but it's not the same as a recycle bin – and recovery is usually a pain. I do not know anyone who does partial recovery using this process.

> 2. Access limits.

Application permissions and scopes are a huge topic for app vendors, too. While I cannot speak for the whole vendor community, we at Polymetis Apps generally limit the scopes we request as much as possible. However, that is not always as simple – the (still) de facto standard Connect has eight scopes – for example we cannot request ADMIN scopes without implicitly getting DELETE permissions.

With Forge, there are two kinds of scopes classic and granular. ) Granular scopes are very granular, but the current recommendation by Atlassian is, that apps use classic scopes.

That being said, if an app is Forge-based it can be set up to not egress any data, ie the app could read all the data, but could not send it to anywhere outside of your Jira Cloud instance. Unfortunately, unless a vendor tells you upfront about this, you'll only find out about the egress settings of an app when you install it and run it.

> 4. Applications security.

Indeed, the general impression so far was too many people do not seem to care too much about the self-assessment or other trust signals (like Cloud Fortified). While I personally believe that these will become more and more important, if a vendor has not gotten many questions about not completing the self-assessment, I can understand why they would not prioritize it. I would recommend to reach out to them and let them know that you do in fact care about this.

> 5. Marketplace applications vulnerability mitigation and remediation.

Not every app vendor is aware of CISA, quite a few are not located in the US. That being said, each vendor can have their own policy with different, stricter policies. The Atlassian policy you linked to is the bare minimum a vendor must adhere to.

> 6. Data residency.

Frankly, yes that is how it works typically. Once you install an app with READ permissions, that app can potentially read all the data on your instance. However, with Connect apps, vendors can also offer data residency, meaning they can run their app in different geographies and store data according to your preferences/location. Unfortunately, that is not a standardized process, so you will have to talk to each individual vendor on what data is stored where and how. Some, like Adaptavist, have that info available on their website.

With Forge apps, there currently is no guaranteed data residency, although that is on Atlassian's roadmap.

Anyway, I hope that helps understanding the ecosystem a bit better, even though I don't think I could alleviate all of your concerns. If you are willing to discuss this further, I am always interested in learning more about compliance sensitive organizations and their needs.

Best regards,

Oliver from Polymetis Apps