Security policy

Last updated 25 September 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.

Mermaid Diagrams & Gantt 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 & Templates for Jira Service Management

Requests five 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, storage:app to hold schedules, templates and settings, and report:personal-data to report the account ids it stores each week, so that everything held for a closed account can be erased. All five 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 and templates 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.

Issue Templates & Create Defaults for Jira

Requests six scopes, all shown on the install screen. Five of them are Atlassian's recommended scope group for apps that work in Jira's Create dialog, which has to be declared in full: read:jira-work, write:jira-work, manage:jira-configuration, read:jira-user and manage:jira-project. Within that group, the app uses read:jira-work to read the form, the caller's own permissions, projects, issue types, create screens, the issue a template is saved from and the key of an issue just created from the template gallery, and to keep its Create dialog settings in Jira; write:jira-work to fill fields in the Create dialog and to create the optional alert issue; and manage:jira-configuration to put a note on each field it fills, to read priorities and priority schemes, and to see the licence status in the Create dialog. It makes no use of read:jira-user or manage:jira-project. The sixth scope, storage:app, holds templates, their versions, usage counts and the daily check's results.

The only issues it ever creates itself are alert issues, which an administrator can switch on, and a test alert when an administrator asks for one. It never edits or deletes an issue. Filling the Create dialog happens in the person's browser, and the issue is still created by Jira, as that person.

This app records nothing about the people who use it: no account ids, names or email addresses, and not who saved, used, restored or deleted a template. Usage counts stay in your site's app storage and are not sent to us. Templates hold whatever administrators type or copy from an issue. What Save as template removes from a copied description, and everything else the app keeps, is set out in the privacy policy.

If something fails, it writes a short error line to its Forge logs, which Atlassian keeps and we can read. Those lines hold no account ids and nothing from the Create dialog form. The privacy policy says what they hold.

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 Diagrams & Gantt uses Mermaid and CodeMirror, both MIT licensed. Recurring Requests uses only Atlassian's own Forge packages. Issue Templates uses Atlassian's Forge packages and React.

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.

In Issue Templates, the page a request came from, and on a project's pages the project itself, are taken from platform context rather than the request body, and every change to a template or a setting is checked against Jira's own permissions for the person making it. The work the app does as itself rather than as that person — keeping Jira's Create dialog settings in step, checking templates, and creating an alert issue — runs only after an administrator has been confirmed, or from the daily scheduled check. Template text shown on the Templates page is inserted as text, never as markup.

Email security@eriksenlabs.com. 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.

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 security@eriksenlabs.com, 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 our apps run on Atlassian Forge with no servers of ours, 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.

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 only for the permissions each one needs, or that Atlassian requires as a group for a module it uses — listed above, per app. That is a more useful answer than a certificate covering infrastructure we do not operate.

Privacy policy · Service level agreement · Terms