Sicherheitsrichtlinie und Incident Response für Impediment Ledger for Jira

Zuletzt aktualisiert: 2026-10-12

1. Geltungsbereich

Diese Richtlinie gilt für die Atlassian-Forge-App Impediment Ledger for Jira (die „App“) sowie für die Konten, den Arbeitsplatzrechner und die Repositorys, mit denen sie entwickelt und veröffentlicht wird. Sie wird von PR Flow, eine Geschäftsbezeichnung von Árpád Kozma, Einzelunternehmer (egyéni vállalkozó) gepflegt (der „Herausgeber“, „wir“).

PR Flow ist ein Ein-Personen-Unternehmen. Diese Richtlinie beschreibt die Maßnahmen, die tatsächlich umgesetzt sind, und die Schritte, denen wir folgen, wenn etwas schiefgeht. Sie wurde am 2026-10-13 beschlossen und wird mindestens einmal jährlich sowie nach jedem Sicherheitsvorfall überprüft.

Wie die App mit Daten umgeht, beschreibt der Datenschutzhinweis; die Sicherheitspflichten gegenüber Kunden stehen in Abschnitt 11 des Endbenutzer-Lizenzvertrags.

Diese Richtlinie ist in englischer Sprache verfasst, und die englische Fassung hat Vorrang. Übersetzungen dienen nur der besseren Verständlichkeit.

2. Schwachstellen melden

Bitte melden Sie Schwachstellen vertraulich an [email protected] und nicht in einem öffentlichen Kanal. Diese Adresse ist auch der Sicherheitskontakt im Marketplace-Eintrag der App.

3. Konten und Zugriff

  • Jedes für die App genutzte Konto ist mit Multi-Faktor-Authentifizierung geschützt: GitHub, Google Workspace, das Atlassian-Konto und das Hosting-Konto der Website.
  • Passwörter sind einzigartig und werden in einem Passwortmanager aufbewahrt.
  • Nur der Inhaber hat Zugriff auf den Quellcode, die Forge-App, den Developer Space und das Marketplace-Partnerkonto. Die Zugriffe werden vierteljährlich überprüft (Mitwirkende, Developer-Space-Mitglieder, GitHub-Collaborators und Deploy-Tokens); Nicht-Benötigtes wird entfernt.
  • Das Forge-Deploy-Token liegt ausschließlich in einer geschützten GitHub-Umgebung. Es wird einmal jährlich erneuert, bei Verdacht auf Offenlegung sofort.

4. Arbeitsplatzrechner

  • Der Entwicklungsrechner nutzt vollständige Festplattenverschlüsselung, automatische Betriebssystem- und Anwendungsupdates sowie Schutz vor Schadsoftware.
  • Nicht mehr unterstützte Betriebssystemversionen werden weder für die Entwicklung noch für Deployments verwendet.

5. Entwicklung und Änderungsmanagement

  • Jede Änderung durchläuft vor dem Push Typprüfungen, Lint (einschließlich Sicherheits- und Secret-Erkennungsregeln), die Unit-, Property-based- und Systemtests sowie ein Abhängigkeitsaudit. Längere Prüfungen (tiefe Tests, ein vollständiger Mutationslauf, Audits) laufen vor jedem Release.
  • Produktiv-Deployments erfolgen nur von einem Versions-Tag auf dem Hauptzweig über einen automatisierten Deploy-Workflow.
  • Die OWASP Top 10 und der OWASP Application Security Verification Standard (ASVS) 5.0 sind die Referenz für das Bedrohungsmodell der App.
  • Abhängigkeiten werden nur aus einer Lockfile installiert, mit einem Mindestalter für neue Pakete. Updates verwalten Renovate und Dependabot, die CI schlägt bei bekannten Schwachstellen ab Schweregrad „hoch“ in den mit der App ausgelieferten Abhängigkeiten fehl, und jedes Release hat eine CycloneDX-Software-Stückliste (SBOM).
  • Die App benötigt keine eigenen Secrets; im Code und im Repository sind keine gespeichert.

6. Daten

  • Die App läuft auf Atlassian Forge ohne externen Datenverkehr (External Egress). Kundendaten bleiben im Forge-Hosted-Storage der Atlassian-Site des Kunden; der Herausgeber hat keinen Zugriff darauf.
  • Aktionen eines Benutzers in der App laufen mit dessen Jira-Berechtigungen, und jedes angezeigte Ergebnis wird danach gefiltert, was dieser Benutzer sehen darf.
  • Protokolle enthalten keine personenbezogenen Daten, Zugangsdaten oder Tokens; protokolliert werden nur freigegebene, strukturierte Felder.
  • Der Quellcode und seine Historie liegen auf GitHub; die App kann aus jedem Release-Tag neu gebaut und bereitgestellt werden.

7. Incident Response

Wir folgen Atlassians app security incident management guidelines:

  • Erkennen und festhalten. Notieren, was wann beobachtet wurde und was betroffen sein kann (die App, Konten, Tokens, Kunden-Sites).
  • Eindämmen. Offengelegte Tokens und Passwörter widerrufen oder erneuern, die betroffene Funktion deaktivieren oder auf das letzte fehlerfreie Release zurückgehen und Deployments aussetzen, bis die Ursache bekannt ist.
  • Benachrichtigen. Atlassian über das Developer and Marketplace Support Portal innerhalb von 48 Stunden informieren, nachdem wir von einem Vorfall erfahren haben, der Kunden oder ihre Daten betrifft, und die betroffenen Kunden unverzüglich informieren, mit Atlassians Vorlage für die Vorfallkommunikation.
  • Beheben und prüfen. Die Ursache beheben, einen Regressionstest hinzufügen und über die üblichen Prüfungen veröffentlichen.
  • Auswerten. Festhalten, was passiert ist und was sich ändert, und diese Richtlinie aktualisieren.

Der Plan wird einmal jährlich als Tabletop-Übung durchgespielt, mit einem offengelegten Token und einer Schwachstellenmeldung als Szenarien.

8. Kontinuität

  • Die App läuft auf Atlassian Forge; es gibt keine PR-Flow-Server, die wiederhergestellt werden müssten.
  • Geht der Arbeitsplatzrechner verloren, wird der Code aus GitHub wiederhergestellt, die Konten werden mit offline aufbewahrten MFA-Wiederherstellungscodes zurückgewonnen und das Deploy-Token wird erneuert.

9. Kontakt

Sicherheitsmeldungen: [email protected]. Andere Fragen: Support.