Security overview

Effective October 28, 2026

Report a vulnerability

If you think you found a security problem in TreeCraft, follow our Vulnerability Disclosure Policy. It says how to report, what is in scope, how we protect researchers who act in good faith, and what to expect from us and when.

• Write to info@plugincraft.ca. Use sample data.
• For an urgent matter, such as data being exposed now, put "URGENT" at the start of the subject line.
• Security contact hours: 8:00 to 17:00 Eastern Time, Monday to Friday.

Once TreeCraft is listed on the Atlassian Marketplace, you can also report through Atlassian: the Marketplace Security Bug Bounty program and the Vulnerability Disclosure Program.

Response commitments

These are the times Plugincraft commits to. They match the minimums that Atlassian sets for Marketplace partners in the Atlassian Enterprise Certified program, or improve on them. Business days are Monday to Friday, and business hours are the support hours: 8:00 to 17:00 Eastern Time. A message that arrives outside business hours counts from the start of the next business period.

Security reports go to info@plugincraft.ca, which receives mail at all times and is read on every business day.

Bug fix deadlines

We rate a vulnerability with its CVSS score and fix it within the deadline in Atlassian's Security Bug Fix Policy for cloud apps. The deadline runs from the day we receive the report, or from the day Atlassian reports the vulnerability to us through the Marketplace, whichever comes first. We checked the policy on October 27, 2026. Atlassian may change it, and the policy on Atlassian's site is the one that applies.

These are the deadlines Plugincraft commits to. We do not ask for longer ones. Atlassian's policy allows an extension only in limited cases, for example when the fix depends on a change to the Atlassian platform. If we ever need one, we say so to the reporter. A security incident also has a severity and targets in Incident Response. Where both apply, we meet the shorter time.

Security practices

This section describes how we build, run and check TreeCraft. What it says about the app comes from the app's source code and documentation. What it says about Atlassian's platform comes from Atlassian's documentation, linked where it is used.

Secure development lifecycle

• Private source, pull requests only. The source code is private. Every change is made on its own branch and reaches the main branch only through a pull request. Nobody commits to the main branch directly.
• Independent review. Every pull request is reviewed by a reviewer who did not write it. The reviewer is an AI review agent working to written rules (see the AI Usage Policy). It reads the change against those rules, checks that the automated tests pass, and records what it ran and what it found on the pull request. A person's approval does not replace it, and authors never merge their own pull requests. No review, no merge.
• Automated tests on every change. On every pull request and every push to the main branch, the build runs type checking, unit and scale tests that must cover at least 90% of lines, branches, functions and statements, a production build, and end-to-end tests of the user interface in a real browser. A feature that people can see ships with its end-to-end tests in the same pull request.
• Tests that guard the promises on this page. One test fails the build if the app adds outside network access. One fails it if code logs customer content. One protects released database migrations, which can only be added to, never edited or removed.
• Secret scanning. A scan for secrets runs on every pull request and every push to the main branch. It reads the code and its whole history, with the scanner's default rules and a rule for Atlassian license keys.
• Dependency and static analysis scanning (being added). Scans of the app's dependencies for known vulnerabilities, and of its source code by static analysis, are being added to the automated checks. This page will be updated when they run on every change.
• What we do with findings. We fix a vulnerability in a dependency that ships with the app within the deadlines above. Until the scans above run, we learn of one from advisories and reports, not from an automated check.
• Releases. Only people the owner has given access to the app can deploy it.
• Current runtime. The app runs on the Forge Node.js 22 runtime.

Access control

• Jira decides who sees a work item. The app's pages read work items from Jira as the person looking, so Jira leaves out what that person may not browse. Reads that do not start on a page (the Rovo agent, dashboard gadgets and the work item panel's list of hierarchies) ask Jira, as the caller, which work items they may see. A failed or timed-out check hides the work item.
• Structure, not content. The app keeps each hierarchy's structure as work item ids and their positions. A person who may open a hierarchy can receive the ids and positions of work items they cannot browse, and never those work items' keys, summaries or field values. The REST API and the MCP tools work the same way: they return ids and the app's own words, and the caller reads work items from Jira with their own token, where Jira applies that person's permissions.
• Changes are made as the person. Edits, transitions and write-backs go to Jira from the person's browser, as that person, so Jira applies their permissions. The app does not write to Jira as itself, with one exception: the search tokens below.
• Search tokens are written as the app. When someone with Control turns on Jira search for a hierarchy, the app writes a small property (craftline-search) to each work item in the hierarchy, as the app, holding random tokens that contain no content. It also updates the saved answers of its own JQL function. People who can edit a work item can edit its properties, so the app never uses the property to decide who sees what. Anyone who can search Jira can use the function and can tell which work items they may browse are in the hierarchy, which is why search stays off until someone with Control turns it on. The app removes a hierarchy's tokens when its search is turned off or the hierarchy is deleted.
• The app acts as itself only where it must. It reads the site's field names and lists, the people and groups used in access rules, Assets objects and the site's audit log as the app, and it never writes to Jira as the app except as described above.
• Every request is checked on the server. A person below View access on a hierarchy gets "not found", so hierarchy ids are not disclosed. If the app cannot confirm that a person may see a work item or a hierarchy, it hides it.
• Levels that only narrow. Each hierarchy has its own access list (No access, View, Edit, Automate, Control) on top of Jira's permissions. Jira admins can also limit who may use the app, who may use automation and write-backs, and who administers the app. Those lists take access away. They never grant a level.
• Authenticated APIs only. The app has no web triggers. The REST API and MCP tools are reached through the Atlassian API gateway, which checks an OAuth token and its scopes before the app runs. The app then checks the person's access to each hierarchy, an on and off switch for the site, and its limits (120 calls a minute per person and 1,000 per site).
• Least privilege. The scopes the app asks for, and why, are listed below.
• No credentials. The app asks for no password or personal API token and keeps none.

Data minimisation

• No copy of your work items. Pages read work items from Jira when they need them. The server keeps the ids and positions of the work items in each hierarchy and, for one day, the time Jira said an item changed.
• Ids, not people. The app stores Atlassian account ids to record who owns a hierarchy, who has access and who made a change. It stores no names or email addresses; it asks Jira for them when it shows them. Time off holds days and hours only, with no reason, and is cleared two years after it ends.
• Only what a feature needs. Assets objects are kept as names, keys, types and chosen attributes, with text cut at 100 characters and never an email address or a hidden attribute. Short-lived records are removed on the schedule in Data Handling, and change history is deleted after one year unless an admin turns that off.
• Logs without content. App logs hold ids, counts, statuses and error codes. See Data Logging.
• Support bundle on request. A support bundle holds versions, settings, counts and ids. An admin sees the whole file before deciding whether to send it.
• No tracking. The app uses no analytics service. This website uses no analytics and sets no cookies.

Runs on Atlassian (no egress)

• The app declares no external fetch permissions, remotes, Connect modules, web triggers or external URLs, and it uses no outside scripts, fonts, images, analytics or logging services. A test fails the build if any is added. It is built to stay eligible for Atlassian's Runs on Atlassian program.
• Plugincraft has no servers of its own. The only subprocessor of app data is Atlassian (see Subprocessors), and all the data the app stores stays in your Jira site's data residency location.
• Atlassian states that the Forge platform is SOC 2 attested and ISO 27001 certified, and that an app that uses Forge's runtime and hosted storage and has no data egress can rely on the controls it inherits from the platform. That covers the platform. It is not a certification of Plugincraft. Atlassian also says that when an app runs entirely on its platform, it can fully support investigation, containment and log sharing during an incident.

Encryption at rest and in transit

• At rest. TreeCraft stores customer data only in Forge hosted storage (Forge SQL and the key-value store) and, for search tokens, in Jira. It keeps nothing on a server of its own. Atlassian states that the Forge platform uses AES-256 to encrypt data at rest for data stored within Forge app storage, and that data in the key-value store is "transferred, encrypted, and stored on disk according to the Atlassian cloud's data encryption policies". Forge SQL and the key-value store are both Forge hosted storage, covered by the same Forge data lifecycle documentation.
• In transit. Atlassian states that the Forge platform uses TLS 1.2 or higher to encrypt data in transit. The app makes no other connections. This website redirects plain HTTP to HTTPS and tells browsers to use HTTPS only.
• Secrets. The app keeps no credentials, so it has no secrets to encrypt.

Backups and recovery

• Atlassian backs up the storage. Atlassian states that databases provisioned and managed through Forge SQL are backed up periodically, and that the Atlassian cloud backs up all persistent Forge storage for disaster recovery. If an app deletes data by mistake, Atlassian can restore it when a support ticket is raised within 21 days of the deletion.
• Plugincraft holds no copy. We keep no copy or backup of customer data. The app's code is in a private source repository, and a new version can be deployed to Forge from it.
• Admins can save their own backup. A Jira admin can save a backup file of the app's data (hierarchies, rules, notes, access, settings and, if chosen, history) and restore it as new hierarchies next to the existing ones. The file is saved where the admin chooses, and Plugincraft never receives it. Backup and restore are covered by automated tests.

Penetration test and bug bounty (planned)

• Penetration test. No penetration test of TreeCraft has been done yet. After the app is listed on the Atlassian Marketplace, we plan to have it tested once a year, through Atlassian's penetration test program or by a CREST-accredited provider. Once a test is done, we plan to make the report or an attestation letter available to customers under a non-disclosure agreement.
• Bug bounty. TreeCraft is not yet in a bug bounty program, and Plugincraft pays no rewards for reports yet. After the app is listed, we plan to take part in Atlassian's Marketplace Security Bug Bounty program.
• These are plans, not results. We will update this page when a test is done or the program is joined.

Permissions the app asks for

These are the Forge scopes in the app's manifest, and what each is for.

Incidents and status

How we handle an incident is in Incident Response. A status page will be published with the Marketplace listing. Problems with Jira or Forge themselves are reported on Atlassian's status page.

Related documents

• Vulnerability Disclosure Policy
• Architecture Diagram and Data Flow (password protected: request access at info@plugincraft.ca)
• Data Logging
• Data Handling: Retention and Deletion
• Incident Response
• Subprocessors
• Privacy policy