Security

The architecture is the security model

Calibro Software’s apps are Forge apps. None of them have servers, a hosting account or infrastructure of ours anywhere in the path. Their code runs on Atlassian’s compute, any database they use is provisioned by Atlassian inside your site’s environment, and their interface is served from Atlassian’s CDN. There is no network boundary between your Atlassian site and one of our apps 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 data in a bucket somewhere, and no laptop that could leak one.

Data

• Residency — stored and processed in the region Atlassian hosts your site in, inheriting your site’s residency settings.
• Egress — none, for any of our apps. Each one declares no external permissions, so the platform will not let it make an outbound request even if its code tried to.
• 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 whatever that app stored, immediately.

Access control

Authorisation for each app is checked against Jira or Confluence directly, never inferred from something the app stored itself. In Calibro Track, for instance, 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. In Calibro Sketch, everything a Sketch shows about a Jira issue or Confluence page is bounded by what the person looking at it can already see in Jira or Confluence — the app has no wider view of its own.

There are no Calibro Software accounts and no Calibro Software passwords for any of our apps. Identity is always your Atlassian identity, so your SSO, your MFA and your deprovisioning all apply unchanged, everywhere. Removing someone from Jira or Confluence removes their access to our apps 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 each app’s permission scopes live in its manifest, so widening them is a reviewed code change.
• Where an app has a 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 support@calibrosoftware.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 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.