Перейти к основному содержанию
`Ctrl`+`K`

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

В 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 — система оценки критичности уязвимостей.

- Фаззинг-тестирование — метод проверки устойчивости компонента к некорректным, неожиданным или специально искаженным входным данным.

- Доверенный контур сборки — контролируемый набор репозиториев, зависимостей и процедур, используемых для формирования поставочных сборок.