FortiEDR's software and content update release process

[ShaharRazon]

In light of recent cybersecurity events, we would like to remind FortiEDR customers and partners about our software and content update release process, as well as our overarching release strategy. The following overview will detail our various release types, our systematic release process, and the measures we take to mitigate associated risks. 

1. Release types: 
   We classify FortiEDR releases into three categories: Major, Minor, and Patch. 
   1. Major and Minor releases undergo comprehensive QA cycles, followed by internal deployments where the system is tested in our own production environment for several months. 
   2. Patch releases address a limited set of bugs and are considered less risky. These releases go through QA cycles that focus on the impact of the changed modules and include overall sanity checks. Similar to Major and Minor releases, Patch releases are tested internally for at least a few weeks before being deployed in production. 
2. Development and QA cycle: 
   To begin with, FortiEDR's development approach includes longevity testing for each release, including content updates to validate system stability or serviceability features over a long period of time. While many tests are automated, we also perform manual QA including PSIRT vulnerability testing.After QA completes its test cycles and the release is approved, the software or content is promoted to Limited Availability (LA). During this phase, it is deployed in small numbers in production and closely monitored by our production management team. Once the release meets the specified KPIs, it is promoted to General Availability (GA) and gradually deployed in larger quantities. Deployment in subsequent batches occurs only after the KPI criteria are met for the previous batch. 
3. Fail-safe mechanism: 
   FortiEDR incorporates two fail-safe mechanisms in our system
   1. Process: We do not fully automate deployment, even for GA releases. We continuously monitor and measure our system as deployment scales up. 
   2. Software: As FortiEDR is kernel-based, and since kernel bugs can cause BSOD (Blue Screen of Death), we have developed an internal mechanism to identify recurring BSOD events. If detected, this mechanism disables the kernel component. In such cases, the machine will reboot in safe mode while FortiEDR’s user space service will continue to run and communicate with its management console. 

Shahar Razon