# Общие положения

В Global ERP безопасная разработка является неотъемлемой частью инженерного процесса. Раздел устанавливает обязательные требования и принципы безопасной разработки для сотрудников и контрагентов, участвующих в создании, интеграции, тестировании, выпуске и сопровождении прикладных решений и компонентов платформы Global ERP.

Цель раздела — формализация процесса безопасной разработки, снижение риска включения в поставку уязвимого прикладного кода и непроверенных сторонних компонентов, а также обеспечение единого подхода к контролю безопасности на всех этапах жизненного цикла разработки. Раздел систематизирует реализованные в системе меры, применяемые в рамках подхода *security by design*, а также процесс централизованного учета и устранения выявленных уязвимостей.

## Область применения

Раздел применяется ко всем подразделениям, сотрудникам и внешним контрагентам, участвующим в:

- разработке, интеграции и сопровождении прикладных решений и компонентов платформы Global ERP;
- включении сторонних библиотек и компонентов в поставочный контур;
- сопровождении и выпуске релизов системы, в рамках которых изменяются код, зависимости или конфигурация;
- тестировании, анализе и устранении уязвимостей на всех этапах жизненного цикла.

## Подход к безопасной разработке

Подход к безопасной разработке учитывает архитектуру платформы Global ERP: система использует СУБД PostgreSQL / Postgres Pro, сервер приложений и браузерный клиент, а прикладные решения и интеграционные компоненты поставляются в составе общей системы. В связи с этим контроль безопасности строится вокруг трех основных направлений:

- проверка прикладного кода;
- проверка сторонних зависимостей;
- проверка поведения развернутых веб-интерфейсов и API.

## Основные принципы

Внутренний процесс безопасной разработки строится на следующих принципах:

- проверка безопасности выполняется на нескольких этапах жизненного цикла: при разработке, при сборке, перед выпуском и после устранения выявленных замечаний;
- для прикладного кода применяется обязательный статический анализ;
- изменения прикладного кода проходят рецензирование перед включением в поставочный контур;
- для сторонних библиотек применяется отдельный контроль состава зависимостей;
- для веб-интерфейсов и HTTP/API-контуров применяется динамическая проверка на выделенном стенде;
- для отдельных компонентов и значимых изменений может применяться фаззинг-тестирование как дополнительный метод проверки устойчивости к некорректным и специально искаженным входным данным;
- все новые внешние библиотеки проходят архитектурное согласование до включения в доверенный контур сборки.

Точные правила срабатывания, внутренние профили сканирования, наборы правил проверки и настройки доверенных репозиториев не раскрываются в открытой эксплуатационной документации.

## Ответственность участников процесса

Распределение ответственности между ролями не исключает совместного участия в процессе безопасной разработки. Все участники процесса обязаны соблюдать требования раздела в пределах своей компетенции.

### Разработчик

Осуществляет разработку и изменение прикладного кода, обеспечивает соблюдение требований безопасной разработки, прохождение статического анализа и устранение выявленных уязвимостей, а также обосновывает использование сторонних библиотек.

### Архитектор

Осуществляет согласование использования сторонних компонентов, оценивает архитектурные и технологические риски и принимает решение о включении библиотек в доверенный контур сборки.

### Инженер по тестированию

Участвует в обеспечении безопасности за счет выполнения проверок в процессе тестирования, проведения динамического анализа и верификации исправлений уязвимостей.

### Специалист по информационной безопасности

Обеспечивает методологическую поддержку процесса, участвует в анализе уязвимостей и инцидентов, проводит адресные проверки и формирует рекомендации по снижению рисков.

### Ответственный за релиз

Контролирует прохождение обязательных проверок, учитывает результаты анализа и принимает решение о допуске версии к поставке либо о возврате на доработку.

## Нормативная база

Процесс безопасной разработки реализуется с учетом следующих нормативных документов:

- Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» в части требований к безопасной разработке и жизненному циклу программного обеспечения;
- внутренние нормативные документы ООО «Бизнес Технологии» по информационной безопасности и качеству разработки;
- руководство по безопасной эксплуатации и сопровождению компонентов;
- рекомендации OWASP.

## Термины и сокращения

В разделе используются следующие термины и сокращения:

- **CI/CD** — конвейер автоматизированной сборки, проверки и поставки программного обеспечения.
- **SCA** (*Software Composition Analysis*) — анализ состава сторонних компонентов и зависимостей на наличие известных уязвимостей, устаревших версий и лицензионных ограничений.
- **DAST** (*Dynamic Application Security Testing*) — динамический анализ безопасности развернутых веб-интерфейсов, HTTP-сервисов и прикладных API.
- **SBOM** (*Software Bill of Materials*) — сведения о составе зависимостей и компонентов поставки.
- **CVSS** — система оценки критичности уязвимостей.
- **Фаззинг-тестирование** — метод проверки устойчивости компонента к некорректным, неожиданным или специально искаженным входным данным.
- **Доверенный контур сборки** — контролируемый набор репозиториев, зависимостей и процедур, используемых для формирования поставочных сборок.