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 security issue
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 any compromise of a system used to build or publish our apps.
On becoming aware of an incident we will:
1. Contain it, and preserve evidence for investigation.
2. Assess what data and which customers are affected.
3. Notify Atlassian through the Ecosystem support portal, and affected customers by email, without undue delay and within 72 hours of confirmation.
4. Provide a written summary covering what happened, what data was involved, what we did, and what we are changing so that it does not recur.
5. Keep affected parties updated until the incident is closed.
We follow Atlassian’s security incident communication guidance and use their notification templates so that customers receive information in a form they can act on.
Security contact of record: info@kuppersoftware.com, registered with Atlassian on `ecosystem.atlassian.net` so that they can reach us directly.
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.
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