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 (SLO) 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 Zeitvorgaben gelten für alle cloudbasierten Atlassian-Produkte und alle anderen Softwareanwendungen oder Systeme, die von Atlassian verwaltet oder innerhalb der Atlassian-Infrastruktur ausgeführt werden. Sie gelten auch für Jira Align (sowohl für die Cloud- als auch die selbstverwalteten Releases).
- Kritisch: Diese Sicherheitsrisiken sollten spätestens 10 Tage nach der Bestätigung behoben sein
- Hoch: Diese Sicherheitsrisiken sollten spätestens 28 Tage nach der Meldung im Produkt behoben sein.
- Mittel: Diese Sicherheitsrisiken sollten spätestens 84 Tage nach der Bestätigung behoben sein
- Niedrig: Diese Sicherheitsrisiken sollten spätestens 175 Tage nach der Meldung im Produkt behoben sein.
Verlängerte Problembehebungsfristen
Diese Zeitvorgaben gelten für alle selbstverwalteten Produkte von Atlassian. Selbstverwaltete Produkte werden vom Kunden auf selbst verwalteten Systemen installiert und dazu zählen die Data Center- und mobilen Apps von Atlassian.
- Kritisch, Hoch, Mittel: Diese Sicherheitsrisiken sollten spätestens 90 Tage nach der Meldung im Produkt behoben sein.
- Niedrig: Diese Sicherheitsrisiken sollten spätestens 180 Tage nach der Meldung im Produkt behoben sein.
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:
- einen Bugfix-Release für den neuesten Feature-Release des betroffenen Produkts.
- einen neuen 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 Core 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 Backportierungen hängt unter anderem von komplexen Abhängigkeiten, architektonischen Änderungen und der Kompatibilität ab.
Du solltest ein Upgrade deiner installierten Produkte durchführen, sobald ein Bugfix-Release veröffentlicht wird, um sicherzugehen, dass du über die aktuellen Sicherheits-Bugfixes verfügst.
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.