Just Published! Threat Report: Exposing Malware in Linux-Based Multi-Cloud Environments | Download Now

Carbon Black EDR Product Support Lifecycle Policy

Carbon Black EDR Product Support Lifecycle Policy

Overview

Policy Effective Date: February 2020 

This policy applies to customers with an active maintenance contract for VMware Carbon Black EDR (formerly CB Response). The policy is the same for both VMware Carbon Black EDR Server and VMware Carbon Black EDR Sensors. VMware Carbon Black Hosted EDR (formerly CB Response Cloud) Servers are maintained and upgraded by VMware Carbon Black and will always be on Latest. The intent of this policy is to provide consistent and predictable guidelines for product support throughout the product’s lifecycle to allow our customers to strategically plan for upgrades and improve their security posture through consistent updates. 

These terms apply to all VMware Carbon Black EDR releases.

Current product release status can be found at VMware Carbon Black EDR Support Versions Grid.

Version Definition

A Version refers to the unique series of numbers indicating, at a glance, the scope of what was changed.

Carbon Black EDR versions its products with 3 sets of numbers: XX.YY.ZZ. Each set of numbers presents an epoch in the product lifecycle

  • XX - Platform Release
  • YY - Feature Release
  • ZZ - Bug Fix / Maintenance Release

Note that each piece of VMware Carbon Black EDR (the server, macOS sensor, Windows sensor, and Linux sensors) are all released on their own schedules.  A release of the server does not necessarily mean a release of new sensors and a release of a new sensor does not mean other sensors are getting new versions at the same time, nor that a new server will be released at the same time. 

Version Numbering Definitions

XX = Platform 

A platform release includes significant architectural changes including the addition of or replacement of significant features. Examples include deprecating APIs version, changes to the product architecture, or dramatic changes to the look and feel of the product. A platform release might have limited or no backwards compatibility with the previous platform version due to these changes. Updating this number will trigger a new supported release window. 

YY = Feature 

A feature release includes new functionality, features and bug fixes or replaces functionality, features, and bug fixes.  This could include things like UX updates, major 3rd party package updates, or removal of legacy features. Updating this number will trigger a new supported release window. 

ZZ = Maintenance 

A maintenance release contains bug fixes, stability and performance improvements, or minor updates to features. We recommend that customers always install the latest maintenance version. Please note that maintenance releases do not reset the support timeline. Only a Feature or a Platform release triggers a new support timeline. 

Latest Version

The term “Latest Version” refers to the highest version number. New releases are always made on the latest version. 

Feature Series

The term “Feature Series” refers to a specific Feature Release -- such as 6.2.x or 6.3.x. 

Product Support Lifecycle

Standard Support

Carbon Black will provide standard support on the latest feature version and two versions back, or at least 1 year, whichever is longer. During this period of standard support, customers may call support and receive assistance on a version in Standard support, however Carbon Black does not provide support for versions of the software more than two versions back from the latest feature release, unless that version was GA’d less than one year ago. 

Bugs identified in any supported versions will be addressed in the next maintenance version for latest feature version. Note, maintenance release (3rd number in the version number) do not reset the Standard Support countdown for the Feature Release. After the 3rd future version or at least 1 year has passed, that version will enter End of Support and Carbon Black will no longer provide support. 

For example, Carbon Black EDR could support a 6.1.x, 6.2.x version. A customer identifies an issue in 6.1.3. We will release the fix for the issue in the next maintenance release of the 6.2.x server. To receive the bug fix, the customer must update to the latest maintenance version in the latest feature series. In this case, this would be the 6.2.x series server because that’s our latest feature version. 

  • In extraordinary cases, Carbon Black may opt, at its discretion, to back-port critical features to any version still in standard support.

At any given time, we will only release maintenance releases on the Latest Version. 

The sensors and the server maintain their own support schedules based on their release schedule. Moving a server to end of support does not mean that a sensor is moving to end of support or vice versa. 

Legacy OS Support

Carbon Black may elect, at its discretion, to maintain multiple sensors versions in Standard Support for a single platform to maintain support for legacy operating systems. The Legacy OS Support Version will receive maintenance releases for critical bug fixes, security vulnerabilities and OS currency at Carbon Black’s discretion. 

Carbon Black evaluates the Lifecycle of each Legacy Support Version for sensors individually and so no overarching statement on support applies. However, Carbon Black will strive to provide at least 6-months notice prior to moving a Legacy OS Support Version to End of Support. 

End of Support

Following Standard Support, product releases will enter End of Support. A Carbon Black EDR release will enter End of Support on the last day of the month it's scheduled to enter End of Support. That means the version slated to End of Support in March 2020 will receive support until March 31 2020 at 11:59p ET. At April 1 2020 at 12:00a ET, the version will enter End of Support. Carbon Black will provide no active technical support for product releases after entering End of Support.

End of Support entails the following:

  • Support cases will not be opened
    • Existing support cases that are open at the time that the version goes End of Support will still be worked to completion-- however no new support cases will be opened on that version. 
  • Customers will have access to existing technical articles and support documentation available in our Knowledge Base available on our customer support sites
  • Customers will be advised to upgrade to a version in Standard support

 

Supportability Matrix

Standard

End of Support

Technical Support

Yes

No

Knowledge-base Access

Yes

Yes

User Forum Access

Yes

Yes

Product Documentation

Yes

As available

Defect resolution

Yes

No

 

Documentation Versioning

Documentation will be versioned with each feature release. A single Feature version of the document will be continually updated to include any changes from maintenance releases. In the past, we versioned documentation for each maintenance release. So for example, 6.2.0, 6.2.1, 6.2.2, 6.2.3 and 6.2.4 all have their own versioned documentation. Going forward, we will have a single document, 6.2 Feature release that contains all the changes from the 6.2.0 - 6.2.4 release.  This should help cut down on the overall number of documents and make it easier to find the information that customers need to find. 

In the old method, documentation versioned for each feature and maintenance release:

We currently have versioned documentation for:  

  • 6.2.0
  • 6.2.1
  • 6.2.2
  • 6.2.3
  • 6.2.4 

In the new methodology, each Feature release gets version documentation, but maintenance releases do not.  In the new model, the entire 6.2.x series would be contained in a single 6.2 document. The documentation would then version to 6.3 and would contain updates for all maintenance release in the 6.3.x series. 

Labels (2)
Article Information
Author:
Creation Date:
‎11-13-2019
Views:
4175