Security Policy — Time in Status

Architecture and hosting

Time in Status is built entirely on Atlassian Forge. It has no servers, databases, or infrastructure of its own: it stores no data outside Atlassian, and its manifest declares no permission to make an outbound network call to anything other than Atlassian's own APIs.

TLS, HSTS, DDoS protection, encryption at rest, physical security, and patching of the underlying platform are Atlassian's responsibility, not ours — and are covered by Atlassian's own SOC 2 Type II and ISO 27001 certifications.

Data we handle

The app reads issue summary, status, priority, issue type, assignee display name, and a handful of date fields, live, using the viewer's own Jira permissions — and shows it straight back to them. The issue panel also reads the change history of the one issue being viewed, to compute time per status. None of it is copied anywhere else, and CSV exports are generated in the viewer's browser.

The only thing written to Forge's key-value storage is one row a day, per gadget: a date and three counts. No issue key, no summary, no name, and no Atlassian account ID is ever stored — encrypted at rest by Atlassian along with everything else on the platform.

The app holds no permission to create, edit, transition, or comment on an issue — it cannot write to Jira at all. Full detail, including exactly what is and isn't kept, is in the privacy policy.

Authentication and access control

There is no independent login system. Every request runs as the signed-in Jira user, authenticated by Forge through their existing Jira session — we never collect, transmit, or store Atlassian usernames, passwords, or API tokens.

Access is bounded by the scopes declared in the app's manifest, all of them read access:

No write scope is declared anywhere in the manifest.

Internal security practices

Time in Status is developed by a small team at Vudia.

• Multi-factor authentication is enforced on the Atlassian Developer Console account and on the GitHub account (Dbelokon-cpu) that hosts both this documentation site and the app's source.
• Source code is kept in a private GitHub repository — not publicly browsable — with the same MFA-protected account controlling access.
• Dependabot is enabled on that repository: alerts and automated security fixes for known vulnerabilities, plus a weekly check for routine dependency updates.
• Credentials are kept in a password manager; passwords are not shared or reused across services.
• Dependencies are kept deliberately minimal — Atlassian's own Forge packages plus React — the great majority of the tree comes from Atlassian's own SDKs, not third parties this app chose itself.
• Every change runs through an automated test suite before it ships, and is linted before deployment.

Vulnerability management

Development follows OWASP Top 10 guidance. Dependabot watches the dependency tree continuously and opens a pull request the moment a known vulnerability is published; because the tree is small by design, each one gets reviewed and merged rather than queued.

We are evaluating enrolment in the Atlassian Marketplace-managed security bug bounty program (via Bugcrowd). In the meantime, reports are handled directly — see contacts below — and we follow the Marketplace's own SLA: 10 days for Critical severity, 28 days for High severity.

Incident response

1. Investigate the report and confirm scope — what's affected, and how.
2. Notify Atlassian within 24 hours via a priority (P1) support ticket if the platform itself is implicated.
3. Contain the issue and ship a remediation.
4. Notify affected customers directly if any of their data was involved.
5. Run a post-incident review and record what changes as a result.

Business continuity

Because the app has no infrastructure of its own, its availability depends entirely on Atlassian Forge's own SLA and uptime — there is no independent server, database, or backup process for it to fail separately from Atlassian's platform.

Third-party risk

Atlassian is the only third party involved: it provides storage, hosting, and operations, and is certified under SOC 2 Type II and ISO 27001. The app uses no analytics, no subprocessors, and no external APIs — its manifest declares no permission to reach anything outside Atlassian.

Compliance

We do not hold independent security certifications (SOC 2, ISO 27001, or similar) at this time. The app inherits the controls of Atlassian's own certified platform, and is built to comply with the Atlassian Marketplace's security requirements for Cloud apps.

Policy review

This policy is reviewed at least once a year, and sooner if the app's architecture, data handling, or team changes materially.