Please help us shape the "Runs on Atlassian" roadmap for 2026 and beyond

[scott.dudley]

@SeanBourke

Flexible Implementation vs Abuse - CME has been developed in a way which enables apps to control egress is exposed and managed within their app. This was a conscious decision, as we understood that the use cases were diverse and having to defer to Connected Apps to manage egress would be a disruptive and sub-optimal customer experience. This came with a trade-off, which is that any incentive to adopt CME to attain a badge could be abused - an app could immediately ask for egress and not function without it.

Hi Sean,

I appreciate your candour here. Similar to @marc’s comment, I believe that Atlassian figured out how to work around most of these perception problems of “the app does not egress data at all” when dealing with analytics, while still allowing those analytics-sending apps to receive the RoA badge.

Is there any similar sort of mitigation that could be figured out here?

For example, if I declare analytics egress, I can trivially send unlimited amounts of arbitrary data up to Sentry (or whatever), and then download it from outside the customer perimeter. I can also stop the app from working if the admin has disabled analytics egress.

I believe the current primary differentiator between the two features is the ability for admins to disable analytics egress at a site or organization level. Those who do not want any of this egress will clearly turn it off.

Could something similar be considered here, like adding an org-level flag to allow admins to prohibit CME egress unless the requested domain falls on a list of org-level or site-level approved CME domains, and users/apps can only request CME to a domain that an org admin has already previously allowlisted? (When creating this flag, you could look at all sites/orgs that already have analytics disabled and decide to default the CME egress flag to “allowlist only” as well.)

For the malicious behaviour aspect, I also wonder if CME abuse could be simply treated the same way that Atlassian does for RoA apps that abuse analytics (drastic action taken when uncovered by Atlassian). Given that the CME target domain always has to be manually approved by the customer in some form, it seems that the potential for abuse is actually far worse with analytics.

I agree that other security factors beyond RoA can come into play when making customer decisions. I also fear that when the Marketplace makes it really easy to prioritize searches for RoA, despite any potential nuances in a vendor listing, many customers will become RoA-or-nothing, and those who do not have the badge (regardless of why) will be left outside the fold.