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
Poniżej opisano, w jaki sposób i kiedy usuwamy błędy zabezpieczeń w naszych produktach. Nie jest to opis pełnego procesu ujawniania lub ostrzeżeń, który stosujemy.
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 ramy czasowe:
Czas 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).
- Błędy krytyczne — usunięcie z produktu w ciągu 14 dni od weryfikacji
- Błędy bardzo istotne — usunięcie z produktu w ciągu 28 dni od weryfikacji
- Błędy średnio istotne — usunięcie z produktu w ciągu 42 dni od weryfikacji
- Błędy mało istotne — usunięcie z produktu w ciągu 175 dni od weryfikacji
Czas usuwania błędów w trybie wydłużonym
Przedstawione poniżej ramy czasowe dotyczą 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 serwerowe, do centrów danych, komputerowe i mobilne Atlassian.
- Błędy krytyczne, bardzo istotne i średnio istotne — usunięcie z produktu w ciągu 90 dni od weryfikacji.
- Błędy mało istotne — usunięcie z produktu 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 kroki:
- Możliwie jak najszybciej udostępni nowe, poprawione wydanie bieżącej wersji produktu, którego dotyczy problem.
- Opublikuje nowe wydanie poprawiające poprzednią wersję zgodnie z następującym schematem:
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:
|
For Crowd, Fisheye, and Crucible, we will provide a bug fix release for the latest feature release of the affected product.
Ważne, aby korzystać z najnowszego wydania z poprawkami błędów używanej wersji produktu (jest to najlepsza praktyka). Przykładowo klienci korzystający z rozwiązania Jira Software 7.5.0, powinni proaktywnie dokonać uaktualnienia do wersji Jira Software 7.5.3. W przypadku wydania nowej poprawki zabezpieczeń, np. Jira Software 7.5.4, różnica między dwoma wersjami będzie minimalna (tj. będzie to wyłącznie poprawka zabezpieczeń), co ułatwi jej zastosowanie.
Proces eliminowania krytycznych luk w zabezpieczeniach nie ma zastosowania do produktów Atlassian Cloud, ponieważ poprawki w tych usługach są zawsze wprowadzane przez Atlassian, bez konieczności podejmowania jakichkolwiek działań przez klientów.
Product | Example |
|---|---|
| Jira Software | Example Jira Software 9.13.x because 9.13.0 is the latest feature release |
| Example Jira Software 9.12.x because 9.12.0 is the latest Long Term Support release | |
| Example Jira Software 9.4.x because 9.4.0 is the previous Long Term Support release | |
| Jira Service Management | Example Jira Service Management 5.13.x because 5.13.0 is the latest feature release |
| Example Jira Service Management 5.12.x because 5.12.0 is the latest Long Term Support release | |
| Example Jira Service Management 5.4.x because 5.4.0 is the second latest supported Long Term Support release | |
| Confluence | Example Confluence 8.7.x because 8.7.0 is the latest feature release |
| Example Confluence 8.5.x because 8.5.0 is the latest Long Term Support release | |
| Example Confluence 7.19.x because 7.19.0 is the second latest supported Long Term Support release | |
| Bitbucket | Example Bitbucket 8.17.x because 8.17.0 is the latest feature release |
| Example Bitbucket 8.9.x because 8.9.0 is the latest Long Term Support release | |
| Example Bitbucket 7.21.x because 7.21.0 is the second latest supported Long Term Support release | |
| Bamboo | Example Bamboo 9.5.x because 9.5.0 is the latest feature release |
| Example Bamboo 9.2.x because 9.2.0 is the latest Long Term Support release | |
| Crowd | Example Crowd 5.3.x because 5.3.0 is the latest feature release |
| Fisheye/Crucible | Example Fisheye/Crucible 4.8.x because 4.8.0 is the latest feature release |
No other product versions would receive new bug fixes.
Frequent upgrades ensure that your product instances are secure. It's a best practice to stay on the latest bug fix release of the latest feature release or LTS release of your product.
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 wersji ze wsparciem długoterminowym.
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.