Your data stays in your tenant. That is the whole design.

Built on Forge, inside your site

• Every app on this site runs on Atlassian Forge, Atlassian's own serverless platform, within your Atlassian site.
• App data is held in Forge storage that belongs to your site. Uninstall the app and it is gone.
• The apps listed here make no external network calls. That is what makes them eligible for Atlassian's "Runs on Atlassian" marker.
• Each app requests the fewest scopes it can. The exact scopes, and why each one is needed, are printed on every app page.
• Apps are read-only by default. Where an app can change something, it is a single opt-in path that previews the change set and asks for confirmation first.
• Every app goes through Atlassian's Marketplace approval, including the Marketplace Security questionnaire. Our code is scanned for dependency vulnerabilities and with static analysis on every change.

Managed applications in your subscription

• Each Azure app deploys as a managed application into your own subscription, under a managed identity you control.
• Roles are granted by you after deployment, scoped to what the app needs, and revocable at any time.
• Alerts go only to destinations you configure: your Slack, Teams, or email. Nothing is sent anywhere else.

What each Atlassian app asks for

Secure development practices

This is our published security policy. It backs the answers on every Marketplace listing's Privacy and Security tab and is reviewed at least annually. Last reviewed: September 2026.

• Least privilege by design. Every app requests the fewest scopes it can, read-only wherever possible. Each write scope is documented in the app manifest with the exact endpoint that needs it and why.
• No secrets in code. Apps hold no API keys, tokens, or credentials. Authentication is delegated to Atlassian (Forge) or to the customer's own managed identity (Azure). Nothing sensitive is written to logs.
• Tested before every release. Strict TypeScript, a unit test suite per app that runs before each deploy, and Forge manifest linting. A release does not ship with failing tests.
• Dependencies kept minimal and current. Software composition analysis (npm audit) runs on every dependency change; critical and high findings are fixed before the next deploy. Atlassian's Ecoscanner and Forge security checks run against every published version and we resolve their findings within Atlassian's required timelines.
• Built and shipped from controlled accounts. UI bundles are built locally and served by the platform, not from third-party CDNs. Developer, Marketplace, and source control accounts require multi-factor authentication; deploy credentials are per-purpose and rotated or revoked when no longer needed.
• Data minimisation. Apps store only the derived report data they need, in storage owned by the customer's tenant and encrypted at rest by the platform. Uninstalling the app removes it.

Vulnerability disclosure

We want to hear about security issues in any Katabarwa Labs app. Send reports to support@katabarwalabs.dev with the app name, the affected version if known, and steps to reproduce. This is the same security contact listed on every Marketplace listing.

• Acknowledgement within 2 business days. You will get a reply confirming receipt and a tracking reference.
• Triage and severity. We assess each report and rate it using CVSS. We will tell you our rating and the planned fix window.
• Fix timelines follow Atlassian's Security Bug Fix Policy. Critical issues are fixed as a priority, and in every case within the timelines that policy sets for Marketplace apps. Forge apps update automatically for all customers once a fix is published, so no customer action is needed.
• Safe harbour. Good-faith research that avoids privacy violations, data destruction, and service disruption, and that gives us reasonable time to fix before public disclosure, will not be met with legal action. Please do not test against Atlassian sites or Azure subscriptions you do not own.
• Credit. We are glad to credit reporters in release notes if they wish.

Incident response commitment

If we confirm a security incident affecting a Katabarwa Labs app, we commit to notifying Atlassian and every affected customer within 48 hours of confirming the incident, and to keeping them updated until it is resolved. Our incident response plan:

1. Detect and triage. Within 24 hours of becoming aware of a possible incident we confirm whether it is real, which apps and versions are affected, and whether any customer data could have been exposed.
2. Contain. Publish a patched version or withdraw the affected version from the Marketplace. Because our apps run inside the customer's own tenant with no servers of ours in the path, there is no Katabarwa Labs infrastructure to isolate.
3. Notify within 48 hours. Report the confirmed incident to Atlassian through the Ecosystem security process and email every affected customer's listed contacts, describing what happened, what data or functionality was affected, what we have done, and what, if anything, they need to do.
4. Remediate and verify. Fix the root cause, test it, redeploy, and confirm the fix with the reporter where one exists.
5. Learn. Write a post-incident summary with timeline, root cause, and the change that prevents a repeat, and update this policy if a control failed.

Where a law or an Atlassian or Microsoft partner agreement requires a shorter notification window, the shorter window applies.