Security
Our approach is to remove capabilities rather than to promise restraint. An app that holds no write permission cannot damage your data even if we make a mistake; an app with no network access cannot leak it. Everything below is a description of what the software can and cannot do, and most of it is verifiable before you install.
Verify this yourself, before installing
Every Marketplace listing shows the permissions an app requests, and you can read that list before installing anything. Ours are short, and not one of them is a write permission. You do not have to take our word for any of the following — the platform states it.
| App | Permission | What it allows |
|---|---|---|
| Read-only Gantt | read:jira-work |
Reading work items, in order to draw them on a timeline. |
storage:app |
The app’s own settings store, held by Atlassian. Holds field identifiers chosen by an administrator — nothing from your work items. | |
| Export work items | read:jira-work |
Reading the work items you asked to export. This app stores nothing at all. |
There is no write permission of any kind in either app. Neither can create, edit, move, transition or delete a work item, and neither can touch the Updated field. This is enforced by the Atlassian platform, not by our code.
Taking data out is a separate right
Reading work items on screen and downloading them to a computer are not the same thing: a file, once saved, is outside Jira and Jira’s permissions no longer reach it.
Export work items therefore declares its own Jira global permission, Export work items, which an administrator grants in Jira settings → System → Global permissions like any other. By default only administrators hold it. The check runs on the server, on every request that returns data — not only in the interface.
Access follows your own permissions
Every request the app makes to Jira is made as the signed-in user. The app cannot show anyone an issue they could not already open themselves, and it holds no elevated or service account. Removing someone’s access in Jira removes it here at the same moment.
Where code runs, and where data goes
Our apps are built on Atlassian Forge and run inside Atlassian’s cloud infrastructure. Both are confirmed eligible for Atlassian’s Runs on Atlassian programme.
- No servers of our own. We operate no backend, no database and no cache outside Atlassian. There is no copy of your data anywhere for us to lose.
- No outbound network access. The app declares no external egress and makes no request to any destination outside Atlassian.
- No third parties. No analytics, error reporting, advertising or profiling code is bundled with the app.
What is stored
Technical configuration only: the identifiers of the Jira fields used for dates, project keys, the names of issue link types treated as dependencies, and a timestamp. These are held in Atlassian Forge storage.
No issue content is stored — no summaries, descriptions, comments, attachments, statuses, dates, names or avatars. The chart is assembled in your browser from data fetched live, and is gone when the tab closes. Details are in the privacy policy of each app (Gantt, Export), and organisations needing a processor agreement can use our Data Processing Agreement (Gantt, Export).
Logging
The app writes no application logs containing customer data. There is no logging pipeline to secure, and no log retention question to answer.
Credentials
We never ask for Atlassian personal access tokens, passwords, API keys or any other shared secret, and the app has no field in which to enter one. Authentication is handled entirely by the Atlassian platform. If anyone asks you for such a secret in our name, it is not us.
What we do not have
Being straightforward about this is more useful than silence:
- We hold no SOC 2 or ISO 27001 certification. Those audits examine infrastructure and organisational controls around it — and we run no infrastructure. The controls protecting your data are Atlassian’s, under Atlassian’s own certifications.
- We do not currently run a public bug bounty programme. Reports are handled directly, as described below.
- We have not completed a CAIQ Lite questionnaire. If your procurement process needs one, write to us and we will fill it in.
Reporting a vulnerability
Write to support@goor.email with “Security” in the subject line. Please include enough detail to reproduce the issue.
- Security reports are looked at ahead of everything else, on the day they arrive whenever possible.
- We will confirm receipt, tell you what we find, and let you know when a fix ships.
- We will not pursue or support legal action against anyone who reports an issue in good faith, without accessing or altering other people’s data, and gives us reasonable time to fix it before disclosing.
Fixes follow the remediation deadlines Atlassian sets for Marketplace cloud apps. These are not our own targets — every app on the Marketplace is held to them:
| Severity | Fixed within |
|---|---|
| Critical (CVSS 9.0+) | 10 days |
| High (CVSS 7.0+) | 4 weeks |
| Medium (CVSS 4.0+) | 12 weeks |
| Low (CVSS below 4.0) | 25 weeks |
Counted from the report or from triage. In practice a viewer with two read permissions and no network access has a small surface to get wrong, and we would rather fix something the same week than argue about which bracket it falls into.
Please do not include customer data, credentials or personal data in a report. We do not need it.
Contact
Goor Software · support@goor.email · support hours and response times