Security

Most of what a security questionnaire asks about is a vendor's servers: where they are, who can reach them, what happens when one is compromised. We cannot answer those questions, because the honest answer to all of them is that there are none.

• Ganttry is a Forge app. The code runs on Atlassian's compute, inside your Atlassian site's own boundary, and its data sits in Forge app storage.
• We operate no servers, no database and no object store that holds your data. There is no infrastructure of ours to be breached, no credentials of ours to be stolen, and no copy of your issues anywhere we could be asked to produce one from.
• Forge requires every external host an app talks to be declared in its manifest as egress. Ganttry's manifest declares none, which is what makes it eligible for the Runs on Atlassian badge — a claim Atlassian verifies against the deployed app rather than one we make about ourselves.
• Data residency follows the host site. There is no second country to name because there is no second host: where Atlassian keeps your Jira is where the app's data is.

$ npx forge eligibility
The version of your app [10.1.0] that's deployed to [development] is eligible for the Runs on Atlassian program.

These are Atlassian's controls, not ours, and saying so is the point. A small studio claiming to have implemented its own encryption at rest is a claim worth less than the platform's, and it is the sort of thing a reviewer checks.

• Encryption

  In transit and at rest, by the platform. Forge app storage is encrypted at rest by Atlassian, and every request between the browser, the app and Jira runs over TLS. We hold no key and manage no certificate, because there is nothing of ours in the path.

• Authentication

  There is none of ours. The person looking at the chart is whoever Atlassian says is signed in to the site. We issue no credential, store no password, and have no login of our own that could be phished or reused.

• Tokens

  No personal access token, API token or OAuth credential of yours is asked for, entered anywhere, or stored. Ganttry talks to Jira through Forge's own product API, which carries the signed-in user's identity for us.

• Access by us

  We cannot read your data. There is no admin console, no support impersonation and no back door: an installed Forge app's storage is reachable by that app running in that site, and not by us. When a support case needs to see something, you send it.

Everything above is about the platform Ganttry sits on. This is the part a review actually came for. The numbers below are read from the app's own test suite, which reads the real manifest and the real source and fails the build when they drift — so they are the app's numbers rather than a description of them. Last checked 24 August 2026.

The 5 scopes, and the sentence that pays for each

A sixth is not an implementation decision. Adding one makes the next deploy a major version, and a major version reaches nobody until each customer's admin approves the new permissions by hand — which is the protection this app is built on, pointed at us as much as at you. Nobody is upgraded quietly, including by us.

• read:jira-work

  Everything the chart is built from: issues, their dates, estimates, links, sprints and fix versions. What it costs: A read of the work in projects the person opening the chart can already see.

• write:jira-work

  Publishing the plan back to Jira, and the six issue writes listed below. What it costs: Jira has no scope meaning “may edit two date fields”, so this one permits every field on every issue. What narrows it is our test, not Atlassian's gateway.

• manage:jira-project

  Creating a fix version, and changing an existing version's name or release date, from the chart that draws the release line. What it costs: Wider than what is used. It also covers components, project roles and the project's own configuration, none of which Ganttry touches. Jira's classic scopes have nothing narrower; the granular set does, and a manifest cannot mix the two.

• read:jira-user

  The names and account ids of people who may be assigned work in a project the chart is drawn from, so the assignee menu can offer them. What it costs: A directory read. Ganttry already receives these names — every assigned issue carries one — so what this adds is offering them before the fact rather than reporting them after it.

• storage:app

  Ganttry's own storage: baselines, the bars you moved, the working calendar, the record of what was published. What it costs: Nothing in Jira. It grants access to this app's data and to no issue.

9 calls over 8 endpoints. Not a summary of them — this is the list, and there is nothing under it. Every one is made as the signed-in user, so your own Jira permissions decide before the app is involved, and a test fails the build if a 10th appears.

• PUT/rest/api/3/issue/{key}

  Sets the start date and the due date on an issue ticked in the publish dialog. One request per issue, and no other field.

• DELETE/rest/api/3/issue/{key}

  Deletes one issue that is on the chart, after a dialog naming it. See below — this one is stated rather than buried.

• POST/rest/api/3/issue

  Creates one issue from a dialog somebody filled in, in a project the chart is drawn from: a summary, a type, an optional parent and the two dates. No description, label, priority or custom field is sent even if a caller invents one.

• POST/rest/api/3/issueLink

  Creates a link between two issues that are both on the chart.

• DELETE/rest/api/3/issueLink/{linkId}

  Removes a link, by the link id Jira gave it. The id is checked as digits before it becomes a path.

• POST/rest/api/3/issue/{key}/transitions

  Moves an issue through one of the transitions Jira itself offered for that issue and that person, by an id from that list. The body carries the transition id and no fields.

• PUT/rest/api/3/issue/{key}/assignee

  Assigns an issue by account id, or to nobody. By id and never by name: two people on a site of any size share a display name.

• POST/rest/api/3/version

  Creates a fix version in a project the chart is drawn from, with a name and a release date and nothing else.

• PUT/rest/api/3/version/{id}

  Changes an existing version's name or release date, by the id Jira gave it. Never released, never archived.

And what is structural rather than checked

True because of the shape of the code rather than because of a test guarding it. There is no code path that does these things, so there is nothing to get wrong.

• No comment is posted, on any issue, by any code path.
• No worklog is written.
• No field is written but those two dates, the assignee, and the ones a create dialog carries.
• No version is deleted, released or archived.
• No request is made as the app. Every call is made as the signed-in user.
• No request leaves Atlassian.

It is on the list above and it deserves more than a line there. A competitor in this category deletes Jira issues when a project is removed from a view, its listing says nothing about it, and its reviews are where customers found out. So: Ganttry can delete an issue. One at a time, from a dialog that names it, and here is everything standing between that and a bug.

• The key is validated as an issue key before it becomes a path.
• It is checked against the projects the chart is drawn from, and refused with “is not in this chart” if it is not one of them.
• The call is made as the signed-in user, so Jira's own Delete Issues permission is what decides.
• One key goes per request. There is no bulk path and no list parameter anywhere in the resolver.
• `deleteSubtasks` is never sent, so Jira refuses a parent that has children rather than taking it with its subtree.

If your review would rather the capability did not exist, say so. It is one dialog, and we would rather know that than find out from a renewal.

Every app in this category says it is safe. The difference worth asking about is what happens on the day somebody adds a feature that quietly is not. In Ganttry that day fails the build, and here is each thing that fails it.

• The scope list is counted

  A test reads the real manifest and asserts the scopes by name and by number. Adding one fails the build, so it becomes a deliberate act with somebody's name on it rather than a line that appeared in a diff.

• The endpoint list is counted

  The same test reads the shipped source, extracts every call to Jira with its verb and its path, and fails if one appears that is not on a list written out in that file with a paragraph explaining what it cost.

• Every write is made as you

  The test asserts that no module calls Jira as the app, and that every call site is made as the signed-in user. Your own Jira permissions decide what a write is allowed to do, before the app is involved.

• The bodies are pinned, not just the endpoints

  Holding a write scope permits every field on every issue, so the test also checks what is actually sent: which fields a date write assigns, that a transition carries an id and no fields, that an assignee carries an account id and nothing else. Widening a body fails the build the same way a new endpoint does.

• Nothing can reach outside Atlassian

  The test asserts that no shipped source file contains an outbound URL, and that the one module naming an XML namespace — which is an identifier, not an address — cannot make a request at all.

None of that is a promise about our intentions. It is a promise that a change of intention cannot ship quietly: the test has to be edited, by hand, by somebody who then has to write down what they gave up.

What to put in it

• The app and the version, and the site you saw it on if you are comfortable naming it.
• What you did, what happened, and what you expected instead.
• Enough to reproduce it. A screen recording is worth more than a paragraph.
• Whether you have told anyone else, and whether you intend to publish.

What happens next

• You get a reply

  Within four business hours, which is the severity 1 first-response target on our published SLA. We do not offer a faster number here, because a second commitment beside a specific one is how both stop meaning anything.

• We tell you what we think it is

  Confirmed or not, with the reasoning. If we disagree that it is a vulnerability we will say why rather than going quiet.

• We fix it and ship it

  A confirmed vulnerability is treated as severity 1: a fix or a written workaround within 48 hours of us confirming it. Forge deploys reach every install without an upgrade unless the fix needs a new scope, and we will tell you if it does.

• We tell Atlassian, and we tell the people affected

  Atlassian is notified through the Marketplace security process. If customer data was reachable, affected sites are told directly — what happened, when, and what it touched.

Those times are the ones on our service level agreement, which is published, versioned and dated. We deliberately do not offer a faster number on this page: a second commitment beside a specific one is how both stop meaning anything.

Safe harbour

Report something in good faith and we will not pursue you for it. Test against your own site or a free Atlassian instance, not somebody else's; do not run anything that degrades a service or reaches data that is not yours; and give us a chance to ship a fix before publishing. We have no bug bounty and no budget for one — we would rather say so than run a programme we cannot pay out on. Credit in the release notes is offered, and declined as often as it is taken.

A review checklist has questions this answers with a no. Answering them here is cheaper for both of us than a follow-up email, and a page that quietly omitted them would earn one.

SOC 2, ISO 27001 or an equivalent certification?

No. We are a small studio and hold no certification. What stands in its place is that there is no infrastructure of ours in scope for one: the compute, the storage and the encryption are Atlassian's, and Atlassian's own certifications cover them.

A CAIQ Lite self-assessment?

Not published. Ask and we will complete one for your review; most of its rows are answered by the sentence above.

A penetration test report?

None commissioned. The testable surface is a Forge app with no egress, no server and no authentication of its own; the platform underneath it is tested by Atlassian.

A bug bounty?

No. Atlassian runs one that covers Marketplace apps, and reports reaching us that way reach us just as well as the address above.

A Data Processing Addendum?

Yes, on request, at the security address. We act as a processor for the small amount of personal data an app stores, and Atlassian is the sub-processor holding it.

A term is never edited in place. When one changes, the version goes up and the change is written here, so a reviewer who cited a version can see what happened to it.

• 1.0 · 24 August 2026First published.