Security Policy

1. Who we are and what this covers

Scritt Solutions, a sole proprietorship operated by Ryosuke Kamei in Tokorozawa, Saitama, Japan, develops and operates the App. One person maintains it. This policy describes the controls that one maintainer applies and keeps, for the App itself and for the accounts and tools used to ship it. Contact us at support@scritt.com.

3. Shared responsibility

Security of the App splits between Atlassian, which operates the platform, and Scritt, which writes and publishes the code.

• Atlassian runs the infrastructure: hosting and isolation of Forge functions, encryption of Forge storage and Confluence attachments in transit and at rest, authentication of your users, and permanent deletion of the App's stored records within 28 days after you uninstall it. Atlassian documents these controls on its Trust site.
• Scritt is responsible for the App's code, the third-party libraries it bundles, the permissions it requests, the accounts used to publish it, and this policy.

4. Permissions and least privilege

The App requests five Confluence scopes, each tied to one job:

• read:page:confluence reads the page body during PDF and Word export so the App can place the diagram image.
• read:content-details:confluence identifies the page or content that holds the macro.
• write:attachment:confluence saves the rendered diagram as a PNG attachment on the same page.
• read:attachment:confluence reads that PNG back for export.
• storage:app keeps the App's own record in Forge storage: a reference to the attachment plus a copy of the diagram source and its SVG.

When the App repairs a stored diagram, it writes with the permissions of the user viewing the page. A user with read-only access cannot change stored content through the App.

5. Access to our systems

Multi-factor authentication is on for every account involved in building and publishing the App: the Atlassian developer account, the GitHub account that holds the source code, and the Vercel account that hosts this site. The source code lives in a private GitHub repository with a single maintainer.

We keep no copy of your data outside Forge storage, and we cannot read what the App keeps there. The App sends nothing to us. When you contact support, we work from what you choose to share.

6. Secure development and releases

Before every deployment we run the App's automated tests: unit tests for the backend, the shared domain package, and both browser bundles, plus TypeScript type checking. A change that fails any of them does not ship.

Every dependency is pinned through lockfiles, so each build uses the versions we reviewed. The App loads no third-party scripts at runtime; we build both browser bundles ourselves from those pinned packages.

We deploy through the Forge CLI from the maintainer's authenticated account. Atlassian distributes updates to your site through Forge, so you never install files from us, and minor updates reach you without action on your side. An update that adds a new permission takes effect only after your site administrator approves it.

7. Vulnerability management

GitHub Dependabot watches the App's dependencies and alerts us to new advisories, and we run npm audit before every release. We track Mermaid.js releases and upgrade the bundled renderer so that upstream security fixes reach the App within the timeframes below.

We assess each vulnerability by its CVSS score and fix it within the timeframes Atlassian sets for Marketplace apps: critical (9.0 and above) within 10 days, high (7.0 to 8.9) within 4 weeks, medium (4.0 to 6.9) within 12 weeks, and low (below 4.0) within 25 weeks. The same timeframes apply whether Atlassian, a customer, a researcher, or we ourselves find the issue.

9. Security incident response

A security incident is any event that exposes, alters, or destroys customer data through the App, or that lets someone use the App with access they should not have. When we learn of one, we:

• confirm it and contain it, which may mean deploying a fix or disabling the affected function until a fix is ready;
• fix the root cause, deploy the fix through Forge, and verify it on a test site;
• report the incident to Atlassian through the Marketplace partner support channel, as the Marketplace security requirements require;
• notify affected customers without undue delay, through the contact details Atlassian makes available to Marketplace partners and through the App's release notes, and tell them what happened, what data was involved, and what we did;
• write down what happened and what we changed to prevent a repeat, and update this policy if the controls changed.

10. Logging and monitoring

The App's backend writes diagnostic logs to Forge, where Atlassian stores them. A log entry may include the page or macro identifier and the outcome of a Confluence API call; it never includes diagram content, names, or email addresses. We read them when we investigate a report or an error. The App collects no analytics and loads no tracking scripts.

11. Changes to this policy

We will update this page when our practices change, and we will change the date at the top. Material changes will also appear in the App's Marketplace release notes.

12. Contact

Security questions or reports: support@scritt.com. We reply within two business days.