Security policy and incident response for Impediment Ledger for Jira

Last updated: 2026-10-12

1. Scope

This policy covers the Atlassian Forge app Impediment Ledger for Jira (the “App”) and the accounts, workstation and repositories used to build and publish it. It is maintained by PR Flow, a trading name of Árpád Kozma, sole proprietor (egyéni vállalkozó) (the “Publisher”, “we”, “us”).

PR Flow is a one-person business. This policy states the controls that are actually in place and the steps we follow when something goes wrong. It was adopted on 2026-10-13 and is reviewed at least once a year and after every security incident.

How the App handles data is described in the privacy notice; the security obligations towards customers are in section 11 of the End User License Agreement.

This policy is written in English, and the English version prevails. Translations are provided for convenience only.

2. Reporting a vulnerability

Please report vulnerabilities privately to [email protected] rather than in a public channel. This is also the security contact on the App's Marketplace listing.

3. Accounts and access

  • Every account used for the App has multi-factor authentication: GitHub, Google Workspace, the Atlassian account and the hosting account of the website.
  • Passwords are unique and kept in a password manager.
  • Only the owner has access to the source code, the Forge app, the Developer Space and the Marketplace partner account. Access is reviewed every quarter (contributors, Developer Space members, GitHub collaborators and deploy tokens), and anything not needed is removed.
  • The Forge deploy token is kept only in a protected GitHub environment. It is rotated once a year, or immediately if exposure is suspected.

4. Workstation

  • The development workstation uses full-disk encryption, automatic operating system and application updates, and malware protection.
  • Unsupported operating system versions are not used for development or deployment.

5. Development and change management

  • Every change runs type checks, lint (including security and secret-detection rules), the unit, property-based and system test suites and a dependency audit before it is pushed. Longer checks (deep tests, a full mutation run, audits) run before every release.
  • Production deploys happen only from a version tag on the main branch, through an automated deploy workflow.
  • The OWASP Top 10 and the OWASP Application Security Verification Standard (ASVS) 5.0 are the reference for the App's threat model.
  • Dependencies are installed from a lockfile only, with a minimum release age for new packages. Updates are managed by Renovate and Dependabot, CI fails on known vulnerabilities rated high or above in the dependencies the App ships with, and every release has a CycloneDX software bill of materials (SBOM).
  • The App needs no secrets of its own; none are stored in the code or the repository.

6. Data

  • The App runs on Atlassian Forge with no external egress. Customer data stays in the Forge hosted storage of the customer's Atlassian site; the Publisher has no access to it.
  • Actions a user takes in the App run with that user's Jira permissions, and every result shown to a user is filtered by what that user may browse.
  • Logs contain no personal data, credentials or tokens; only whitelisted, structured fields are logged.
  • Source code and its history are kept in GitHub; the App can be rebuilt and redeployed from any release tag.

7. Incident response

We follow Atlassian's app security incident management guidelines:

  • Detect and record. Note what was observed, when, and what may be affected (the App, accounts, tokens, customer sites).
  • Contain. Revoke or rotate exposed tokens and passwords, disable the affected function or roll back to the last good release, and suspend deploys until the cause is known.
  • Notify. Tell Atlassian through the Developer and Marketplace support portal within 48 hours of becoming aware of an incident that affects customers or their data, and tell the affected customers without undue delay, using Atlassian's incident communication template.
  • Fix and verify. Fix the cause, add a regression test and release through the normal checks.
  • Review. Write down what happened and what changes, and update this policy.

The plan is walked through once a year as a tabletop exercise, with a leaked token and a vulnerability report as scenarios.

8. Continuity

  • The App runs on Atlassian Forge; there are no PR Flow servers to restore.
  • If the workstation is lost, the code is restored from GitHub, the accounts are recovered with multi-factor recovery codes kept offline, and the deploy token is rotated.

9. Contact

Security reports: [email protected]. Other questions: support.