Security Policy — Canopy Access Review

Canopy Access Review is a read-only, egress-free Atlassian Forge app. It runs entirely inside Atlassian's cloud: it makes no external network calls, and SR Consulting operates no servers, databases, or third-party services that receive, process, or store your Jira data. There is no vendor-side copy of your data to breach.

That architecture is the core of this security policy — most of the risk surface that a vendor security questionnaire is designed to probe (vendor infrastructure, data transfers, sub-processors, hosting providers, backups held by the vendor) does not exist for this app by design. The sections below describe the controls that do apply: how the app is built and reviewed, how we handle vulnerabilities and security incidents, and how we secure the accounts and systems used to develop and publish it.

This policy complements — and does not replace — the Canopy Access Review Privacy Policy, which describes what data the app reads and stores.

2.1 Runs on Atlassian — egress-free

The app is built on Atlassian Forge and qualifies for the Runs on Atlassian programme. Concretely:

• No egress. The app's manifest declares no external permissions or egress domains. The Forge platform enforces this at runtime: an outbound call to a non-declared domain is blocked by the platform, not merely discouraged by policy. Customers can verify this in the app's manifest at install time and on the Marketplace listing.
• No vendor infrastructure. All app code executes in Atlassian-managed Forge functions ("FaaS"). SR Consulting hosts nothing, terminates no TLS, and holds no infrastructure credentials that could expose customer data.
• No third-party services. No analytics, telemetry, error-reporting service, CDN, advertising, LLM/AI service, or sub-processor receives any customer data.

2.2 Least-privilege, read-only access

• Every Jira scope the app requests is a read scope. The app holds no write scope for Jira content and is technically incapable of modifying, deleting, or transitioning issues, projects, permissions, or users.
• Scopes are granular and enumerated in the manifest, requested only where a specific REST endpoint requires them (permission schemes, permissions, project roles, groups, users, projects and their supporting read scopes), plus storage:app for in-Atlassian snapshot storage and report:personal-data for GDPR personal-data reporting.
• Customers see and consent to the full scope list at install and at any upgrade that adds scopes.

2.3 Data storage and encryption

• Report snapshots and the app's audit log are stored in the Forge Key-Value Store (KVS) — Atlassian-operated storage inside the Atlassian cloud, encrypted at rest and in transit by Atlassian, and subject to Atlassian's data-residency handling for the customer's site.
• Data in transit between the user's browser, Jira, and the app is carried over Atlassian-managed TLS; no connection leaves the Atlassian boundary.
• Stored data is limited to what the reports need. Snapshots are removable by an administrator at any time from within the app ("erase all data"), and all app storage is destroyed by Atlassian when the app is uninstalled.

2.4 Authorization inside the app

• The app's UI is an admin page, and every backend resolver performs its own fail-closed authorization check for the Jira ADMINISTER permission. Module placement is treated as a UI convenience, not a security boundary: a crafted call to a backend endpoint by a non-admin is rejected.
• Privileged, state-changing operations (running a scan, erasing data, exporting evidence) are recorded in a tamper-evident, append-only audit log with a monotonic sequence number, so an administrator can see who did what and when.

2.5 Output safety

• CSV exports are RFC 4180 compliant and hardened against formula injection (CSV/spreadsheet injection), so a maliciously named Jira object cannot turn an exported evidence file into an executable payload in Excel or Sheets.
• Diagnostic logs written by the app follow a PII-free contract: identifiers and counts, never names, email addresses, or report contents.

2.6 Honest reporting as a security property

For an access-review tool, a confidently wrong answer is a security failure. The app cross-checks its computed results against Jira's own permission evaluator on a sample of every scan, and discloses blind spots, conditional grants, truncations, and methodology limits in both the UI and the export header. A partial scan is never presented as complete.

• Language and typing. The app is written in TypeScript under strict mode; the build fails on type errors. Boundaries (REST responses, stored records, resolver payloads) are explicitly typed and validated.
• Automated testing. A unit and integration suite covers the permission resolution engine, storage layer, concurrency behaviour, export generation and authorization contracts, and runs on every change. Platform primitives are faked in a way that models the platform's rejections, not just its happy path, so that tests do not pass on behaviour the real runtime would refuse.
• Mandatory adversarial code review. No change reaches the release branch until it has passed an independent adversarial review briefed to assume the code is broken and to hunt for race conditions, edge cases, authorization gaps, injection, and platform misuse. Findings must be fixed or explicitly dismissed with a written reason before merge. Changes to the manifest (modules, scopes, egress) always trigger this gate.
• Pre-release security audit. Before Marketplace publication the app underwent a full-application adversarial audit across all subsystems (scan engine, storage, authorization, exports, frontend, compliance surface), with each finding re-verified against the code. All findings rated HIGH were remediated before submission; remaining items are tracked to closure on an internally published remediation roadmap.
• Least-privilege by review. Every scope addition must be justified against a specific endpoint requirement and is re-examined at each release.
• Dependency management. Runtime dependencies are deliberately minimal — Atlassian's own Forge packages plus the UI framework. Dependencies are reviewed and updated on each release and in response to advisories; the Forge runtime version is kept on a currently supported release.
• Source control and integrity. All source is held in a private version-controlled repository with full history. Releases are traceable from the published app version back to a specific commit. Deployment to production is a manual, authenticated action performed by the named owner via the Atlassian Forge CLI.
• No secrets in the app. The app requires no API keys, tokens, or credentials of its own; it authenticates to Jira exclusively through Forge's platform-managed app authentication. There are no secrets to leak, rotate, or hard-code.

4.1 How to report a vulnerability

Report suspected vulnerabilities to security@sr-consulting.fr.

Please include: affected app and version, a description of the issue, the steps or proof-of-concept needed to reproduce it, and the impact you believe it has. You may also report through Atlassian's Marketplace Security Bug Bounty and Vulnerability Disclosure programmes, which route findings to us through the Atlassian Marketplace Security (AMS) project.

We ask reporters to practise coordinated disclosure: give us a reasonable window to remediate before public disclosure, do not access, modify, or exfiltrate data belonging to others, and do not degrade any customer's service while testing. We will not pursue legal action against researchers who report in good faith within these terms.

4.2 Our commitments to reporters

4.3 Remediation targets

We remediate confirmed vulnerabilities within, or faster than, the timeframes of Atlassian's Security Bug Fix Policy for Marketplace apps for cloud apps:

Because the app is a Forge cloud app, customers do not need to take any action to receive a security fix: a new major version is deployed by us to Atlassian's production environment and rolled out by the platform. Customers are not left running a vulnerable build while an upgrade sits in their backlog.

4.4 Continuous assessment

• The app is subject to Atlassian's app approval security review and to EcoScanner, Atlassian's automated scanning of Marketplace apps; findings raised in the AMS project are triaged under the commitments above.
• We maintain a named security contact in the Atlassian Marketplace Partner Portal so that Atlassian and researchers can always reach a human.
• We monitor Atlassian's Forge platform security advisories and changelog and react to deprecations and platform security changes as part of routine upkeep.
• We do not currently commission independent third-party penetration testing. Given that the app runs entirely on Atlassian-operated infrastructure with no vendor-side attack surface, our assurance comes from the Forge platform's own security model, Atlassian's review and scanning, mandatory adversarial code review, and the pre-release audit described above.

5.1 What counts as an incident

Any confirmed or suspected event that compromises the confidentiality, integrity, or availability of customer data handled by the app, or of the systems and accounts used to develop, publish, and deploy it — including compromise of the developer's Atlassian partner or Forge account.

5.2 Process

1. Detect & declare. Incidents may surface from a customer report, a researcher, Atlassian, or our own monitoring. Any credible report is treated as an incident until ruled out.
2. Investigate. Establish root cause, whether data was accessed or exfiltrated, which customers are affected, and over what time window.
3. Contain. Take the fastest effective containment step — which may include revoking credentials, rolling back or removing a deployed app version, or requesting temporary delisting of the app from the Marketplace.
4. Notify Atlassian. We raise a P1 ticket with Atlassian promptly and no later than 24 hours after becoming aware of a security incident, per Atlassian's app security incident management guidelines, and maintain contact with remediation updates at least every 6 hours while the incident is active.
5. Notify customers. Affected customers are notified within 72 hours of confirmation, with what happened, what data was involved, what we have done, and what (if anything) they should do. Where GDPR applies, SR Consulting also meets its obligations as controller/processor for notification to the competent supervisory authority (Art. 33) and to data subjects (Art. 34).
6. Remediate. Ship the fix and the controls that prevent recurrence.
7. Review. Conduct a post-incident review and update this policy, the code, and the process accordingly.

5.3 Incident contacts

• Security contact: security@sr-consulting.fr
• General contact: contact@sr-consulting.fr
• Primary and secondary security incident contacts (email and phone) are kept current in the Atlassian Marketplace Partner Portal, as required by the Marketplace Partner Agreement.

We aim to acknowledge inbound security reports within one business day and to respond to Atlassian communications during an active incident within the timelines above.

SR Consulting is a French sole proprietorship. The app is developed and published by a single, named individual; there is no wider staff, contractor, or offshore team with access.

• No standing access to customer data. We cannot read your Jira data. The app operates under Atlassian's app authentication inside your tenant; there is no vendor console, no support back door, and no mechanism by which we can pull your permission data out of your site. Any data we need for support is what you choose to send us.
• Account security. Accounts used to build, deploy, and publish the app — the Atlassian developer/partner account, the source-code host, and the email domain — are protected with multi-factor authentication and unique, high-entropy credentials held in a password manager.
• Endpoint security. The development device uses full-disk encryption, an automatic screen lock, an actively supported OS with security updates applied, and the platform firewall enabled.
• Deployment authorization. Production deployment and Marketplace publication require authenticated access to the Atlassian developer account and are performed only by the owner.
• Least privilege & offboarding. Third-party access is not granted. Should that ever change, access would be scoped to the minimum required and revoked on completion, and this policy updated.
• Support data handling. Support correspondence is handled by email. We ask customers not to send permission exports, user lists, or other production data in support tickets; where a customer chooses to send an export, it is used only to resolve that request and deleted afterwards.

• Availability of the app is a function of the Atlassian Forge platform; there is no vendor-side service that can go down independently. Platform status is published at status.atlassian.com.
• Customer data lives in your Atlassian tenant and is covered by Atlassian's own backup and durability guarantees. We hold no copy to lose, and we therefore make no separate backup of your data.
• Continuity of the app itself. The complete source is held in version control with full history, so the app can be rebuilt, patched, and redeployed from source. Should SR Consulting ever be unable to continue maintaining the app, customers would be notified via the Marketplace listing and email so they can uninstall in an orderly way; uninstalling removes all app-stored data and leaves your Jira configuration untouched, because the app never modified it.

• Sub-processors: none. Atlassian is the sole processor and host of app data. There are no analytics, hosting, AI, or support-tooling sub-processors that receive customer data. If this ever changes, it will be disclosed here and in the privacy policy before the change takes effect.
• Data residency. Because storage is Forge KVS, app data follows the data residency handling of the customer's Atlassian site.
• GDPR. SR Consulting is established in France and operates under the GDPR. The app implements Atlassian's Personal Data Reporting API so that personal-data reporting and erasure requests propagated by Atlassian are honoured on a continuous cycle, independent of billing status. Data-subject requests can be raised via the support page or contact@sr-consulting.fr. See the Privacy Policy for the full detail.
• Certifications. SR Consulting does not itself hold SOC 2 or ISO 27001 certification — we state that plainly rather than implying otherwise. The infrastructure the app runs on is Atlassian's, and is covered by Atlassian's own compliance programme (SOC 2, ISO 27001, ISO 27018 and others). Customers using Canopy as evidence in their own SOC 2 / ISO 27001 / GDPR access reviews rely on the app's exports and on Atlassian's underlying controls.

One point deserves emphasis: the app's CSV exports leave the Atlassian boundary the moment an administrator downloads them. An export is a sensitive document — it describes who can do what across your site. Store, transmit, and retain it under your own classification and retention rules, as you would any other access-review evidence.

Material changes to this policy are published here with an updated "Last updated" date. Changes that affect the app's security posture — a new scope, any introduction of egress, or any sub-processor — are additionally disclosed on the Marketplace listing and in the app's release notes.

Questions, security reports, or a security questionnaire to complete? Write to security@sr-consulting.fr.