Configscope

Security policy

How Configscope for Jira is built and run, what protects it and the systems behind it, and what happens when something goes wrong.

This page is Configscope's partner security policy for the Atlassian Marketplace. It covers the app Configscope for Jira, this website, and the vendor systems used to build and publish them. What the app reads and stores is described separately in the privacy policy.

Scope and setup

Configscope is operated by its founder. There is no shared account anywhere in the chain: every system below is accessed by one named person, and nobody else holds credentials to it.

The app is built on Atlassian Forge and runs entirely on Atlassian's infrastructure, in the Runs on Atlassian programme. It declares no external network access (no egress), keeps no storage of its own, and requests read-only permissions. It has no servers, databases or third-party services of its own to secure.
This website is static HTML hosted on Cloudflare Pages. It has no backend, no accounts and no user input that leaves the browser.
Vendor systems are the Atlassian developer and Marketplace accounts, the source code repository on GitHub, the domain registrar, and the workstation used for development.

Security controls

Least privilege

The app asks for the smallest set of Jira permissions that covers each call it makes, and every permission is tied to a specific request in the code. Read-only scopes only; no write scope, no storage scope, no egress. Requests run as the app from a Jira admin page that only site administrators can open. Permissions are reviewed at every release, and a scope is removed the moment the call that needed it goes.

Access to vendor systems

Accounts with the right to publish the app or change the listing (Atlassian, GitHub, domain registrar, hosting) require two-factor authentication. API tokens are created with an expiry date, scoped to the task, stored outside the repository, and revoked once the task that needed them is finished. Secrets are never committed: the repository is checked for token patterns before every commit.

Secure development and release

Every change is versioned in git and goes through automated tests and Atlassian's Forge linter before deployment; the linter also verifies that the code only calls endpoints covered by the declared permissions.
Dependencies are pinned in a lockfile and checked against the npm advisory database before each release.
Releases go to a development environment on a live Jira site first, where results are checked against a known baseline before the same build is promoted to production.
Every public Marketplace version is additionally reviewed by Atlassian before it is listed.

Data handling

The app reads configuration and counts, never work item content or user profiles, and stores nothing: scan results exist only on the administrator's screen while the page is open. Application logs held by Atlassian for the app contain error messages only; no customer data is written to logs. Because there is no storage, there is no customer data to encrypt at rest, back up or delete on uninstall.

Vulnerability management

Sources watched: Atlassian's Forge platform and security announcements, the npm advisory database for the app's dependencies, and reports sent to the address below. Findings are handled by severity:

Severity	Response
Critical	Acknowledged within 1 business day. Fix or mitigation deployed within 72 hours; if a fix is not possible in that time, the affected version is withdrawn from the Marketplace until it is.
High	Acknowledged within 2 business days. Fix deployed within 7 days.
Medium and low	Fixed in the next scheduled release, normally within 30 days.

Fixes ship as a new Forge version through the normal release process above. Vulnerable dependency versions are not left in place behind a workaround.

Reporting a security issue

If you believe you have found a vulnerability in Configscope for Jira or this website, email hello@configscope.com with a description and, if possible, steps to reproduce. You will get an acknowledgement within two business days and updates as the issue is confirmed and fixed. Please give us a reasonable time to fix before publishing details; we will credit you if you wish. There is no bug bounty programme at this time.

Security incidents

A security incident is any confirmed unauthorised access to a vendor system, or a defect in the app that exposes or endangers customer data. If one occurs:

Contain. Revoke the affected credentials, and withdraw or disable the affected app version so that no customer site keeps running it.
Assess. Establish what was affected, which customer sites, and for how long, using Atlassian's deployment and installation records.
Notify. Inform Atlassian through the Marketplace partner channels, and affected customers through the contact details Atlassian provides to vendors, without undue delay and no later than 72 hours after confirmation, with what happened, what it affects and what to do.
Fix and learn. Ship the fix through the normal release process and record what changed to prevent a repeat.

Third parties

The app depends on Atlassian only. The vendor uses Cloudflare (website hosting), GitHub (source code) and Porkbun (domain and email forwarding); none of them receive customer data from the app, because the app sends data nowhere.

Changes to this policy

This page is updated when practices change, and the date below is updated with it. Questions: hello@configscope.com.

Last updated 8 September 2026.