Beveiligingsbugfixbeleid
Het is een prioriteit van Atlassian om er voor te zorgen dat de systemen van onze klanten niet in gevaar komen vanwege kwetsbaarheden in Atlassian-producten.
Scope
Het volgende beschrijft hoe en wanneer we bugs in de beveiliging van onze producten oplossen. Het beschrijft niet het volledige openbaarmakings- of adviesproces dat we doorlopen.
Beveiligingsbugfix Service Level Objectives (SLO)
Atlassian bepaalt doelstellingen op serviceniveau voor het oplossen van beveiligingsproblemen op basis van het beveiligingsniveau en het getroffen product. We hebben de volgende tijdskaders gedefinieerd voor het oplossen van beveiligingsproblemen in onze producten:
Versnelde tijdskaders voor probleemoplossing
Deze tijdskaders zijn van toepassing op alle cloudproducten van Atlassian, en op alle andere software of systemen die beheerd worden door Atlassian of werken op de infrastructuur van Atlassian. Ze zijn ook van toepassing op Jira Align (zowel de cloud als de zelfbeheerde versies).
- Bugs met ernstigheidsniveau kritiek moeten gefixt zijn in het product binnen 2 weken nadat ze geverifieerd zijn
- Bugs met ernstigheidsniveau hoog moeten gefixt zijn in het product binnen 4 weken nadat ze geverifieerd zijn
- Bugs met ernstigheidsniveau medium moeten gefixt zijn in het product binnen 6 weken nadat ze geverifieerd zijn
- Bugs met ernstigheidsniveau laag moeten gefixt zijn in het product binnen 25 weken nadat ze geverifieerd zijn
Verlengde tijdskaders voor probleemoplossing
Deze tijdskaders zijn van toepassing op alle zelfbeheerde producten van Atlassian. Een zelfbeheerd product wordt door klanten geïnstalleerd op door klanten beheerde systemen en omvat server-, datacenter- en desktop-applicaties en mobiele applicaties van Atlassian.
- Bugs met ernstigheidsniveau kritisch, hoog en medium moeten gefixt zijn in het product binnen 90 dagen nadat ze geverifieerd zijn
- Bugs met ernstigheidsniveau laag moeten gefixt zijn in het product binnen 180 dagen nadat ze geverifieerd zijn
Kritische kwetsbaarheden
Wanneer een kritisch beveiligingslek ontdekt wordt door Atlassian of gerapporteerd wordt door een externe partij, doet Atlassian het volgende:
- Zo snel mogelijk een nieuwe, gefixte release uitbrengen voor de huidige versie van het betreffende product.
- Een nieuwe onderhoudsrelease uitgeven voor een oudere versie, zoals hier beschreven:
Product | Beleid vorige versies | Voorbeeld |
|---|---|---|
| Jira Software Server en Data Center Jira Core Server en Data Center Jira Service Management Server and Data Center (voorheen bekend als Jira Service Desk) | Nieuwe bugfixreleases uitbrengen voor:
| Als bijvoorbeeld een kritische bugfix wordt ontwikkeld op 1 januari 2020, moeten de volgende nieuwe bugfixreleases volgen:
|
| Confluence Server en Data Center | Nieuwe bugfixreleases uitbrengen voor:
| Als bijvoorbeeld een kritische bugfix wordt ontwikkeld op 1 januari 2020, moeten de volgende nieuwe bugfixreleases volgen:
|
| Bitbucket Server en Data Center | Nieuwe bugfixreleases uitbrengen voor:
| Als bijvoorbeeld een kritische bugfix wordt ontwikkeld op 1 januari 2020, moeten de volgende nieuwe bugfixreleases volgen:
Bitbucket 6.3.0 is uitgebracht op 14 mei 2019, meer dan 6 maanden voor de datum van de fix. Als het is aangeduid als een release met lange termijn-support, is ook een bugfixrelease gemaakt. |
| We releasen alleen nieuwe bugfixes voor de huidige en voorgaande functiereleaseversies. | Als bijvoorbeeld een oplossing voor een kritische beveiligingsbug voor Bamboo wordt ontwikkeld op 1 januari 2020, moeten de volgende nieuwe bugfixreleases volgen:
|
Product | Beleid vorige versies | Voorbeeld |
|---|---|---|
| Jira Software Server en Data Center Jira Core Server en Data Center Jira Service Management Server and Data Center (voorheen bekend als Jira Service Desk) Confluence Server en Data Center Bitbucket Server en Data Center Server en Data Center van Bamboo | Nieuwe bugfixreleases uitbrengen voor:
| Als een kritische bugfix is ontwikkeld op 1 januari 2020, zijn de volgende voorbeeldreleases die de bugfix zouden ontvangen:
Hieronder volgen voorbeelden van releases die geen nieuwe bugfixreleases zouden ontvangen:
|
| We releasen alleen nieuwe bugfixes voor de huidige en voorgaande functiereleaseversies. | Als bijvoorbeeld een oplossing voor een kritische beveiligingsbug voor Crowd wordt ontwikkeld op 1 januari 2020, moeten de volgende nieuwe bugfixreleases volgen:
|
ProductJira Software Server en Data Center Jira Core Server en Data Center Jira Service Desk Server en Data Center |
Beleid vorige versiesNieuwe bugfixreleases uitbrengen voor:
|
VoorbeeldAls bijvoorbeeld een kritische bugfix wordt ontwikkeld op 1 januari 2020, moeten de volgende nieuwe bugfixreleases volgen:
|
ProductConfluence Server en Data Center |
Beleid vorige versiesNieuwe bugfixreleases uitbrengen voor:
|
VoorbeeldAls bijvoorbeeld een kritische bugfix wordt ontwikkeld op 1 januari 2020, moeten de volgende nieuwe bugfixreleases volgen:
|
ProductBitbucket Server en Data Center |
Beleid vorige versiesNieuwe bugfixreleases uitbrengen voor:
|
VoorbeeldAls bijvoorbeeld een kritische bugfix wordt ontwikkeld op 1 januari 2020, moeten de volgende nieuwe bugfixreleases volgen:
Bitbucket 6.3.0 is uitgebracht op 14 mei 2019, meer dan 6 maanden voor de datum van de fix. Als het is aangeduid als een release met lange termijn-support, is ook een bugfixrelease gemaakt. |
Product |
Beleid vorige versiesWe releasen alleen nieuwe bugfixes voor de huidige en voorgaande functiereleaseversies. |
VoorbeeldAls bijvoorbeeld een oplossing voor een kritische beveiligingsbug voor Bamboo wordt ontwikkeld op 1 januari 2020, moeten de volgende nieuwe bugfixreleases volgen:
|
Het is belangrijk om de nieuwste bugfixrelease te hebben van de versie van het product dat je gebruikt (dit is een best practice). Als je bijvoorbeeld Jira Software 7.5.0 gebruikt, dien je proactief naar Jira Software 7.5.3 te upgraden. Als er een nieuwe beveiligingsbugfix uitkomt, bijv. Jira Software 7.5.4, is de delta tussen de twee versies minimaal (d.w.z. alleen de beveiligingsfix), waardoor het gemakkelijker toe te passen is.
Het proces om kritische kwetsbaarheden op te lossen is niet van toepassing op onze Atlassian Cloud-producten, aangezien deze altijd door Atlassian worden opgelost zonder dat daar verder actie van onze klanten voor nodig is.
Niet-kritische kwetsbaarheden
Wanneer een beveiligingsprobleem met een hoge, gemiddelde of lage ernst wordt ontdekt, zal Atlassian ernaar streven om een fix in de release op te nemen binnen de doelstellingen van het serviceniveau die aan het begin van dit document worden vermeld. Deze fix kan indien mogelijk ook worden meegenomen naar releases met lange termijn-support.
Je dient je installaties te upgraden zodra er een bugfixrelease beschikbaar komt, zodat je er zeker van kunt zijn dat de nieuwste beveiligingsfixes zijn toegepast.
Overige informatie
De ernstigheidsgraad van kwetsbaarheden wordt berekend op basis van Ernstigheidsniveaus voor beveiligingsproblemen.
We zullen ons beleid voortdurend blijven aanpassen op basis van feedback van klanten en eventuele wijzigingen of updates op deze pagina tonen.