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
This policy describes how and when we may resolve security vulnerabilities in our products.
Usuwanie błędów zabezpieczeń — docelowe poziomy świadczenia usług (SLO)
Atlassian sets service level objectives for fixing security vulnerabilities based on the security severity level and the affected product. We've defined the following timeframe objectives for fixing security issues in our products:
Accelerated Resolution Objectives
These timeframes apply to all cloud-based Atlassian products, and any other software or system that is managed by Atlassian, or is running on Atlassian infrastructure. They also apply to Jira Align (both the cloud and self-managed releases).
- Critical vulnerabilities to be fixed in product within 10 days of being verified
- High vulnerabilities to be fixed in product within 28 days of being verified
- Medium vulnerabilities to be fixed in product within 84 days of being verified
- Low vulnerabilities to be fixed in product within 175 days of being verified
Czas usuwania błędów w trybie wydłużonym
These timeframe objectives apply to all self-managed Atlassian products. A self-managed product is installed by customers on customer-managed systems and includes Atlassian's Data Center and mobile apps.
- Critical, High, and Medium vulnerabilities to be fixed in product within 90 days of being verified
- Low vulnerabilities to be fixed in product within 180 days of being verified
Krytyczne luki w zabezpieczeniach
When a critical vulnerability is discovered by Atlassian or reported by a third party, Atlassian will take the following actions:
- For cloud products, we will ship a new fixed release for the affected product as soon as possible
- For self-managed products, we will:
- 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
- ship a bug fix release for all supported LTS releases of the affected product, in accordance with the Atlassian Support End of Life Policy.
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.
Examples of critical vulnerability fixes for self-managed products:
If a critical vulnerability fix is developed on Feb 1, 2024, the following are example releases that would receive the bug fix:
Produkt | Przykład |
|---|---|
| Jira Software | Przykład Jira Software 9.13.x because 9.13.0 is the latest feature release |
| Przykład Jira Software 9.12.x because 9.12.0 is the latest Long Term Support release | |
| Przykład Jira Software 9.4.x because 9.4.0 is the previous Long Term Support release | |
| Jira Service Management | Przykład Jira Service Management 5.13.x because 5.13.0 is the latest feature release |
| Przykład Jira Service Management 5.12.x because 5.12.0 is the latest Long Term Support release | |
| Przykład Jira Service Management 5.4.x because 5.4.0 is the second latest supported Long Term Support release | |
| Confluence | Przykład Confluence 8.7.x because 8.7.0 is the latest feature release |
| Przykład Confluence 8.5.x because 8.5.0 is the latest Long Term Support release | |
| Przykład Confluence 7.19.x because 7.19.0 is the second latest supported Long Term Support release | |
| Bitbucket | Przykład Bitbucket 8.17.x because 8.17.0 is the latest feature release |
| Przykład Bitbucket 8.9.x because 8.9.0 is the latest Long Term Support release | |
| Przykład Bitbucket 7.21.x because 7.21.0 is the second latest supported Long Term Support release | |
| Bamboo | Przykład Bamboo 9.5.x because 9.5.0 is the latest feature release |
| Przykład Bamboo 9.2.x because 9.2.0 is the latest Long Term Support release | |
| Crowd | Przykład Crowd 5.3.x because 5.3.0 is the latest feature release |
| Fisheye/Crucible | Przykład 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
When a security issue of a 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. The fix may also be backported to Long Term Support releases, if feasible. The feasibility of backporting depends on complex dependencies, architectural changes, and compatibility, among other factors.
Po udostępnieniu wydania z poprawką błędu należy uaktualnić instalacje, aby mieć pewność, że zostały zastosowane najnowsze poprawki zabezpieczeń.
Inne informacje
The severity level of vulnerabilities is calculated based on Severity Levels for Security Issues.
We'll continuously evaluate our policies based on customer feedback and will provide any updates or changes on this page.