Security & Incident Response — Group Audit for Jira

Version 1.0 · Effective 27 August 2026 · Applies to the Marketplace app “Group Audit for Jira (Find Where a Group Is Used)”

Report a security issue: kontakt@arbeitstyp.de with “SECURITY” in the subject line. Reports are read first and acknowledged within two business days.

1. How the app is built

Runs on Atlassian. The app is a Forge app and runs entirely on Atlassian’s infrastructure. There is no remote backend, no web trigger and no egress permission — data never leaves the customer’s Jira site.
Read-only by design. The app requests granular read scopes only (no “Administer Jira” permission) and cannot change or delete anything.
No storage. The app keeps no data: no Forge storage, no external database, no caches outside the current request.
Admin-only. Every backend call runs as the app and is guarded by a server-side check that the calling user is a Jira administrator; the user interface is a Jira admin page.
No secrets, no credentials. The app collects no Atlassian or third-party credentials and holds no API keys.
Minimal logging. Application logs contain counts, booleans and error classes — never group names, user data, tokens or credentials.

2. Secure development

Source code lives in a private Git repository with two-factor authentication enforced; the developer workstation uses full-disk encryption, automatic security updates and the platform’s built-in malware protection.
Dependencies are pinned and audited (npm audit) before every production deployment; releases are blocked on unresolved critical or high findings.
Every release passes static analysis (ESLint), a security review against the OWASP Top 10 (input validation, regular-expression safety, injection in JQL strings, least privilege) and a live end-to-end test suite on a staging site before forge deploy to production.
Atlassian’s automated vulnerability scanning of the app is monitored through the Atlassian Marketplace Security (AMS) project.

3. Vulnerability handling

We follow Atlassian’s Security Bug Fix Policy for Marketplace apps. Reported vulnerabilities are triaged within two business days and fixed within the remediation timeframe Atlassian sets for the severity and hosting type. Because the app is read-only and holds no data, most classes of vulnerability are limited in impact, but every report is treated as real until proven otherwise.

4. Incident response plan

A security incident is any confirmed or suspected event in which the app could have exposed, altered or made unavailable customer data, or in which the app’s source code, build pipeline or publishing account was compromised.

Step	What happens	Target
1. Detect & record	Report received (customer, Atlassian, researcher, own monitoring). Open an incident record with time, source, affected versions and initial severity.	Immediately
2. Contain	Depending on the finding: disable the affected code path, publish a hotfix version, or — if the app itself is the risk — ask Atlassian to pause new installations. Rotate any credential that may be affected (Forge CLI token, Git credentials, publishing account).	Within 24 hours
3. Notify Atlassian	Report the incident to Atlassian through the App security incident management process (Developer & Marketplace Support) with scope, affected versions, containment status and next update time.	Within 48 hours
4. Notify customers	Inform affected customers via the Marketplace listing and email (where a contact is known) using Atlassian’s incident communication template: what happened, what data or functionality was affected, what we did, what customers should do.	Within 72 hours
5. Fix & verify	Ship the corrected version, re-run the security review and the end-to-end suite, confirm the fix on staging and production.	Per bug-fix policy
6. Post-incident review	Write up root cause, timeline and preventive changes; update this plan and the release checklist accordingly.	Within 14 days

Roles

The app is developed and operated by a single person, who acts as product owner, engineer and security contact. All incident communication comes from kontakt@arbeitstyp.de; the same contact is registered as the app’s security contact with Atlassian.

Communication principles

Say what is known, what is not yet known, and when the next update comes.
Never ask customers for credentials or access to their Jira site.
Do not close an incident before Atlassian and affected customers have been informed.

5. Business continuity

The app has no infrastructure of its own to fail: hosting, scaling and backups of the runtime are Atlassian’s responsibility under the Forge platform. Source code is versioned in a private Git repository (off-site copy) and can be redeployed with forge deploy from any workstation with the publishing account.

6. Review

This document is reviewed at every major release and at least once a year, and after any incident. Changes are recorded in the version line at the top.