Richtlinie zur Behebung von Sicherheits-Bugs
Atlassian ist es ein großes Anliegen, sicherzustellen, dass die Systeme von Kunden nicht durch Ausnutzung von Schwachstellen in Atlassian-Produkten kompromittiert werden können.
Umfang
Diese Richtlinie beschreibt, wie und wann wir Sicherheitsrisiken in unseren Produkten beheben.
Service Level Objectives (SLOs) für die Behebung von sicherheitsrelevanten Bugs
Atlassian legt Service Level Objectives zur Behebung von Sicherheitsrisiken auf Grundlage des Schweregrads und des betroffenen Produkts fest. Wir haben die folgenden Zeitvorgaben für die Behebung von Sicherheitsproblemen bei unseren Produkten festgelegt:
Ziele für die schnelle Problembehebung
Diese Zeitrahmen gelten für:
- Alle cloudbasierten Atlassian-Produkte
- Jede Software bzw. jedes System, das von Atlassian verwaltet wird
- Jede Software bzw. jedes System, das innerhalb der Atlassian-Infrastruktur ausgeführt wird
- Jira Align – Cloud-Releases und selbstverwaltete Releases
Je nach Schweregrad des Sicherheitsrisikos haben wir die folgenden Zeitvorgaben für den Bugfix in einem Produkt nach der Überprüfung festgelegt:
- Kritisch – 14 Tage
- Hoch – 28 Tage
- Mittel – 42 Tage
- Niedrig – 175 Tage
Verlängerte Problembehebungsfristen
Diese Zeitvorgaben gelten für alle Data Center-Produkte von Atlassian. Data Center-Produkte werden vom Kunden auf selbst verwalteten Systemen installiert. Dazu zählen die auch die Data Center- und mobilen Apps von Atlassian.
- Schweregrad Kritisch, Hoch und Mittel: Diese Sicherheitsrisiken sollten spätestens 90 Tage nach der Meldung im Produkt behoben sein.
- Schweregrad Niedrig: Diese Sicherheitsrisiken sollten spätestens 180 Tage nach der Meldung im Produkt behoben sein.
Modell der geteilten Verantwortung
Wir bei Atlassian legen großen Wert darauf, sofort einsatzbereite, sichere Produkte zu liefern. Wir verlassen uns jedoch auch auf ein Modell der geteilten Verantwortung. Bei diesem Modell müssen Kunden Praktiken implementieren, die über das Deployment hinaus andauern und sich bis in die Betriebsphasen erstrecken. Zu diesen Verantwortlichkeiten gehören:
- Betrieb der Atlassian-Software in privaten Netzwerken
- Schnelle Implementierung von Sicherheitskorrekturen, sobald sie veröffentlicht werden
- Konfiguration von Web Application Firewalls (WAF), VPNs, Multi-Faktor-Authentifizierung und Single-Sign-On
- Implementierung von Verschlüsselung und Zugriffskontrollen
- Durchführung regelmäßiger Backups
- Durchführung regelmäßiger Sicherheitsaudits
Kritische Sicherheitslücken
Wenn ein "kritisches" Sicherheitsrisiko von Atlassian entdeckt oder von einem Dritten gemeldet wird, ergreift Atlassian die folgenden Maßnahmen:
- Für Cloud-Produkte liefern wir so schnell wie möglich einen neuen Release mit der Behebung für das betroffene Produkt.
- Für selbstverwaltete Produkte liefern wir:
- ein Bugfix-Release für das neueste Feature-Release des betroffenen Produkts;
- ein neues Feature-Release für das betroffene Produkt gemäß Release-Zeitplan;
- einen Bugfix-Release für alle langfristig unterstützten Releases des betroffenen Produkts gemäß der Support-End-of-Life-Richtlinie von Atlassian.
Produkt | Backport-Richtlinie | Beispiel |
|---|---|---|
| Jira Software Server und Data Center Jira Server und Data Center Jira Service Management Server und Data Center (ehemals Jira Service Desk) | Veröffentlichung von neuen Bugfix-Releases für:
| Angenommen, ein kritischer Sicherheits-Bugfix wäre am 1. Januar 2020 entwickelt worden. In diesem Fall wären folgende neue Bugfix-Releases erforderlich:
|
| Confluence Server und Data Center | Veröffentlichung von neuen Bugfix-Releases für:
| Angenommen, ein kritischer Sicherheits-Bugfix wäre am 1. Januar 2020 entwickelt worden. In diesem Fall wären folgende neue Bugfix-Releases erforderlich:
|
| Bitbucket Server und Data Center | Veröffentlichung von neuen Bugfix-Releases für:
| Angenommen, ein kritischer Sicherheits-Bugfix wäre am 1. Januar 2020 entwickelt worden. In diesem Fall wären folgende neue Bugfix-Releases erforderlich:
Bitbucket 6.3.0 wurde am 14. Mai 2019 veröffentlicht, mehr als 6 Monate vor dem Ausgabedatum des Fix. Bei Kennzeichnung als langfristig unterstützter Release wäre ein Bugfix erforderlich. |
| Wir veröffentlichen neue Bugfix-Releases nur für die vorherige Feature-Release-Version. | Angenommen, ein kritischer Sicherheits-Bugfix für Bamboo wäre am 1. Januar 2020 entwickelt worden. In diesem Fall wären folgende neue Bugfix-Releases erforderlich:
|
Für Crowd, Fisheye und Crucible liefern wir einen Bugfix-Release für den neuesten Feature-Release des betroffenen Produkts.
Beispiele zu Behebungen von kritischen Sicherheitsrisiken für selbstverwaltete Produkte:
Angenommen, die Behebung eines kritischen Sicherheitsrisikos wäre am 1. Februar 2024 entwickelt worden. In diesem Fall würden die folgenden Releases den Bugfix erhalten:
Produkt | Beispiel |
|---|---|
| Jira Software | Beispiel Jira Software 9.13.x, weil 9.13.0 der neueste Feature-Release ist |
| Beispiel Jira Software 9.12.x, weil 9.12.0 der neueste langfristig unterstützte Release ist | |
| Beispiel Jira Software 9.4.x, weil 9.4.0 der vorherige langfristig unterstützte Release ist | |
| Jira Service Management | Beispiel Jira Service Management 5.13.x, weil 5.13.0 der neueste Feature-Release ist |
| Beispiel Jira Service Management 5.12.x, weil 5.12.0 der neueste langfristig unterstützte Release ist | |
| Beispiel Jira Service Management 5.4.x, weil 5.4.0 der zweitneueste langfristig unterstützte Release ist | |
| Confluence | Beispiel Confluence 8.7.x, weil 8.7.0 der neueste Feature-Release ist |
| Beispiel Confluence 8.5.x, weil 8.5.0 der neueste langfristig unterstützte Release ist | |
| Beispiel Confluence 7.19.x, weil 7.19.0 der zweitneueste langfristig unterstützte Release ist | |
| Bitbucket | Beispiel Bitbucket 8.17.x, weil 8.17.0 der neueste Feature-Release ist |
| Beispiel Bitbucket 8.9.x, weil 8.9.0 der neueste langfristig unterstützte Release ist | |
| Beispiel Bitbucket 7.21.x, weil 7.21.0 der zweitneueste langfristig unterstützte Release ist | |
| Bamboo | Beispiel Bamboo 9.5.x, weil 9.5.0 der neueste Feature-Release ist |
| Beispiel Bamboo 9.2.x, weil 9.2.0 der neueste langfristig unterstützte Release ist | |
| Crowd | Beispiel Crowd 5.3.x, weil 5.3.0 der neueste Feature-Release ist |
| Fisheye/Crucible | Beispiel Fisheye/Crucible 4.8.x, weil 4.8.0 der neueste Feature-Release ist |
Keine anderen Produktversionen würden neue Bugfixes erhalten.
Häufige Upgrades stellen sicher, dass deine Produktinstanzen sicher sind. Es ist eine Best Practice, den neuesten Bugfix-Release des neuesten Feature-Release oder langfristig unterstützten Release deines Produkts zu nutzen.
Nicht kritische Schwachstellen
Wenn eine Sicherheitslücke mit dem Schweregrad "Hoch", "Mittel" oder "Niedrig" entdeckt wird, versucht Atlassian, diese im Rahmen der am Anfang dieses Dokuments angegebenen Service Level Objectives zu beheben. Sofern möglich, wird der Bugfix unter Umständen auch für langfristig unterstützte Releases zurückportiert. Die Machbarkeit von Rückportierungen hängt von verschiedenen Faktoren ab, wie z. B. von Software-Abhängigkeiten, architektonischen Änderungen und Kompatibilitätsproblemen.
Um sicherzustellen, dass deine Installationen die neuesten Fehlerbehebungen enthalten, solltest du ein Upgrade für sie durchführen, sobald ein Bugfix-Release veröffentlicht wird.
Sonstige Informationen
Der Schweregrad von Sicherheitsrisiken wird anhand der Schweregrade von Sicherheitsvorfällen berechnet.
Wir bewerten unsere Richtlinien kontinuierlich auf der Basis von Kundenfeedback und geben Neuerungen oder Änderungen auf dieser Seite bekannt.