Security

The architecture is the security model

Calibro Track is a Forge app. It has no servers, no hosting account and no infrastructure of ours anywhere in the path. Its code runs on Atlassian’s compute, its database is provisioned by Atlassian inside your site’s environment, and its interface is served from Atlassian’s CDN. There is no network boundary between your Jira site and the app for anyone to sit on, because there is no boundary.

Most of what a vendor security review asks about therefore has a short answer. There is no data centre to audit, no subcontractor holding a copy, no backup of your worklogs in a bucket somewhere, and no laptop that could leak one.

Data

• Residency — stored and processed in the region Atlassian hosts your Jira site in, inheriting your site’s residency settings.
• Egress — none. The app declares no external permissions, so the platform will not let it make an outbound request even if its code tried to. Issue type icons, which would ordinarily be fetched from a URL by the browser, are read server-side and passed to the interface inline specifically to keep it that way.
• Encryption — in transit and at rest, by the platform.
• Our access — none. We cannot query a customer’s data, and there is no support tool that would let us.
• Deletion — uninstalling removes the app’s database with it.

Access control

The app’s own tables do not carry Jira’s permission model, so authorisation is checked against Jira rather than inferred from what the app stored. Any read that crosses from your own time to someone else’s resolves the caller’s visible projects from Jira first, and constrains the result to that set. Approval rights are held per project rather than granted globally.

There are no Calibro Track accounts and no Calibro Track passwords. Identity is your Atlassian identity, so your SSO, your MFA and your deprovisioning all apply unchanged. Removing someone from Jira removes their access here in the same moment.

How it is built

• Changes land through pull requests and code review rather than direct commits.
• Lint, type-check, unit tests and an end-to-end suite run on every pull request and again before a deploy.
• Dependency updates are raised automatically and reviewed.
• Production deploys run from a version-controlled pipeline rather than from a laptop, and the app’s permission scopes live in the manifest, so widening them is a reviewed code change.
• Database migrations are versioned, applied in order, and recorded.

Reporting something

If you have found a vulnerability, tell us before you tell anyone else and we will work it with you. Write to corbin.m.carter@gmail.com with what you did, what happened, and anything we would need to reproduce it.

What you can expect: an acknowledgement within two working days, an assessment within five, and then a fix or a plan you can hold us to. We will credit you when it is fixed unless you would rather we did not.

We will not pursue legal action over research done in good faith — testing against your own Jira site, stopping once you have proof, and leaving other people’s data alone. There is no bug bounty yet; we would rather say so than run one badly.