Your current Jira apps are possibly transferring data to third parties

Security and data protection are essential for cloud software. Companies need to know what happens with their data – and this concerns not only core systems like Jira itself but also all apps being used.

But how can you be sure that your Jira apps aren’t transferring data to external servers somewhere in the world? Not only your team but also your IT department, compliance officers, and data protection officers are interested in the answer to this question. It significantly depends on which platform and with which technology an app was developed.

Atlassian Connect: The old model with risks

Atlassian Connect is the classic development platform for Jira apps. Connect apps are so-called “remote apps” that are hosted on servers outside the Atlassian cloud. The apps communicate with Atlassian products via REST APIs and webhooks and use OAuth for authentication.

Why is this problematic?

• External servers beyond your control: Connect apps run in the infrastructure of the respective app provider – often in different regions or even in multiple clouds.
• Data transfer to third-party servers: Usually, lots of information is transferred to external servers, including personal data of employee that may fall under GDPR. In many cases even US companies need to have a DPA with Atlassian Marketplace vendors. Hardly any customer cares today. But they run a severe risk. And the leakage can come from within. A frustrated employee could drag you into a nasty court case.
• Individual security policies: Each app has its own security mechanisms – your company must rely on providers complying with GDPR, SOC2, or other standards.
• More complex security architecture: Multiple Connect apps in a Jira instance mean multiple potential attack points.

How does a typical Connect app work?

1. A user interacts with a Jira app.
2. The app sends an API request to the provider’s external server.
3. The server processes the request and responds with the required data.
4. The data is delivered back to Jira and displayed in the UI.

Since communication runs over the internet, additional security measures such as encryption, authentication, and access controls are required. In short: With Connect apps, your company relies on external hosting and security solutions – potentially opening the door to compliance problems.

Forge: The new security standard for Jira apps

Atlassian Forge is the new generation of app development in the Atlassian environment. The big advantage: Forge apps run directly in the Atlassian cloud and don’t require an external server.

How does a Forge app work? Forge is based on a serverless architecture with the following core components:

• Forge UI: A declarative user interface rendered within Jira or Confluence.
• Forge Functions: Lambda-like serverless functions executed in the Atlassian cloud.
• Forge Storage: An integrated database that allows apps to securely store data within the Atlassian infrastructure.

Why is this more secure? For three reasons:

1. No external hosting is necessary since apps run completely in the Atlassian cloud.
2. Security policies are consistent because Forge apps are subject to Atlassian’s compliance and data protection standards.
3. Your data remains within the Atlassian infrastructure.

However, there is a limitation: Forge is flexible and allows developers to integrate external servers. In some cases and use cases, this is quite reasonable and necessary – for example, when an app needs to access external data sources or synchronize with third-party systems.

The problem: As soon as a Forge app interacts with an external server, there is again the risk of unwanted data egress.

Runs on Atlassian – Full control for admins

To further strengthen trust in Forge apps, Atlassian has introduced the new Runs on Atlassian program. This seal of quality confirms that the respective app is fully hosted and operated in the Atlassian infrastructure. The app does not send any data to servers outside the Atlassian cloud. All security mechanisms and measures of the Atlassian infrastructure apply, without gaps and loopholes that would be created by the app.

Runs on Atlassian also requires that the app supports Data Residency. This means you can explicitly specify in which geographic region your data is stored.

All data? All data!

Atlassian follows a strict “No data egress” policy for apps with the Runs on Atlassian label. But what about logs and analytics? Data logs and analytical data can provide valuable insights for developers – for example, for error analysis and targeted improvement of the app.

Atlassian doesn’t want to completely prevent these possibilities but will introduce new control options for admins:

• App admins can decide for themselves whether analytics and logs should be shared.
• This decision is made directly during the installation process.

This means that your company has full control over what data an app collects and passes on.

Conclusion: Forge is the future – but check carefully

Atlassian Forge offers a more secure, compliance-conforming alternative to Connect, as the infrastructure is directly managed by Atlassian. But: Not every Forge app runs completely on Atlassian. If your company wants to be on the safe side, Runs on Atlassian provides a valuable additional criterion.