Security: Sojourn - Time in Status & Cycle Time for Jira

Contact: security@lichenapps.com Last updated: 2026-09-05

This page says how to report a vulnerability in this app, what the vendor can and cannot reach, what happens if something goes wrong, and which controls exist today. It is written to be checked rather than admired: every claim below is either a property of the Atlassian platform this app is built on, or something the repository can show.

1. Reporting a vulnerability

Email security@lichenapps.com with the words "security" in the subject. Please include what you did, what you observed, and the site or app version if you have them.

• Acknowledgement within 2 business days. New Zealand business days - the vendor is one person in Auckland, and saying so is more use than implying a rota that does not exist.
• Coordinated disclosure. Please give us a chance to ship a fix before publishing. We will agree a date with you rather than ask for an open-ended delay, and we will credit you if you want to be credited.
• No bug bounty at present. There is no money. There is a fast answer from the person who wrote the code.

Please do not run denial-of-service tests or automated scanners against a customer's Jira site.

2. What the vendor can and cannot access

Nothing. That is not a policy, it is the shape of the app.

• The app is a Forge app and Runs on Atlassian: it executes on Atlassian's infrastructure and stores what it derives in Atlassian-hosted storage provisioned for the installation.
• It makes no outbound network requests except to the customer's own Jira site. There are no vendor servers, no analytics, no telemetry, no third-party services. The manifest declares no egress, and the Runs on Atlassian eligibility check is run on every deploy.
• There is therefore no mechanism by which the vendor can read customer data, with or without the customer's permission. A request to "just send us the data" cannot be honoured, because there is nowhere for it to go and no path by which the vendor could fetch it.
• All Jira permissions the app requests are read-only. It never modifies anything in Jira.
• What a customer sees is checked against their own Jira permissions on every load: the report covers only the projects they can browse, and per-issue lists are checked issue by issue.

The privacy policy's "Who can see what" section is the detailed version of that last point.

3. If something goes wrong

The steps a one-person vendor can actually keep, and no others:

1. Triage within 2 business days of a report or of noticing an incident. Owner: the security contact above, who is also the developer.
2. Contain. Either deploy a fix, or - if a fix is not immediate and customers are exposed - withdraw the affected version from the Marketplace so no further installation gets it.
3. Notify. Atlassian, following Atlassian's security incident notification guidance for Marketplace partners, and affected customers directly at the contact address they installed with. Notification is not conditional on having a fix ready; "we know, here is what we know" comes first.
4. Publish. A dated post-incident note on this page: what happened, what was affected, what was done, and what changed so it does not happen again.

Supported versions: the latest Marketplace version only. There is no back-porting. A security fix ships as a new version and customers on Atlassian cloud receive it automatically.

4. Development controls that exist today

Not aspirations - these run on the vendor's machine for every change:

Secrets. The app has one: a per-installation salt, generated once inside the installation's own storage and used to key each user's saved view. It is never transmitted, never leaves Atlassian's infrastructure, and the vendor cannot read it. The vendor's own Atlassian API token is used only for development against a test site and is rotated when a machine changes hands.

Known dependency exceptions. At the time of writing the audit reports two moderate advisories and none at high or critical, both for uuid reached through Atlassian's own @forge/bridge SDK (@atlaskit/react-ufo). The app does not call uuid, and pinning a nested version inside the vendor SDK would put the tree out of step with the version under Marketplace review. It is recorded, not silenced, and is re-checked whenever @forge/bridge is upgraded.

5. What this page is not

It does not claim a SOC 2 report, a penetration test, a security team, or a 24/7 rota, because this app has none of those. It claims what a one-person vendor building on Atlassian's own infrastructure can honestly claim: no servers to breach, no data to leak, read-only access, and a fast, named human to email.