Security Policy

Epic Progress for Confluence · Last updated: October 4, 2026

1. Overview

Epic Progress for Confluence ("the App") is built on the Atlassian Forge platform and operates entirely within Atlassian's infrastructure under the Runs on Atlassian trust boundary. It reads Jira and Confluence with the permissions of the person viewing the page, has no write access to Jira or Confluence, makes no outbound network calls to any external server, and stores no credentials of any kind. This document describes the App's security architecture and our practices.

2. Architecture & Runtime Environment

No developer-operated servers: There is no external backend, database, or infrastructure operated by us. All compute and storage is provided by Atlassian.
Sandboxed execution: Forge functions run in isolated, sandboxed containers with restricted system access managed by Atlassian.
No external network egress: The App declares no egress domains and makes no outbound requests to any server outside the Atlassian platform. No external API keys or third-party services are involved.
No AI services: The App does not call any AI service. Progress is deterministic arithmetic on the status of Jira work items and on Confluence page labels.
Native user interface: The macros, their settings dialog and the admin page are built with Atlassian's UI Kit and rendered by Confluence; the App loads no third-party scripts, fonts, frames or images.

3. Access Control

Control	Details
Reader's own permissions	Every Jira and Confluence read for a page view, a settings preview, a picker, an export or the admin switch runs as the user (Forge `asUser`). Jira and Confluence apply that person's permissions, including issue security and page restrictions. People without access see a short note, never numbers or names. An automated test fails if a Jira request would run as the app.
App account, two yes/no checks only	The App uses its own account (`asApp`) only for two questions that show no data to anyone: on the admin page, whether Jira is connected; and in the daily snapshot cleanup, whether a page with a snapshot still exists or an app access rule blocks it.
No write access	The App requests no write scopes. It cannot create, edit, move or delete any Jira work item or Confluence page, comment or label.
Minimal API scopes	`read:jira-work` (all Jira reads, as the reader), `search:confluence` (Page Progress: count pages by label, as the reader), `read:space:confluence` (space picker), `read:page:confluence` (snapshots: whether the user may view or edit the page, and the daily check whether the page still exists; no page content is read), `read:confluence-user` (verify that the person changing the app setting is a Confluence administrator; only the permitted operations are used), `storage:app` (snapshots, the admin setting, anonymous usage counters, a non-personal cache). Six scopes, no admin or write scopes.
Admin setting for Confluence administrators only	The switch “Allow published snapshots” changes only after Confluence confirms, at that moment and as the person changing it, that they are a Confluence administrator. If Confluence does not confirm it or does not answer, the setting stays as it is and the admin page says why.
Settings from the page, not from the browser	A macro on a page reads its settings from the Forge macro context, which the platform fills from the page and the browser cannot change. Settings sent from the browser (settings preview, pickers) can only query the caller's own data, with the caller's permissions.
Published snapshots	Showing a snapshot requires view permission on the page, and publishing, updating and removing one require edit permission, both checked with Confluence as the user at that moment; publishing reads Jira as the user. Snapshots are stored under the page and macro ID from the Forge context, never from an ID sent by the browser, so a reader of one page cannot fetch the snapshot of another. Stored fields are whitelisted: no person fields (no assignees or account IDs, not even of the publisher) and no JQL text; titles and names are kept as the team wrote them in Jira. Reading a snapshot never causes a Jira request; “View live” reads Jira with the reader's own permissions. Someone who may no longer view the page gets a neutral notice instead. Unless a macro turns it off, a snapshot's numbers are updated when someone who can edit the page opens it and the snapshot is older than 15 minutes, read with that person's own Jira permissions (never with the App's account), one update at a time; an automatic update never adds epics, work items or names, never changes which epics a list shows, and a removal always wins over it. Confluence admins can turn snapshots off for the site.
Input validation	Work item keys, project keys and IDs from the settings are validated before use, and names and labels enter JQL and CQL only as escaped values. JQL typed by users is limited to 2,000 characters and runs with the reader's permissions.
License enforcement	The subscription is checked server-side before any data is shown; if the license state is missing or unknown, the App fails closed and shows a notice instead of data.
Developer access	None. We cannot read, access, or export any data stored in your Jira or Confluence site or in the App's Forge storage. All data resides within Atlassian's infrastructure.

4. Data Protection

Data in transit:

All Forge-to-Jira and Forge-to-Confluence API calls use Atlassian's internal secured transport (TLS 1.2+).
The App makes no outbound HTTPS calls to external services.

Data at rest:

The App stores only published snapshots with two small notes for their automatic update (time of the last check, a one-minute lock; no person), a "last viewed" date per page with a snapshot (no person), one admin setting, anonymous daily usage counters and the IDs of the site's story point fields, in Atlassian Forge storage, hosted by Atlassian with encryption at rest and data residency in the location of your Confluence site.
Macro settings are stored by Confluence itself as part of the page.
No credentials, tokens, or secrets are stored; there are none to store.
Account IDs, email addresses and person fields such as assignees are never stored; titles in snapshots are kept as written in Jira. Work item descriptions, comments and page content are never read.

Data minimization:

The App reads only the fields it needs: status, title, type, parent, due date, story point estimate and the flagged state; the assignee's display name only for the optional list of open work items, shown live and never stored.
Snapshots contain progress by default: counts, keys and the name of what is measured; work item titles and statuses only if the publishing editor chooses so. Retention and deletion are described in the Privacy Policy.

5. No External Credentials or Integrations

The App does not require or accept any API keys, tokens, passwords, or third-party credentials. There is no configuration that could expose user secrets, and there are no integrations beyond the Atlassian platform itself.

6. Dependency & Vulnerability Management

Runtime dependencies are limited to Atlassian's official Forge packages and React, maintained and patched by their publishers.
Build and test tooling is not included in the production runtime bundle.
We run npm audit before every deploy via an automated pre-deploy gate that blocks the release on high-severity findings in the App's own dependencies, plus a weekly automated audit. Current status: 0 known vulnerabilities in the production dependencies.
Security patches are deployed promptly via Forge; the Node.js runtime is maintained by Atlassian.

7. Incident Response

If a security issue is discovered in the App:

We investigate and begin remediation promptly upon notification or discovery.
A fix is deployed as a priority update via the Forge deployment pipeline.
Affected customers are notified via the Marketplace listing and, where possible, directly.

To report a security vulnerability, contact support@janekbehrens.de with the subject line "Security Report — Epic Progress". We aim to acknowledge reports within 2 business days.

8. Organizational Security Controls

Access to production: Deployments are performed exclusively by the maintainer (Janek Behrens) via the authenticated Forge CLI, behind an automated security gate.
Source code: Maintained in a version-controlled repository under the maintainer's control.
No sub-processors: We engage no sub-processors. All processing occurs within the Atlassian platform.

9. Compliance

GDPR: The App stores no account IDs or person fields; titles in snapshots are kept as your team wrote them. See our Privacy Policy.
Atlassian security requirements: Built to comply with Atlassian Forge security requirements, the Forge shared responsibility model and the Marketplace security review.
Runs on Atlassian: Operates under Atlassian's trust boundary, so Atlassian's infrastructure, security controls, and compliance certifications (SOC 2, ISO 27001, etc.) apply to the underlying platform.

10. What We Cannot Access

For complete transparency, we have no technical means to access:

Any data in your Jira or Confluence site (work items, pages, comments, attachments, user data)
The snapshots and other data in the App's Forge storage
Your Atlassian account credentials or session tokens
Any personal data of your team members

11. Contact

For security questions or to report a vulnerability:
Email: support@janekbehrens.de
Subject: Security Report — Epic Progress

Atlassian, Confluence and Jira are trademarks of Atlassian. Epic Progress for Confluence is an independent app by Janek Behrens and is not made or endorsed by Atlassian; the product names only say which products the app works with.