Security policy for the apps

The short version

The apps are Forge apps. They run inside Atlassian's runtime on your own site, read Jira and Confluence data as the person using them, store their records in Forge hosted storage on your site, and send nothing anywhere else. There are no servers of mine, no egress and no external data stores. What is left to secure is the code, the accounts that can change it, and the way it gets released. This page says how that is done, and what happens when something goes wrong.

Who is responsible

Toine.com B.V. in Utrecht, the Netherlands (Chamber of Commerce 87544903) is the vendor. I am the only person with access to the source, the developer console and the Marketplace listing. There are no employees and no contractors with access. Every cadence in this policy is a recurring entry in my calendar, and the outcome of each one is recorded in the internal version of this document.

Accounts and access

• Every account that can change code, deploy or manage the listing has two-factor authentication: Atlassian, GitHub, Vercel, Apple.
• Source lives in private GitHub repositories with one collaborator. Secrets are never committed; the apps have none to commit.
• Every quarter I review who and what has access to GitHub, the Atlassian developer console, the Marketplace partner profile, Vercel and the development site, revoke anything not needed, and confirm two-factor authentication is still on everywhere. The review is also done whenever an account, device or integration is added or removed.
• The development workstation has full-disk encryption, a locked screen, and automatic operating system updates.

Secure development

• Every product read runs as the viewing user, so Jira and Confluence apply that user's own permissions. A build check fails on any read that would run with the app's site-wide grant without a documented reason.
• Before every deployment and every Marketplace submission, the unit tests and a security gate run. The gate fails the build on raw HTML injection sinks, dynamic code execution, possible hardcoded secrets, a manifest declaring egress or remote endpoints, outbound requests to absolute URLs, and any dependency vulnerability at moderate severity or above.
• Static analysis (Semgrep and CodeQL) and dependency scanning (OSV-Scanner and npm audit) run on every push and every week in GitHub. Dependabot opens update pull requests weekly.
• A documented OWASP Top 10 review covers all apps and is repeated when an app is added, when an app gains a scope, and at least quarterly.
• Every release carries a software bill of materials in CycloneDX format, listing the production dependencies of the Forge bundle and the user interface bundle. It is kept with the release and available on request.
• Changes are tested in the development environment before they go to production. Production deployment is an explicit, manual step, and every release is a distinct versioned deployment recorded by Atlassian.

Fixing what is found

Whoever finds a vulnerability, a scanner, Dependabot, a researcher, Atlassian or a customer, the deadlines are the same and follow Atlassian's Security Bug Fix Policy for cloud apps as the outer bound, counted from the day the finding is confirmed:

• Critical: within 2 weeks. In practice the same day.
• High: within 4 weeks. In practice before the next deployment.
• Medium: within 6 weeks.
• Low: within 25 weeks.

A finding that cannot be fixed in time is mitigated before the deadline, by disabling the feature or withdrawing the version, and the case is recorded. Because a Forge minor version reaches every installation automatically, a fix is live for all customers at once.

Data

All persisted data lives in Forge hosted storage on your own site, encrypted at rest by Atlassian. No customer data is copied to any system I operate, and I hold none on the workstation. The apps write no log statements of their own, so no customer data can reach a log through my code. What the apps read and store is described in the privacy policy for the apps.

Monitoring

Forge records every app invocation, retained by Atlassian for 30 days. Alert rules are enabled on every app in production for invocation errors and success rate, and alerts are emailed to me. Security notifications from Atlassian, GitHub and Apple (new sign-in, new device, two-factor change) go to a mailbox I read daily.

Continuity

Source is on GitHub and pushed the same day it is written. App data is Atlassian's to back up and needs no copy from me. If the workstation is lost, I revoke its sessions and tokens, restore the source on a new device and re-authenticate the Forge CLI with a new token. That restore is rehearsed at least once a year on a clean machine: clone, install, run the tests, deploy one app to the development environment.

Incidents

An incident is anything that exposes customer data through an app, lets a user see data they should not, compromises an account or device that holds source or credentials, or takes an app down for customers. The procedure, in order:

1. Contain, within one hour of becoming aware: revoke affected tokens or sessions, and if an app is the cause, deploy a fix or a version that disables the affected feature.
2. Assess: what data, which sites and users, from when until when, and whether the cause is in my code, in a dependency or in the platform.
3. Notify: if customer data may have been exposed, report to Atlassian through the Marketplace partner support desk and notify affected customers through their site administrators, within 72 hours of assessment.
4. Fix and verify: correct the root cause, add a test or gate check that would have caught it, and verify on the development site.
5. Record and learn: write up the timeline, cause, impact and fix within a week, and change this policy where the incident showed a gap.

The procedure is exercised at least once a year with a walkthrough of a realistic scenario, or credited with a real incident handled under it.

Compliance

Once a year, and whenever Atlassian changes its partner terms or an app gains a scope, I check that the privacy and security answers in each Marketplace listing are still true of the code and the manifest, that the current Marketplace Partner Agreement and Forge terms have been read and nothing in the apps conflicts with them, and that the apps' handling of personal data has not grown beyond what the privacy policy describes.

Reporting a vulnerability

Mail contact@toine.com with what you found and how to reproduce it. Reports are acknowledged within two business days and get priority over everything else. I fix confirmed issues within the deadlines above and before talking about them publicly, and credit you if you want to be credited. There is no paid bounty programme; Toine.com B.V. is a one-person company and says so rather than promising one.

Changes

If I change this policy, I publish the new version on this page with a new version number and date.

Contact

Toine.com B.V., Utrecht, the Netherlands. Email contact@toine.com.