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

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

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

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

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

Содержание