Security

Security contact and vulnerability disclosure · updated 30 September 2026

Reporting a vulnerability

Email support@dyordanov.com with Security in the subject line. Please do not open a public GitHub issue or post about it until it is fixed. Tell us what is affected, how to reproduce it, what an attacker could do with it, and how to reach you.

In scope: the Sprint Ledger app for Jira Cloud and this documentation site. A vulnerability in Jira, in Atlassian's Forge platform or in the Atlassian Marketplace belongs to Atlassian; report it through Atlassian's own process.

What happens after you report

1. You get an acknowledgement within two business days.
2. We reproduce the issue and rate its severity with CVSS, and tell you the rating.
3. We fix it within the time Atlassian's Security Bug Fix Policy sets for cloud apps, counted from the report or triage: critical 10 days, high 4 weeks, medium 12 weeks, low 25 weeks. Fixes reach every site as an app update, with nothing for its administrators to do.
4. We tell you when the fix is live and agree with you when the issue can be published. With your permission we credit you in the changelog.

We do not run a paid bug bounty.

Good-faith research

We will not pursue legal action against research that stays within these rules:

• test only on a Jira Cloud site you own or are authorised to test (a free Jira site is enough to install the app);
• do not access, change or delete data that is not yours, and stop and report as soon as you reach any;
• do not degrade the service for others: no load or denial-of-service testing, no automated scanning of Atlassian's infrastructure;
• no social engineering or phishing, of us or of anyone else;
• give us the time above to fix the issue before disclosing it.

These rules cannot authorise testing of Atlassian's own systems; Atlassian's terms apply to those.

If there is a security incident

If we learn that your data has been exposed through Sprint Ledger, we tell Atlassian within 24 hours, as Atlassian's security incident guidelines for Marketplace partners require, and the affected sites within 72 hours, through Atlassian and by email where we have an address: what happened, what data was involved, and what we are doing about it.

How the app is built

• It runs on Atlassian's infrastructure. Sprint Ledger is a Forge app: its code runs in Atlassian's hosted runtime (Node.js 22) and its data lives in Forge storage attached to your installation. There are no servers of ours and no third-party services.
• Nothing leaves Atlassian. The app makes no outbound network calls other than to your own Jira site's API. Every production version is checked with Atlassian's forge eligibility command for the Runs on Atlassian programme, which verifies that an app stores its data on Atlassian and does not send it elsewhere.
• It stores as little as it can. IDs, dates, sprint membership and the values it computes, never summaries, descriptions or comments; the only personal data is the account ID of whoever moved an issue in or out of a sprint, which an administrator can switch off and remove. The privacy policy has the full list.
• It shows people only what Jira lets them see. A search that uses its functions or fields returns only the issues the person searching can see, because Jira runs it with their permissions; the admin page is for Jira administrators only; the project page for that project's administrators; the gadget asks Jira whether the viewer can see the board before it shows anything; and the export reads issue summaries from Jira as the person exporting, leaving out issues they cannot see.
• It asks for the permissions its job needs. Read work items, projects, boards (including their configuration) and sprints; run JQL searches; write Jira work, which it uses only for its own read-only fields and its functions' stored answers; read and write app data; read user details, which it uses only to put names in the CSV export and to show the issue panel's times in the viewer's time zone; report the account IDs it stores to Atlassian's personal data reporting API; and use Forge storage. The same list is on the consent screen Jira shows when the app is installed.
• It never handles credentials. It does not ask for, store or log passwords or API tokens; Forge authenticates the app to Jira.
• Dependencies are kept clean. Production dependencies are kept free of known high and critical vulnerabilities, as Atlassian's security requirements for Marketplace apps ask, and the runtime is a supported Node.js version.