Atlassian Marketplace
For Ganttry, our Jira app. Most of this is short, because a Forge app with no servers behind it has little to disclose — and the part that is not short is the list of everything it can do to your Jira, which is the answer a review actually needs.
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.
Runs on Atlassian, checked 3 September 2026
$ npx forge eligibility --environment production
App version 2.3.0 deployed to production is eligible for the Runs on Atlassian program.Recorded from Forge CLI against the production environment; the result applies to that exact deployed app version.
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
Forge app storage encryption at rest and transport TLS are provided by Atlassian. Integration HMAC roots are separate application secrets managed in encrypted Forge environment variables; they are not platform encryption keys.
Interactive 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.
Integration authentication
A static Forge web trigger accepts approval decisions and approval-policy configuration only. HMAC-SHA-256 binds method, path, installation, canonical plan, role, timestamp, request id and body. Approval and configuration use separate root secrets and roles; timestamps expire after five minutes, replay/rate claims after ten, and the hard limits are 30 decisions or 10 configuration requests per plan/role/minute. It has no read route and returns only predeclared statuses.
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
There is no customer-support impersonation feature or separate vendor customer-data database. Authorized Forge contributors can access platform tooling and logs subject to Atlassian roles and customer log-sharing controls. Deployment access and any support files you send are governed access, not a claim that developer access is impossible.
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 30 August 2026.
5
Scopes
13
Read endpoints
13
Write calls
over 12 endpoints
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-workEverything 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-workPublishing reviewed date, issue, dependency, release, sprint, Team and rank changes back to Jira. 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-projectCreating 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-userThe 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:appGanttry'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.
Ganttry uses Jira's permission schemes rather than keeping a second list of roles that can drift when somebody changes team or leaves the company.
View
Anyone Jira allows to browse the underlying work may view it in Ganttry. Every Jira read is made as the signed-in person, so Jira remains the boundary.
Edit a shared plan
Edit Issues and Schedule Issues are required in every project represented by the plan. If either permission is missing in one project, the shared plan is read-only.
Review an approval
Administer Projects is required in every represented project. The requester cannot approve or reject their own request, and the approved request is tied to its plan, requester, action fingerprint and policy version.
Administer approval policy
Jira Administer permission is required to enable, disable or change approval rules, site defaults, plan inheritance or policy locks. A planner or project approver cannot turn the four-eyes control off or bypass a locked calendar, scheduling or export rule.
Promote configuration and export audit evidence
A Jira administrator can review and atomically apply a versioned configuration package with explicit cross-site identifier remapping and rollback. Administrator-only bounded JSON exports include separate tamper-evident plan and site-policy hash chains; Jira's own history remains authoritative for Jira records.
Replace or restore
Chart replacement and backup restore require Administer Projects in every represented project, or Jira administration. Restoring an approval-policy or inheritance revision always requires Jira administration. A JQL or filter source has no bounded project set before it runs, so changing to one is Jira-administrator only.
Checked behind the screen
The resolver checks these permissions on the server before Forge storage is changed. Hiding a button is not treated as authorization, and a direct resolver call reaches the same check.
13 calls over 12 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 14th appears.
/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.
/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.
/rest/api/3/issueCreates 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.
/rest/api/3/issueLinkCreates a link between two issues that are both on the chart.
/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.
/rest/api/3/issue/{key}/transitionsMoves 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.
/rest/api/3/issue/{key}/assigneeAssigns 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.
/rest/api/3/versionCreates a fix version in a project the chart is drawn from, with a name and a release date and nothing else.
/rest/api/3/version/{id}Changes an existing version's name or release date, by the id Jira gave it. Never released, never archived.
/rest/agile/1.0/sprint/{sprintId}/issueMoves selected chart issues to a sprint Jira listed for the active board.
/rest/agile/1.0/backlog/issueMoves selected chart issues from a sprint back to Jira's backlog.
/rest/api/3/issue/{issueKey}Sets only the discovered Team field on one selected issue.
/rest/agile/1.0/issue/rankRanks one selected issue before or after another issue in the chart.
The transition is the widest of these
A transition runs your own workflow. A workflow can send mail, fire a post-function or close a parent, and nothing in Ganttry can take that back. What is true is that Ganttry can only make a move the person could have made by hand, because the list it chooses from is Jira's own answer for that issue and that user.
Undo depends on the operation
Creating and deleting an issue have no in-app undo, and neither has a bulk form. Date publishing and dependency edits expose limited undo where the interface offers it. Other changes may require another explicit Jira edit and may not be reversible: workflow transitions, permissions, version changes, sprint moves and rank changes do not carry a blanket rollback guarantee.
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.
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.
And the part that is uncomfortable to write
Four of those five are our code, and code can be wrong in a way an arithmetic cannot. Ganttry used to have one DELETE, it reached one path, and that path took a link id — no argument it could be handed, mistyped or crafted, would delete an issue, because Jira's endpoint for a link cannot address one. That was not a check, it was arithmetic, and it is gone. The guarantee that replaced it is real and is a weaker kind, and the difference is what anyone asking what this app can do to their data should be told.
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 path, and fails if one appears outside the canonical machine-readable trust inventory. That inventory also pins scopes, storage-key builders, API roles, retention and telemetry fields.
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.
Security contact
security@plugthatapp.comSend it to the address above. It reaches a monitored inbox and it reaches a person, not a form.
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.
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.
The response process follows Atlassian's Marketplace app security incident guidance. It applies to a suspected incident as well as a confirmed breach, because evidence has to be preserved before the conclusion is known.
A documented response plan
The internal runbook covers severity, named response roles, evidence preservation, containment, remediation, recovery, customer and regulatory communication, and a post-incident review.
Atlassian is notified within 24 hours
A security incident involving the Marketplace app is reported to Atlassian promptly and no later than 24 hours after awareness. During active containment, Atlassian receives an update at least every six hours.
Affected customers are told
When possible, affected customers are notified within 72 hours of identifying an incident. A shorter legal or contractual deadline always takes precedence.
Operational details stay restricted
Responder phone numbers, recovery credentials, evidence locations and containment procedures are kept out of this public page. Security reports go to the monitored address below.
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.
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.