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 data in transit and at rest, authentication of your users, data residency for Forge storage (the App's stored data stays in your site's region), and permanent deletion of the App's storage 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 twelve Confluence scopes. Each is tied to one job, and none of them is used to change the body of a page:

• read:page:confluence reads a page's metadata and version number to confirm that the person can see the page and to record which version was approved. It also reads the approval status the App stores on the page.
• write:page:confluence stores the approval status and the byline label on the page as content properties. Atlassian governs content properties with this page-level scope; the App never creates a page version.
• read:content-details:confluence reads the edit restrictions a page already has, so the App can save them before locking the page and put them back afterwards.
• write:content.restriction:confluence applies the edit lock after approval and restores the previous restrictions when a revision is requested. Viewing permissions are never changed.
• write:comment:confluence posts the comment that notifies approvers and requesters by @mentioning them.
• read:comment:confluence is declared with the comment scope above so that the App can handle the comment record Confluence returns when it posts. The App never reads or displays comments written by people.
• read:user:confluence resolves account IDs to display names when a screen is drawn, identifies the App's own account, and checks group membership for the administrator check.
• read:group:confluence expands an approver group into its members when approval is requested, and lets administrators pick groups in the settings screen.
• read:space.permission:confluence reads space roles and their assignments to decide who may change workflow settings. If this check cannot complete, the settings screen stays closed.
• read:space:confluence is declared with the space-roles check above. The App only uses the space identity Confluence hands it and never enumerates spaces.
• read:content.metadata:confluence lets the App subscribe to page-updated events, so it can detect when an approved page is edited and mark the approval invalid.
• storage:app keeps the App's own records in Forge storage: workflow definitions and space settings in key-value storage, and the audit trail in Forge SQL.

The App reads with the permissions of the person using it wherever it can, so it cannot show anyone a page they could not already open. It writes with its own app identity only for the two things an ordinary user must not be able to do by hand: the approval status it attaches to a page, and the edit restriction that locks an approved page. Who may approve or reject is decided by the App from the workflow definition, and who may change workflow settings is decided by Confluence's space roles. When either check cannot complete, the App refuses rather than allows.

5. Integrity of the audit trail

Every audit record carries a hash that links it to the previous record for the same page, so a changed or missing record can be detected. The App writes the audit record before it changes any state, never after, so the trail can say more than happened but never less. There is no function in the App to edit or delete an audit record; the trail is removed only when the App is uninstalled.

The audit trail in Forge SQL is the record of truth. The approval status shown on a page is a display copy, and the label on the page is re-derived from that status each time the page is opened.

6. 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.

7. Secure development and releases

Before every deployment we run the App's automated checks: unit tests for the backend and the user interface, TypeScript type checking, linting, Atlassian's Forge lint, and the Runs on Atlassian eligibility check, which fails if the App were ever to gain an external permission. A change that fails any of them does not ship.

Every dependency is pinned through a lockfile, so each build uses the versions we reviewed. The App's user interface is built with Atlassian's Forge UI Kit and loads no third-party scripts at runtime.

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.

8. Vulnerability management

GitHub Dependabot watches the App's dependencies and alerts us to new advisories, and we run npm audit before every release. The App bundles no rendering engine or other large third-party runtime; its dependencies are the Forge SDK packages and React.

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.

10. 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.

11. Logging and monitoring

The App's backend writes diagnostic logs to Forge, where Atlassian stores them. A log entry may include a page, space, workflow, or account identifier and the outcome of a Confluence API call; it never includes page 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.

12. 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.

13. Contact

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