Security Policy

Kupper Software

Last reviewed: 10 August 2026 · Review cadence: annually, and after any security incident.

This policy describes how Kupper Software secures the apps we publish on the Atlassian Marketplace, how we handle vulnerabilities and security incidents, and what customers can expect from us. It complements our [Privacy Statement], which covers what data we process and why.

 

1. Scope

This policy applies to all Kupper Software apps listed on the Atlassian Marketplace, for both Atlassian Cloud and Data Center, and to the systems we use to develop and publish them.

2. Reporting a vulnerability

Email: info@kuppersoftware.com
We welcome reports from customers, researchers and Atlassian. You do not need permission to report an issue, and we will not pursue action against anyone who reports a vulnerability in
good faith.
Please include, where you can: the affected app and version, the Atlassian product and hosting type, steps to reproduce, and the impact you observed. A CVSS vector is helpful but
not required.
What we commit to:
Stage Our commitment
Acknowledgement Within 2 business days
Initial assessment and severity rating Within 5 business days
Progress updates At least every 10 business days until resolved
Resolution Within the deadlines in section 3
We rate severity using CVSS v3.1. If we disagree with a reporter’s rating, we explain why and record both.
Please do not disclose the issue publicly until a fix is available and deployed. We are glad to credit reporters in our release notes when they wish it.

3. Vulnerability remediation deadlines

We meet or better the Atlassian Marketplace Security Bug Fix Policy.
Cloud apps & Data Center apps
Severity CVSS Fixed within
Critical ≥ 9.0 10 days
High ≥ 7.0 4 weeks
Medium ≥ 4.0 12 weeks
Low < 4.0 25 weeks

The clock starts when the issue is reported to us or identified by our own triage, whichever is earlier.

Because our Cloud apps are built on Atlassian Forge, a fix reaches every customer as soon as we deploy it — there is no upgrade for the customer to perform, and no window in which
some installations remain vulnerable. Data Center fixes are released as a new app version, and we notify affected customers directly.

4. Security incidents

A security incident is any confirmed or suspected unauthorised access to, disclosure of or loss of customer data, or a compromise of our build or publishing systems.

When one occurs, we:

  1. Contain it and assess which data and customers are affected.
  2. Notify Atlassian within 48 hours of becoming aware of it, through the Atlassian Marketplace security channel (ecosystem.atlassian.net).
  3. Notify affected customers without undue delay, and within 72 hours at the latest.
  4. Fix the root cause, send a written summary and keep everyone informed until closure.

 

5. Vulnerability management

– Dependency scanning:
 Third-party dependencies are scanned for known vulnerabilities on every change and before every release, and reviewed for whether the vulnerable code is
  actually reachable in the shipped artefact. We keep runtime dependencies current and prefer to remove a dependency over pinning a vulnerable one.
– Platform advisories:
We monitor Atlassian developer advisories and Marketplace security bulletins, and act on those affecting the platforms and APIs our apps use.
– Pre-release checks.
 Every release passes static analysis and the Atlassian Forge linter, and is reviewed against the Marketplace security requirements before submission.
– No unmaintained releases.
 We do not maintain multiple parallel versions of a Cloud app; the deployed version is the only version, which removes the risk of customers running an unpatched build.

 

6. How our apps are built

Our Atlassian Cloud apps are Atlassian Forge apps. That choice is itself a security control, and it determines most of what follows.
– No vendor-operated infrastructure: Our Forge apps run entirely inside Atlassian’s infrastructure. We operate no servers that receive, process or store customer content.
– No egress: Our apps declare no external hosts and make no outbound network calls. Customer data cannot leave Atlassian’s environment through them.
– Least privilege: Each app requests the minimum set of Atlassian scopes required for its features, and we justify each one at review. Where an app only reads data, it holds
  only read scopes.
– Acting as the user: Product API calls are made in the context of the signed-in user,  so a user only ever sees content they are already permitted to see. Where an app must act
  with its own identity, we check the user’s permissions first via the Atlassian authorization APIs.
– Data minimisation: Our apps store as little as possible, and several store nothing at all outside the Atlassian content they operate on. Where an app does store data, it uses
  Atlassian-hosted storage, inside the customer’s own cloud region.
– Input validation: All values that reach a query, a URL or a pattern are validated against an allow-list or escaped before use. Paths are normalised and then checked against
  an allow-list, so a crafted request cannot redirect an app to an unintended endpoint.
– Logging discipline: Application logs record events and counts, not content. We do not log credentials, tokens, or personal data, in line with Atlassian’s logging guidelines.
– No credentials collected: Our apps never ask customers for Atlassian passwords or API tokens, and never handle third-party credentials.

 

Data Center apps run entirely within the customer’s own infrastructure, under the customer’s controls. They neither call out to us nor report usage back to us.

Technical controls

  • Encryption in transit: TLS 1.2 or higher on every connection.
  • Encryption at rest: AES-256, through Atlassian’s platform storage. Sensitive data that an app keeps in Confluence pages is also encrypted with AES-256-GCM.
  • Access control: apps act with the signed-in user’s own Atlassian permissions, with minimal scopes.
  • Isolation: Cloud apps run in Atlassian’s sandboxed Forge runtime with no outbound network access.
  • Accounts: MFA on every account used to build or publish our apps.

 

7. Secure development

– Source code is held in private repositories with access limited to those who need it.
– Changes are reviewed before release, and releases are made only from reviewed code.
– Publishing credentials are held by named individuals, protected by multi-factor authentication, and are not shared.
– Development workstations use full-disk encryption, endpoint protection, and are kept patched.
– Access to any system that can publish an app is granted on a least-privilege basis and reviewed when someone’s role changes.
– No customer data is used for development or testing; we test against data we create.

 

8. Data protection

What data our apps process, and why, is set out in our Privacy Statement. In summary: our apps operate on the Atlassian content the customer points them at, in place, and we do not
export, copy or retain that content.

 

Atlassian is the processor for data held in Atlassian Cloud, and the customer remains the controller. Where one of our apps stores data, it is stored using Atlassian’s platform
storage and therefore inherits Atlassian’s encryption at rest and in transit, and the customer’s own data residency settings.

 

9. Keeping this policy current

We review this policy at least annually, and after any security incident or material change to how our apps are built or operated. The review date at the top of this page reflects the
most recent review.

 

Contact us

If you have questions about this Policy, you can contact us at info@kuppersoftware.com