Document modification date: 05/03/2025

Arcabit Quality Policy for Software Development and Updates on Endpoint Systems (SDP – Safe Deployment Practices)

Introduction

The purpose of the implemented and strictly adhered-to SDP policy is to ensure the continuous, uninterrupted, and secure operation of our Client’s Endpoint Devices and systems, regardless of the Arcabit package update processes. This applies both to updates of threat databases and updates of libraries and executable files.

Arcabit Package Updates

Arcabit package updates include:

– Threat databases (the primary update path, where new database versions are published approximately every two hours).
– Package libraries and executable files (a parallel update path initiated several times a year upon completion of the software development cycle).

Each update path follows strict testing procedures, which must be entirely and successfully completed before the update is published.

Threat Database Updates

The threat database update path encompasses all patterns, signatures, rules, and other types of data serving as input for all Arcabit protection modules. This path does not include executable files, libraries, or drivers.

Analysis

During the analysis phase, both automated and manual procedures are initiated to generate patterns, signatures, schemes, etc., enabling protection mechanisms to detect new threats.

Preliminary Testing

This phase involves testing newly generated patterns for detection effectiveness, susceptibility to false positives, and performance impact.

Repository Generation

A new update repository is created in this phase, including new and fully tested patterns.

Repository Testing (*1)

The generated repository is published in the internal test structure, followed by the initiation of an update procedure on all Arcabit-supported system versions. After the update, a detailed testing procedure is executed, covering detection tests, false positive rates, and system load impact. Each test is documented with a comprehensive report.

Publication Decision for the New Repository

Upon completion of all test procedures, the generated reports are compared with reference reports. Full compliance allows the update to be published to official repositories. Any discrepancies halt the publication process and return it to the analysis phase, along with details regarding inconsistencies.

Backup of Previous Repositories

The update system retains full versions of all published repositories for the last 30 days and includes an emergency rollback procedure to replace the current repository with a previous one if necessary.

Executable Files, Libraries, and Drivers Updates

The update of package executable files includes:

– New program features,
– Modifications to user interfaces,
– Fixes for existing modules.

Change implementations are inspired by continuous internal cybersecurity ecosystem analyses, user suggestions, detected module issues, and changes in operating system requirements.

Partial Testing

During the implementation phase, partial tests are conducted to verify and guarantee compliance with project assumptions.

Preliminary Testing

After each development cycle, preliminary test repositories are generated, containing new and modified program modules. These repositories are distributed within the internal test network, which includes instances of all supported operating systems. Changes are tested across all supported systems. Full compliance with defined standards is a prerequisite for passing the tests.

Deployment to Public Repositories

Upon successful completion of the preliminary testing phase, changes are merged with existing public repositories and enter the daily test cycle (*1). Updates are published in stages to successive client groups while simultaneously monitoring reports of potential issues.