Security Policy
Visual Progress Tracker for Jira ยท Last updated: October 5, 2026
1. Overview
Visual Progress Tracker for Jira ("the App") is built on the Atlassian Forge platform and operates entirely within Atlassian's infrastructure under the Runs on Atlassian trust boundary. Its dashboard gadgets and widgets read Jira with the permissions of the person viewing them, its only change to Jira is writing progress values into the App's own custom fields, it makes no outbound network calls to any external server, and it 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 statuses, subtasks and story points.
- Native user interface: The custom fields, dashboard gadgets, widgets and the admin page are built with Atlassian's UI Kit and rendered by Jira; the App loads no third-party scripts, fonts, frames or images.
3. Access Control
| Control | Details |
|---|---|
| Viewer's own permissions | The dashboard gadgets and widgets search work items, subtasks and epics as the user (Forge asUser), and the project picker and the progress details on a work item read Jira the same way. Jira applies that person's permissions, so each viewer sees only what Jira allows them to see. |
| Cache per viewer | Results of the gadgets and widgets are cached under the viewer's account ID, so a cached result is only ever shown to the person whose search produced it. A JQL filter appears in the cache key only as a hash. |
| App account for the progress fields | The status and subtask progress fields are computed with the App's own account (asApp) when Jira asks for their value, reading only the statuses of that work item and its subtasks. "Recalculate All Fields" runs only after Jira confirms, as the person starting it, that they may browse the project; it writes with the App's account and only into the App's own progress fields, at most once every 7 days. |
| Minimal API scopes | read:jira-work (work items, projects, fields), write:jira-work (only to write progress values into the App's own custom fields), storage:app (settings, the per-viewer cache, technical records and anonymous usage counters). Three scopes, no admin scopes. |
| Admin settings for Jira administrators only | The status-to-progress mapping and the color thresholds can be changed only after Jira confirms, at that moment and as the person saving, that they are a Jira administrator. |
| Input validation | Project keys are checked against a strict character set before they are used in a JQL query. JQL filters entered in the gadget settings run with the viewer's own permissions and are never stored by the App or written to its logs, only a hash of them. |
| Developer access | None. We cannot read, access, or export any data stored in your Jira instance or in the App's Forge storage. All data resides within Atlassian's infrastructure. |
4. Data Protection
Data in transit:
- All Forge-to-Jira 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 the admin settings, a result cache per viewer (work item keys, titles, statuses, types, priorities and progress; in the Epic Progress Tracker grouped by assignee also the assignees' account IDs and display names), the review prompt state per user, field IDs, the time of the last recalculation, the subscription state and anonymous daily usage counters in Atlassian Forge storage, hosted by Atlassian with encryption at rest and data residency in the location of your Jira site.
- A cache entry is used for at most 5 minutes and then replaced by the next load; retention, including the 28 days after an uninstall, is described in the Privacy Policy.
- Gadget and widget settings are stored by Jira as part of the dashboard; progress values are stored by Jira in the App's custom fields.
- No credentials, tokens, or secrets are stored; there are none to store.
Technical logs:
- Log lines contain identifiers such as project keys and, when a recalculation skips or cannot update a work item, its key, plus counts, modes, HTTP statuses and error codes. They never contain titles, names, email addresses, account IDs or JQL text; every value passes a filter before it is written.
Data minimization:
- The App reads only the fields it needs: status, title, type, priority, resolution, parent and subtasks, and story points for the Epic Progress Tracker; the assignee only when work is grouped by assignee.
- Work item descriptions, comments and attachments are never read. No email addresses, avatars or other profile data are stored.
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 auditbefore every deploy via an automated pre-deploy gate that blocks a release on high or critical findings, plus a weekly automated audit. - 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 โ Visual Progress Tracker". 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 Atlassian account IDs as keys of the per-viewer cache and of the review prompt state, and, in the cache of the Epic Progress Tracker grouped by assignee, the assignees' account IDs and display names; no email addresses or other profile data. 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 instance (work items, comments, attachments, user data)
- The settings, cache 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 โ Visual Progress Tracker