Security Policy
Last updated August 4, 2026
This is the Partner Security Policy for Estimojo. The app is built on Atlassian Forge: it runs entirely inside your Atlassian Cloud site, requests zero egress permissions, and Bomdisoft operates no servers that receive or store your data. This page describes how we secure the app and the process that builds and ships it.
Architecture and hosting
All Estimojo code runs in Atlassian's Forge runtime, inside your Jira site. Data lives in Forge Key-Value Storage on Atlassian infrastructure, encrypted in transit and at rest by Atlassian. Bomdisoft operates no servers, databases, or third-party services that touch customer data; this website is a separate marketing site and holds none.
Platform details
Estimojo stores data differently on each platform it runs on. Every platform Estimojo supports is listed here, whichever one you use.
Jira (Atlassian Forge)
The app manifest requests only the scopes Estimojo needs, and Atlassian enforces them at the platform level. With zero egress permissions, the platform itself blocks any outbound call:
storage:app keeps sessions, votes, and settings in your site's Forge storage.
read:jira-work and write:jira-work read ticket context and write the applied estimate to story points.
read:jira-user shows voter names and avatars through Jira itself.
send:notification:jira asks Jira to notify voters; delivery happens through Atlassian's own notification system (which may include email, per each user's settings), and the app itself cannot send email.
Data security and tenant isolation
Forge storage is scoped per installation, so each customer site is isolated by the platform itself. Bomdisoft has no mechanism to read your site's data: no admin backdoor, no telemetry, no copies outside Atlassian. What is stored and how it is deleted is documented in the privacy policy.
Access control
Deploying and administering the app through the Atlassian developer console and our CI pipeline is restricted to named Bomdisoft engineers with multi-factor authentication on their accounts. Releases reach production only through that pipeline; nobody at Bomdisoft holds standing access to customer sites or their data.
Secure development
Every change is version-controlled and must pass automated type checks, static analysis, and the full test suite in CI before it ships. Dependencies are pinned by lockfile. Releases are staged through separate development and staging environments before production.
Vulnerability management
Dependencies are scanned continuously: Snyk analyzes release-bound changes, Dependabot proposes updates on a monthly cadence, and we monitor security advisories. Each host platform patches its own runtime. Once we confirm a vulnerability, we target:
- Critical severity: fix or mitigation within 7 days.
- High severity: fix within 30 days.
- Medium and low severity: fix within 90 days or the next scheduled release.
Security incidents
If we learn of a security incident, we triage and contain it, investigate the root cause, and close with a post-incident review. Customers whose data is affected are notified without undue delay, at the latest 72 hours after we confirm the incident, together with what happened and what we are doing about it. Platform-level incidents are handled in coordination with Atlassian.
Reporting a vulnerability
Found something? Email support@bomdisoft.com with "Security" in the subject and we will acknowledge within two business days. We welcome good-faith research and will not pursue researchers who report responsibly; please avoid accessing data that is not yours and give us reasonable time to fix before disclosing.
Shared responsibility
Atlassian secures the Forge platform: the infrastructure, runtime sandbox, storage, and encryption, under its own security programs. Bomdisoft secures what we control: the app's code, its permissions, and the process that builds and ships it. The zero-egress design ties the two together so your data never leaves your site.
Contact
Questions about this policy? Email support@bomdisoft.com.