Security Bug Fix Policy
Atlassian makes it a priority to ensure that customers' systems cannot be compromised by exploiting vulnerabilities in Atlassian products.
Scope
The following describes how and when we resolve security bugs in our products. It does not describe the complete disclosure or advisory process that we follow.
Security bug fix Service Level Objectives (SLO)
Atlassian sets service level objectives for fixing security vulnerabilities based on the security severity level and the affected product. We have defined the following timeframes for fixing security issues in our products:
Accelerated Resolution Timeframes
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 versions).
- Critical severity bugs to be fixed in product within 14 days of being verified
- High severity bugs to be fixed in product within 28 days of being verified
- Medium severity bugs to be fixed in product within 42 days of being verified
- Low severity bugs to be fixed in product within 175 days of being verified
Extended Resolution Timeframes
These timeframes apply to all self-managed Atlassian products. A self-managed product is installed by customers on customer-managed systems, and includes Atlassian's server, data center, desktop, and mobile applications.
- Critical, High, and Medium severity bugs to be fixed in product within 90 days of being verified
- Low severity bugs to be fixed in product within 180 days of being verified
Critical Vulnerabilities
When a Critical security vulnerability is discovered by Atlassian or reported by a third party, Atlassian will do all of the following:
- Issue a new, fixed release for the current version of the affected product as soon as possible.
- Issue a new maintenance release for a previous version as follows:
Product | Back port policy | Example |
|---|---|---|
| Jira Software Server and Data Center Jira Core Server and Data Center Jira Service Management Server and Data Center (previously known as Jira Service Desk) | Issue new bug fix releases for:
| For example, if a critical security bug fix is developed on 1 January 2020, the following new bug fix releases would need to be produced:
|
| Confluence Server and Data Center | Issue new bug fix releases for:
| For example, if a critical security bug fix is developed on 1 January 2020, the following new bug fix releases would need to be produced:
|
| Bitbucket Server and Data Center | Issue new bug fix releases for:
| For example, if a critical security bug fix is developed on 1 January 2020, the following new bug fix releases would need to be produced:
Bitbucket 6.3.0 was released on 14 May 2019, more than 6 months before the date of the fix. If it was designated a Long Term Support release, a bug fix release would also be produced. |
| We will only issue new bug fix releases for the current and previous feature release version. | For example, if a critical security bug fix is developed on 1 January 2020 for Bamboo, the following new bug fix releases would need to be produced:
|
Product | Back port policy | Example |
|---|---|---|
| Jira Software Server and Data Center Jira Core Server and Data Center Jira Service Management Server and Data Center (previously known as Jira Service Desk) Confluence Server and Data Center Bitbucket Server and Data Center Bamboo Server and Data Center | Issue new bug fix releases for:
| If a critical security bug fix is developed on 2020/01/01, the following are example releases that would receive the bug fix:
The following are examples of releases that would not receive new bug fix releases:
|
| We will only issue new bug fix releases for the current and previous feature release version. | For example, if a critical security bug fix is developed on 1 January 2020 for Crowd, the following new bug fix releases would need to be produced:
|
ProductJira Software Server and Data Center Jira Core Server and Data Center Jira Service Desk Server and Data Center |
Back port policyIssue new bug fix releases for:
|
ExampleFor example, if a critical security bug fix is developed on 1 January 2020, the following new bug fix releases would need to be produced:
|
ProductConfluence Server and Data Center |
Back port policyIssue new bug fix releases for:
|
ExampleFor example, if a critical security bug fix is developed on 1 January 2020, the following new bug fix releases would need to be produced:
|
ProductBitbucket Server and Data Center |
Back port policyIssue new bug fix releases for:
|
ExampleFor example, if a critical security bug fix is developed on 1 January 2020, the following new bug fix releases would need to be produced:
Bitbucket 6.3.0 was released on 14 May 2019, more than 6 months before the date of the fix. If it was designated a Long Term Support release, a bug fix release would also be produced. |
Product |
Back port policyWe will only issue new bug fix releases for the current and previous feature release version. |
ExampleFor example, if a critical security bug fix is developed on 1 January 2020 for Bamboo, the following new bug fix releases would need to be produced:
|
It is important to stay on the latest bug fix release for the version of the product you are using (this is best practice). For example if you are on Jira Software 7.5.0, you should upgrade to Jira Software 7.5.3 proactively. If a new security bug fix is released, e.g. Jira Software 7.5.4, the delta between the two versions is minimal (i.e. only the security fix), making it easier to apply.
The critical vulnerabilities resolution process does not apply to our Atlassian Cloud products as these services are always fixed by Atlassian without any additional action from customers.
Non-critical vulnerabilities
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.
You should upgrade your installations when a bug fix release becomes available to ensure that the latest security fixes have been applied.
Other information
Severity level of vulnerabilities is calculated based on Severity Levels for Security Issues.
We will continuously evaluate our policies based on customer feedback and will provide any updates or changes on this page.