Reporting a vulnerability
Write to security@bloomlogic.co.uk.
- We aim to acknowledge within one working day, excluding UK bank holidays, and to tell you whether we can reproduce it within five.
- Please give us reasonable time to fix it before publishing. We will not threaten anyone who reports a problem in good faith, and we will credit you if you want to be credited.
- Please do not test against another company's Jira site. If you need an environment, ask us.
How the app is built
It runs entirely inside Atlassian. Canopy is a Forge app. It runs on Atlassian's platform, inside your own Atlassian site.
It has no servers of ours. Canopy's backend and its app storage run on Atlassian Forge. We operate no separately hosted infrastructure for the app: no server, database, queue or backup of our own.
It makes no connection to anywhere else. No analytics, no error reporting, no content delivery network, no fonts fetched from elsewhere — everything is shipped inside the app. This is checked automatically on every release, and a release that tried to reach outside would be refused rather than shipped and noticed later.
It acts as you, not above you. Every change to your work uses the signed-in person's own Jira permissions, so Canopy cannot make a change to an issue that person could not make themselves. Two small writes are the app's own: the note on a project recording that it uses Canopy's own hierarchy, written only for a person Jira confirms may edit issues there or for a project admin switching the project back to Jira's own tree, and a regular clean-up that removes a closed account from Canopy's archive marks. The clean-up runs as Canopy, with nobody signed in, so it cannot reach a card that issue security hides from Canopy itself: on such a card a closed account's identifier stays in the archive mark, readable in Jira by anyone who can see the card. Issues are read with the person's own permissions; what Canopy keeps for the whole project is the exception set out below. Where a permission is withheld, the affected control is disabled rather than failing when pressed.
One stated limit: restricted items. Where Jira hides some work items from some people (issue security), Canopy's Archive activity record, its shared record of recent moves and its kept baselines are kept for the whole project and do not follow that rule. A person Jira hides an item from can still learn that it exists, its key, where it sits, when it was moved or archived, and who did it; and, for a baseline kept on it, the baseline's name, when it was kept and by whom. On such a project Canopy tells each person so, once. Templates are the one saved thing that keeps titles, so a template saved for the team is refused if any of its work items is restricted; one saved for yourself is read by you, and goes into the data download a Jira admin can take from Canopy's menu (Download Canopy's data), titles of restricted work items included. Canopy says so when you save one that holds a restricted item.
Requests are tied to the project they came from. Every call to the app's backend is checked against the project page it was made from, so a request cannot reach another project's stored settings.
What the permissions are for
Canopy asks for eleven permissions. In plain terms:
- Read your Jira work — to show issues, their fields, comments, attachments and history, and the links between them.
- Change your Jira work — to create and edit issues, change their status, add comments, upload and delete attachments, create and remove hierarchy and dependency links, and re-parent, reorder, archive, restore and delete issues, when you do so in Canopy; to link a card someone newly creates in Jira under a parent to that parent, written by an open board as the person viewing it, on a project using Canopy's own tree; and, normally weekly, to remove a closed account from Canopy's archive marks on the cards Canopy itself can see.
- Read user details — to show who work is assigned to, with their name and picture.
- Read project details — to know which project the page is for, and its issue types and statuses.
- Read and write one project setting — to remember, on the project itself, whether that project uses Canopy's own hierarchy: the choice and when it was made, naming nobody, and nothing else.
- Report personal data — to tell Atlassian, on its required schedule (normally weekly), which people Canopy holds anything for, so that when someone's Atlassian account is closed, Canopy erases what it kept about them. Atlassian requires this of every app that stores account identifiers.
- Read boards and sprints — to show which sprint work is in.
- Change boards and sprints — to move an item into a different sprint from Canopy.
- App storage — to keep saved Views, Branches, palettes and templates, preferences, baselines, the short-lived record of recent changes, the Archive activity record, and the records the regular personal-data report needs.
The ability to change and delete issues is the honest cost of a view you can edit. It is always bounded by the permissions the person already has: if your Jira administrator has not granted someone permission to delete issues, Canopy cannot delete on their behalf, and the control is greyed out rather than failing.
Where your data sits
Everything the app stores is held on Atlassian's platform inside your own site. We hold no copy; Atlassian keeps the app's log, which we can read. See the Privacy Policy at bloomlogic.co.uk/privacy for what is stored, and the Data Processing page at bloomlogic.co.uk/data-processing for how it is handled.
Artificial intelligence
Canopy uses no artificial intelligence service of any kind.
What happens when the subscription lapses
While the app is still running, it becomes read-only: you can look, but not change anything through it. Your Jira work — issues, the hierarchy, its order and archived cards — is never deleted, because it lives in Jira. Atlassian removes the app about two months after a subscription ends without being renewed; what Canopy keeps for itself — saved Views, Branches, palettes, templates, baselines — then follows the retention and recovery arrangements described in our Privacy Policy. How long the app keeps running after a lapse is Atlassian's decision, not ours.
Incidents
If we become aware of a security incident affecting data processed through Canopy, we will notify affected customers without undue delay and in any event within 72 hours of becoming aware. We also tell Atlassian within 48 hours of suspecting an incident; where a notice would name Atlassian, Atlassian may need to approve that wording first, which never delays telling you that an incident has happened. See the data processing page for what that notice contains.