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
Nachfolgend wird erläutert, wie und wann wir Sicherheits-Bugs in unseren Produkten beheben. Es wird nicht der gesamte von uns befolgte Offenlegungs- oder Empfehlungsprozess beschrieben.
Service Level Objectives (SLO) für die Behebung von sicherheitsrelevanten Bugs
Atlassian legt Service Level Objectives zur Behebung von Sicherheitsschwachstellen auf Grundlage des Schweregrads und des betroffenen Produkts fest. Wir haben folgende Zeitrahmen zur Behebung von Sicherheitsproblemen in unseren Produkten festgelegt:
Verkürzte Problembehebungsfristen
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 Versionen).
- Kritisch: Bugs mit diesem Schweregrad sollten im Produkt spätestens 2 Wochen nach der Meldung behoben sein.
- Hoch: Bugs mit diesem Schweregrad sollten im Produkt spätestens 4 Wochen nach der Meldung behoben sein.
- Mittel: Bugs mit diesem Schweregrad sollten im Produkt spätestens 6 Wochen nach der Meldung behoben sein.
- Niedrig: Bugs mit diesem Schweregrad sollten im Produkt spätestens 25 Wochen nach der Meldung behoben sein.
Verlängerte Problembehebungsfristen
Diese Zeitangaben gelten für alle selbstverwalteten Produkte von Atlassian. Ein selbstverwaltetes Produkt wird vom Kunden auf ebenfalls vom Kunden verwalteten Systemen installiert. Das können die Server-, Data Center-, Desktop- und mobilen Anwendungen von Atlassian sein.
- Kritisch, Hoch, Mittel: Bugs mit diesem Schweregrad sollten im Produkt spätestens 90 Tage nach der Meldung behoben sein.
- Niedrig: Bugs mit diesem Schweregrad sollten im Produkt spätestens 180 Tage nach der Meldung behoben sein.
Kritische Sicherheitslücken
Wenn eine als "kritisch" eingestufte Sicherheitslücke von Atlassian entdeckt oder von einem Dritten gemeldet wird, ergreift Atlassian folgende Maßnahmen:
- Veröffentlichung eines neuen, korrigierten Release für die aktuelle Version des betroffenen Produkts (so früh wie möglich).
- Veröffentlichung eines neuen Wartungs-Release für eine vorherige Version wie folgt:
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:
|
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) Confluence Server und Data Center Bitbucket Server und Data Center Bamboo 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:
Für die folgenden Releases wären keine neuen Bugfix-Releases erforderlich:
|
| Wir veröffentlichen neue Bugfix-Releases nur für die vorherige Feature-Release-Version. | Angenommen, ein kritischer Sicherheits-Bugfix für Crowd wäre am 1. Januar 2020 entwickelt worden. In diesem Fall wären folgende neue Bugfix-Releases erforderlich:
|
ProduktJira Software Server und Data Center Jira Core Server und Data Center Jira Service Desk Server und Data Center |
Backport-RichtlinieVeröffentlichung von neuen Bugfix-Releases für:
|
BeispielAngenommen, ein kritischer Sicherheits-Bugfix wäre am 1. Januar 2020 entwickelt worden. In diesem Fall wären folgende neue Bugfix-Releases erforderlich:
|
ProduktConfluence Server und Data Center |
Backport-RichtlinieVeröffentlichung von neuen Bugfix-Releases für:
|
BeispielAngenommen, ein kritischer Sicherheits-Bugfix wäre am 1. Januar 2020 entwickelt worden. In diesem Fall wären folgende neue Bugfix-Releases erforderlich:
|
ProduktBitbucket Server und Data Center |
Backport-RichtlinieVeröffentlichung von neuen Bugfix-Releases für:
|
BeispielAngenommen, 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. |
Produkt |
Backport-RichtlinieWir veröffentlichen neue Bugfix-Releases nur für die vorherige Feature-Release-Version. |
BeispielAngenommen, 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:
|
Es ist wichtig, immer das neueste Bugfix-Release für die von dir genutzte Produktversion zu verwenden (dies ist eine Best Practice). Wenn du beispielsweise Jira Software 7.5.0 nutzt, solltest du proaktiv ein Upgrade auf Jira Software 7.5.3 durchführen. Wenn ein neuer Sicherheits-Bugfix veröffentlicht wird, beispielsweise Jira Software 7.5.4, sind die Unterschiede zwischen diesen zwei Versionen minimal (sie beschränken sich auf den Sicherheits-Bugfix), was die Implementierung erleichtert.
Der Prozess zur Behebung kritischer Sicherheitslücken gilt nicht für unsere Atlassian Cloud-Produkte, da bei diesen Services Problembehebungen immer durch Atlassian erfolgen, ohne dass der Kunde selbst Maßnahmen ergreifen muss.
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.
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 Sicherheitslücken wird anhand der Schweregrade für Sicherheitsprobleme berechnet.
Wir bewerten unsere Richtlinien kontinuierlich auf der Basis von Kundenfeedback und geben Neuerungen oder Änderungen auf dieser Seite bekannt.