Greenlight — Security Statement
Provider: Vladimir Maslov · Security contact: akvola.bean.cg@gmail.com
Greenlight is a Confluence Cloud app built on Atlassian Forge and designed to meet the Runs on Atlassian standard: it runs entirely on Atlassian-operated infrastructure and sends no data to any external system.
Hosting & data flow
- No egress. Greenlight makes no outbound network calls to any non-Atlassian destination, uses
no remote endpoints, no dynamic web triggers, and no Atlassian Connect components. This is
self-verified with
forge eligibility(the basis for Runs on Atlassian eligibility; Atlassian applies the badge automatically once the app is listed). - No third-party sub-processors. No analytics, advertising, or external services.
- Atlassian-hosted storage. App data lives in Forge Key-Value Storage on Atlassian's infrastructure, encrypted in transit and at rest by the platform, with tenant isolation.
Data residency
Greenlight stores data only in Atlassian Forge storage and therefore inherits the host product's data-residency region automatically. The app neither pins nor migrates data independently, so residency follows Atlassian's controls for the customer's site.
Data minimization
Greenlight stores only what it needs to compute approval status: Confluence page/space IDs, the Atlassian account IDs of approvers/editors, approval events with timestamps and version numbers, and (only when the optional lock is used) a snapshot of the page's pre-existing edit restrictions. A page's title, version, and lifecycle state (current/archived) are read live at render to compute the approval status and are not stored (the approval status itself is computed, not stored). It does not read or modify page body content, and stores no names or email addresses. See our Privacy Policy.
Permissions (scopes) and why each is needed
| Scope | Purpose |
|---|---|
read:confluence-content.summary |
summary-level page reads + the page lifecycle product triggers |
write:confluence-content |
a coarse classic scope required because the page product triggers have no granular equivalent; the app uses it only to apply/remove the v1 edit restriction for lock-after-approval — never to modify page bodies |
read:confluence-content.permission |
check a user's edit/view permission on a page (authorization) |
read:confluence-user |
resolve a user's group / product-admin status for the space-admin check |
read:page:confluence |
read a page's live version, space, and type (status computed at render) |
read:space:confluence |
resolve space metadata / id |
read:space.permission:confluence |
determine space administrators (config is admin-only) |
write:comment:confluence |
post the @mention footer-comment that notifies approvers |
storage:app |
store approval records in Forge KVS |
Scopes are kept to the minimum required; over-declared scopes (write:page:confluence,
read:comment:confluence) were removed before listing. The app does not read or modify page body
content, and never accesses personal access tokens or user passwords (Forge-scoped OAuth only).
Authorization model
The app never trusts the client UI; every mutating action is re-checked server-side. Configuration changes require space-admin status (verified against the live, paginated permission list); enabling/approving requires the caller's edit/approver rights on the page. The user-facing reads — the page-status byline and the space report — are performed as the requesting user, so Confluence enforces per-page view restrictions and a viewer never sees the title or approvers of a page they cannot access. Internal authorization checks and background operations (permission checks, the lock restriction, and notification recipient resolution) run as the app and then make their own authorization decisions. All permission/admin checks fail closed (deny on error).
Platform security & compliance
Greenlight inherits the Atlassian Forge security model (tenant isolation, Atlassian-managed runtime, scoped OAuth, platform-enforced storage encryption) and introduces no infrastructure of its own. It holds no independent security certifications and relies on Atlassian Forge's compliance posture (e.g. SOC 2 / ISO 27001 at the platform level).
Incident response
We will investigate confirmed security incidents affecting customer data, remediate, and notify affected customers and Atlassian without undue delay, consistent with the Data Processing Addendum.
Vulnerability reporting
Please report any suspected security issue to akvola.bean.cg@gmail.com. We aim to acknowledge within 3 business days and will work with you on triage and remediation. We support good-faith security research and will not pursue action against researchers who report responsibly and avoid privacy violations or service disruption.