Zasady usuwania błędów zabezpieczeń
Ochrona systemów klienta przed atakami z wykorzystaniem luk w zabezpieczeniach produktów Atlassian jest dla Atlassian sprawą priorytetową.
Zakres
W tych zasadach opisano, jak i kiedy usuwamy luki w zabezpieczeniach w naszych produktach.
Usuwanie błędów zabezpieczeń — docelowe poziomy świadczenia usług (SLO)
Atlassian wyznacza docelowe poziomy świadczenia usług dotyczące usuwania luk w zabezpieczeniach na podstawie poziomu istotności problemów z zabezpieczeniami i konkretnego produktu. W przypadku wydawania poprawek zabezpieczeń w naszych produktach zdefiniowaliśmy następujące cele dotyczące ram czasowych:
Cele usuwania błędów w trybie przyspieszonym
Przedstawione poniżej ramy czasowe dotyczą wszystkich produktów chmurowych Atlassian, a także dowolnego innego oprogramowania lub systemu zarządzanego przez Atlassian bądź działającego w oparciu o infrastrukturę Atlassian. Mają one również zastosowanie do rozwiązania Jira Align (zarówno w wersji Cloud, jak i w wersjach samodzielnie zarządzanych).
- Luki krytyczne — wprowadzenie poprawek w produkcie w ciągu 10 dni od weryfikacji
- Luki bardzo istotne — wprowadzenie poprawek w produkcie w ciągu 28 dni od weryfikacji
- Luki średnio istotne — wprowadzenie poprawek w produkcie w ciągu 84 dni od weryfikacji
- Luki mało istotne — wprowadzenie poprawek w produkcie w ciągu 175 dni od weryfikacji
Czas usuwania błędów w trybie wydłużonym
Przedstawione poniżej cele dotyczące ram czasowych mają zastosowanie do wszystkich samodzielnie zarządzanych produktów Atlassian. Produkt samodzielnie zarządzany jest instalowany przez klientów w systemach przez nich zarządzanych i obejmuje aplikacje Data Center i mobilne Atlassian.
- Luki krytyczne, bardzo istotne i średnio istotne — wprowadzenie poprawek w produkcie w ciągu 90 dni od weryfikacji
- Luki mało istotne — wprowadzenie poprawek w produkcie w ciągu 180 dni od weryfikacji
Krytyczne luki w zabezpieczeniach
W przypadku wykrycia przez Atlassian lub zgłoszenia przez stronę trzecią krytycznej luki w zabezpieczeniach Atlassian podejmie następujące działania:
- W przypadku produktów Cloud dostarczymy nową poprawioną wersję dotkniętego produktu tak szybko, jak to możliwe.
- W przypadku produktów samodzielnie zarządzanych:
- dostarczymy wydanie z poprawką błędu dla najnowszego wydania z funkcjami dotkniętego produktu;
- dostarczymy nowe wydanie z funkcjami dla dotkniętego produktu zgodnie z harmonogramem wydań;
- dostarczymy wydanie z poprawką błędu dla wszystkich obsługiwanych wydań LTS dotkniętego produktu zgodnie z polityką dotyczącą zakończenia wsparcia Atlassian.
Produkt | Zasady backportowania | Przykład |
|---|---|---|
| Jira Software Server i Data Center Jira Core Server i Data Center Jira Service Management Server i Data Center (dawniej Jira Service Desk) | Udostępnienie nowych wydań z poprawką błędu dla:
| Przykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
|
| Confluence Server i Data Center | Udostępnienie nowych wydań z poprawką błędu dla:
| Przykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
|
| Bitbucket Server i Data Center | Udostępnienie nowych wydań z poprawką błędu dla:
| Przykładowo, jeśli krytyczna poprawka zabezpieczeń została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
Bitbucket 6.3.0 wydano 14 maja 2019 roku, ponad sześć miesięcy przed datą poprawki. Gdyby ta wersja była oznaczona jako wersja ze wsparciem długoterminowym, utworzono by również wydanie z poprawką błędu. |
| Udostępnienie nowych wydań z poprawką błędu jedynie dla bieżącej i poprzedniej wersji wydania z funkcjami. | Przykładowo, jeśli krytyczna poprawka zabezpieczeń dla rozwiązania Bamboo została opracowana 1 stycznia 2020 roku, konieczne będzie utworzenie następujących nowych wydań z poprawką błędu:
|
W przypadku produktów Crowd, Fisheye i Crucible udostępnimy wydanie z poprawką błędu dla najnowszego wydania z funkcjami dotkniętego produktu.
Przykłady poprawek krytycznych luk w zabezpieczeniach dla produktów samodzielnie zarządzanych:
Jeśli poprawka krytycznej luki w zabezpieczeniach została opracowana 1 stycznia 2024 roku, otrzymają ją przykładowo następujące wydania:
Produkt | Przykład |
|---|---|
| Jira Software | Przykład Jira Software 9.13.x, ponieważ 9.13.0 jest najnowszym wydaniem z funkcjami. |
| Przykład Jira Software 9.12.x, ponieważ 9.12.0 jest najnowszym wydaniem ze wsparciem długoterminowym (LTS). | |
| Przykład Jira Software 9.4.x, ponieważ 9.4.0 jest poprzednim wydaniem ze wsparciem długoterminowym (LTS). | |
| Jira Service Management | Przykład Jira Service Management 5.13.x, ponieważ 5.13.0 jest najnowszym wydaniem z funkcjami. |
| Przykład Jira Service Management 5.12.x, ponieważ 5.12.0 jest najnowszym wydaniem ze wsparciem długoterminowym (LTS). | |
| Przykład Jira Service Management 5.4.x, ponieważ 5.4.0 jest drugim najnowszym obsługiwanym wydaniem ze wsparciem długoterminowym (LTS). | |
| Confluence | Przykład Confluence 8.7.x, ponieważ 8.7.0 jest najnowszym wydaniem z funkcjami. |
| Przykład Confluence 8.5.x, ponieważ 8.5.0 jest najnowszym wydaniem ze wsparciem długoterminowym (LTS). | |
| Przykład Confluence 7.19.x, ponieważ 7.19.0 jest drugim najnowszym obsługiwanym wydaniem ze wsparciem długoterminowym (LTS). | |
| Bitbucket | Przykład Bitbucket 8.17.x, ponieważ 8.17.0 jest najnowszym wydaniem z funkcjami. |
| Przykład Bitbucket 8.9.x, ponieważ 8.9.0 jest najnowszym wydaniem ze wsparciem długoterminowym (LTS). | |
| Przykład Bitbucket 7.21.x, ponieważ 7.21.0 jest drugim najnowszym obsługiwaną wydaniem ze wsparciem długoterminowym (LTS). | |
| Bamboo | Przykład Bamboo 9.5.x, ponieważ 9.5.0 jest najnowszym wydaniem z funkcjami. |
| Przykład Bamboo 9.2.x, ponieważ 9.2.0 jest najnowszym wydaniem ze wsparciem długoterminowym (LTS). | |
| Crowd | Przykład Crowd 5.3.x, ponieważ 5.3.0 jest najnowszym wydaniem z funkcjami. |
| Fisheye/Crucible | Przykład Fisheye/Crucible 4.8.x, ponieważ 4.8.0 jest najnowszym wydaniem z funkcjami. |
Żadne inne wersje produktów nie otrzymają nowych poprawek błędów.
Częste aktualizacje zapewniają bezpieczeństwo instancji produktów. Najlepiej jest pozostać przy najnowszym wydaniu poprawki błędu najnowszego wydania z funkcjami lub wydania LTS produktu.
Niekrytyczne luki w zabezpieczeniach
W przypadku wykrycia bardzo istotnych, średnio istotnych lub mało istotnych problemów z zabezpieczeniami Atlassian będzie dążyć do wydania poprawki w terminach określonych w docelowych poziomach świadczenia usług wymienionych na początku tego dokumentu. Jeśli jest to wykonalne, możliwe jest również backportowanie poprawki do wydania ze wsparciem długoterminowym. Możliwość backportowania zależy między innymi od złożonych zależności, zmian architektonicznych i zgodności.
Po udostępnieniu wydania z poprawką błędu należy uaktualnić instalacje, aby mieć pewność, że zostały zastosowane najnowsze poprawki zabezpieczeń.
Inne informacje
Poziom istotności luk w zabezpieczeniach jest obliczany na podstawie poziomów istotności problemów z zabezpieczeniami.
Będziemy poddawać nasze zasady ciągłej ewaluacji w oparciu o opinie klientów, a na tej stronie będziemy zamieszczać wszelkie aktualności lub zmiany.