Security policy

Reporting a vulnerability

Please include enough detail to reproduce the issue: the affected version, the steps taken, and what you observed.

We will acknowledge your report within two working days and give you an assessment — whether we can reproduce it, how serious we judge it to be, and what we intend to do — within ten working days. We will keep you informed until it is resolved, and we will credit you when we publish a fix if you would like us to.

We ask that you give us a reasonable opportunity to fix an issue before disclosing it publicly, and that you do not access, modify or delete data belonging to anyone else while investigating. We will not pursue legal action against anyone acting in good faith under these terms.

We do not currently operate a paid bug bounty.

How the app is built

Capasight:Lite is an Atlassian Forge app. This is the single most important fact about its security posture, because it removes whole categories of risk rather than mitigating them:

• No servers of our own. All code runs on Atlassian's infrastructure, inside the customer's own site. There is no hosting account, no database and no network perimeter of ours to breach.
• No egress. The app makes no external network calls. It has no external permissions declared in its manifest, so the platform itself prevents outbound traffic. There are no third-party services and therefore no subprocessors.
• No write access to Jira. The app holds read scopes only. It cannot create, modify or delete anything in a customer's site.
• Your permissions decide what you see. Every read made in a person's own context is performed with that person's credentials, so Jira's permission model decides what they can see. There is one exception, described below: the background read that builds the portfolio snapshot runs on a queue where there is no user to read as, so it reads with the app's own credentials. Atlassian's security requirements are explicit about what must then happen — “always validate user permissions before using asApp()… for actions triggered in user context” — so that validation happens when the data is served: every row is filtered to the projects the viewer can browse in Jira before it reaches their screen. Someone with no access to a project in scope is shown an empty portfolio and told why, never somebody else's work.
• Runs on Atlassian. The app qualifies for Atlassian's Runs on Atlassian programme, which independently verifies the data-residency and egress properties described above.

What the app stores, and where

Two things, both held in Atlassian's own storage inside the customer's site. Nothing is copied anywhere else, because there is nowhere else.

Configuration. One document per site, containing only what an administrator entered: names of teams, ARTs and value streams, team velocities, project keys, Jira field identifiers, the sprint cadence and the estimate scales. It holds no issue content and nothing that identifies a person.

A portfolio snapshot. A large portfolio cannot be read inside the twenty-five seconds a Forge function is allowed, so it is read once by a background process and the screens are served from the result. That snapshot is held in Forge SQL, the database Atlassian provisions and hosts inside the customer's own site.

For each work item in the configured project scope it holds: the issue and project key, the item's summary, its type level, its parent, its start and due dates, its t-shirt size, the story points rolled up beneath it and how many have been accepted, its status, and the Jira team name on it. Nothing else — no descriptions, no comments, no attachments, no assignee, reporter or any other user identity, and no Atlassian account identifiers.

It is replaced in full by each build, only the two most recent are kept, and it is rebuilt when it is more than twelve hours old, when an administrator changes the project scope or field mapping, or when anyone presses Refresh.

Data residency. Forge hosted storage is covered by Atlassian's data residency programme: an app storing all of its data this way is pinned to the same location as the host product and migrated automatically whenever that product's data is moved. The snapshot therefore sits in the same region as the Jira site it was read from, without the customer doing anything.

Uninstalling the app deletes both.

Logging

Atlassian's platform records application logs, which we can read for support and diagnosis. We deliberately record only counts, statuses and Jira field identifiers. We do not log issue keys, issue summaries, field values, team names, user identities, or the contents of Jira's responses. Error handling records the HTTP status of a failed call and never the response body, because Jira quotes the request back in its errors — a JQL clause, a field name, sometimes an issue key — and all of that is the customer's. The background snapshot build logs counts and outcomes on the same terms.

Development practices

• All source is held in version control, and every change is reviewed before it is released.
• Static analysis (ESLint) and Atlassian's own forge lint run against every change, and both must be clean before a deployment.
• Dependencies are kept to the minimum the app needs, and are limited to Atlassian's own published packages and their transitive dependencies. We monitor advisories against them and update promptly.
• Changes are deployed to a development environment and exercised against a real Jira site before production.
• User-supplied values used in Jira queries are validated against a strict allowlist pattern before use, and all API paths are constructed with Atlassian's parameterised route helper rather than string concatenation.

Access control

Access to the app's source, its Forge deployment credentials and its Marketplace partner account is restricted to named individuals and protected by multi-factor authentication. Deployment credentials are held only on company-controlled machines and are rotated if a device is lost or a person's access ends.

Incident response

If we become aware of a security incident affecting the app, we will assess its scope, fix the cause, and notify affected customers directly at the technical contact held by Atlassian for their site. Where a personal-data breach is notifiable under UK GDPR, we will notify the Information Commissioner's Office within 72 hours of becoming aware of it. The realistic scope of any such incident is narrow, because the app copies nothing outside the customer's own Atlassian site and records no user identities: the snapshot it holds contains work-item fields, not people. Issue summaries are customer content and could in principle contain anything the customer has written there, which is why they are treated as customer data throughout and never leave the site. The obligation stands regardless of scope.

Certifications

We do not currently hold SOC 2, ISO 27001 or equivalent certification. The platform the app runs on is covered by Atlassian's own certifications, which are published in the Atlassian Trust Center.

Contact

security@capasight.co.uk for security matters.
contact@capasight.co.uk for everything else.