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.
Security bug fix service level objectives (SLOs)
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
These timeframes apply to:
- Wszystkich produktów chmurowych Atlassian
- Any software or system managed by Atlassian
- Any software or system running on Atlassian infrastructure
- Jira Align, cloud and self-managed releases
Depending on the vulnerability level, we defined the following timelines for applying the fix in a product after verifying:
- Critical - 14 days
- High - 28 days
- Medium - 42 days
- Low - 175 days
Czas usuwania błędów w trybie wydłużonym
These timeframe objectives apply to all Data Center Atlassian products. Data center products are installed by customers on customer-managed systems and include Atlassian's Data Center and mobile apps.
- Critical, High, and Medium severity vulnerabilities to be fixed in a product within 90 days of being verified
- Low severity vulnerabilities to be fixed in a product within 180 days of being verified
Shared responsibility model
While Atlassian is committed to delivering secure products out of the box, we also rely on a shared responsibility model. This model requires customers to implement practices that continue beyond deployment and extend into operational phases. Some of these responsibilities include:
- Operating Atlassian software on private networks.
- Ensuring timely implementation of security fixes once they're released.
- Configuring Web Application Firewalls (WAF), VPNs, multi-factor authentication, and single sign-on.
- Implementing encryption and access controls.
- Performing regular backups.
- Conducting regular security audits.
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:
- Ship a bug fix release for the latest feature release of the affected product.
- Ship a new feature release for the affected product on the release schedule.
- 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 Server and 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
When a security issue of High, Medium, or Low severity is discovered, Atlassian will aim to release a fix within the service level objectives listed at the beginning of this document. If feasible, the fix may also be backported to Long-Term Support releases. The feasibility of backporting is influenced by a variety of factors, including software dependencies, architectural modifications, and compatibility issues, among others.
To ensure your installations contain the latest security fixes, upgrade them whenever a bug fix release becomes available.
Inne informacje
Poziom istotności luk w zabezpieczeniach jest obliczany na podstawie poziomów istotności problemów z zabezpieczeniami.
We'll continuously evaluate our policies based on customer feedback and provide any updates or changes on this page.