Security policy

Last updated 30 July 2026

Our security posture rests on scope rather than process: the apps are built so there is very little to secure in the first place. Everything below is verifiable rather than asserted, and where our apps differ we say so per app rather than making one claim that flatters the weaker case.

Common to every app

Hosting

Atlassian Forge. We operate no servers and hold no infrastructure.

Egress

None declared. Nothing is sent outside Atlassian, to us or to anyone else.

Telemetry

None. No analytics, no tracking, no cookies.

Our access

None. We cannot read app data, and hold no mechanism to retrieve it.

What each app can reach

Mermaid Studio for Confluence

Requests no Atlassian permission scopes, which you can confirm on the install screen. It has no backend: a set of static resources served by Atlassian and executed in the reader's browser, sandboxed inside a Forge iframe. Diagram text is never transmitted and is stored by Confluence as part of the page it lives on. We keep no copy and run no database.

Recurring Requests for Jira Service Management

Requests four scopes: read:servicedesk-request and write:servicedesk-request to read the request being copied and create the new one, read:jira-work to read the answers of an attached form, and storage:app to hold schedules and settings. All four are shown on the install screen.

The two service desk scopes permit offline impersonation, which is what allows a scheduled request to be created as the customer who asked for it rather than as the app. The account it acts as always comes from platform context — the identity of the signed-in customer at the moment they created the schedule — and never from anything a browser can send. It cannot be pointed at another user.

This app does store data, in Forge storage scoped to your installation: the schedules themselves, the details of the requests being repeated, and per-project settings. That includes personal data, which is set out in the privacy policy. It remains inside Atlassian and we cannot read it.

Application security

Diagram source is rendered with sanitisation permanently enabled. A diagram cannot inject scripts into a Confluence page, and this is not configurable.

Diagram nodes may carry links. These are parsed and bound by the app rather than passed through to the renderer, and only http and https URLs are permitted — javascript:, data: and similar schemes are rejected.

Third-party components are pinned and reviewed before upgrade. Mermaid Studio uses Mermaid and CodeMirror, both MIT licensed. Recurring Requests uses only Atlassian's own Forge packages.

Where an app accepts input from a browser, it is treated as untrusted. In Recurring Requests this means the identity it acts as, the project it writes to and the request type it creates are all resolved from platform context on the server rather than taken from the request body, and administrative settings can only be changed from the project settings module.

Reporting a vulnerability

Email [email protected]. Please include the app, what you observed, and enough detail to reproduce it.

Acknowledged within 1 business day
Assessed and triaged within 3 business days
Fixes released as soon as they are ready, ahead of all other work
You will be told when a fix ships, and credited if you wish

We will not pursue legal action against anyone who reports an issue in good faith, avoids privacy violations and service disruption, and gives us reasonable time to respond before disclosing publicly.

Incident response

If a security incident affects one of our apps, we follow the steps below. They are deliberately short: with no servers of ours, no outbound network access and no ability to read app data, the realistic incident is a defect in the app itself or in a dependency.

1. Detection. Reports reach us through [email protected], the Atlassian Marketplace security bug bounty programme, or automated dependency alerts on our source repositories.

2. Triage. Acknowledged within 1 business day and assessed for severity and exploitability within 3. Security work takes priority over all other development.

3. Containment. Because the app runs entirely in the browser with no permissions, containment means shipping a corrected version or, if necessary, withdrawing the affected version from the Marketplace. There is no infrastructure of ours to isolate.

4. Notification. For any confirmed critical or high severity issue we notify Atlassian and affected customers using Atlassian's vulnerability notification templates, within the timeframes set by Atlassian's security bug fix policy. We do not wait for a fix to be ready before telling people.

5. Remediation and review. A fix is released, the reporter is told when it ships, and we record what happened and what changed so the same class of issue is prevented rather than patched.

What we do not claim

Eriksen Labs holds no SOC 2, ISO 27001 or comparable certification, and we have not completed a CAIQ questionnaire. We would rather say so plainly than imply otherwise.

For most reviews the relevant question is what an app can reach. Ours run on Atlassian's infrastructure, send nothing outside it, and ask for the narrowest set of permissions each one needs — listed above, per app. That is a more useful answer than a certificate covering infrastructure we do not operate.