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

# Защита при разработке

## Рецензирование кода

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

При рецензировании кода проверяются:

- корректность реализации логики и отсутствие очевидных дефектов безопасности;

- соблюдение внутренних требований к безопасной работе с пользовательским вводом, запросами к БД, сервисными интерфейсами и механизмами авторизации;

- корректность использования сторонних библиотек и внутренних API;

- отсутствие обходных решений, ослабляющих штатные механизмы безопасности платформы;

- соответствие согласованным архитектурным решениям и принятому стилю реализации.

При необходимости к рецензированию привлекаются специалисты смежных направлений, включая архитекторов, разработчиков платформенных компонентов и специалистов по информационной безопасности. Для изменений, затрагивающих механизмы аутентификации, авторизации, интеграционные API, SQL-логику и иные чувствительные участки, рецензирование выполняется с повышенным вниманием.

Результаты рецензирования учитываются при принятии решения о включении изменения в поставочную сборку. Изменения, по которым выявлены существенные замечания, подлежат доработке и повторному рассмотрению.

## Контроль сторонних библиотек и доверенного контура сборки

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

На этапе рассмотрения оцениваются:

- необходимость библиотеки;

- совместимость с технологическим стеком Global ERP;

- наличие известных уязвимостей и история их устранения;

- риски лицензирования и сопровождения.

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

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

## Статический анализ прикладного кода

Для прикладных модулей основной обязательной проверкой является статический анализ на этапе компиляции. В документации Global Framework предусмотрен отдельный раздел, посвященный статическому анализу, включая использование инструмента, добавление правил и разработку собственных правил.

Базовым инструментом статического анализа прикладного Scala-кода является wartremover. Сам инструмент позиционируется как гибкий Scala-linter, предназначенный для повышения безопасности и корректности кода; нарушения правил могут приводить к ошибке компиляции.

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

- выявление небезопасных и нежелательных конструкций на раннем этапе;

- контроль соблюдения внутренних правил написания прикладного кода;

- предотвращение включения в релиз кода, не соответствующего принятому набору ограничений;

- поддержка единообразного инженерного стиля в крупной кодовой базе.

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

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

## Анализ зависимостей и уязвимостей сторонних компонентов

Отдельный контур контроля в процессе безопасной разработки связан с составом используемых сторонних компонентов, библиотек, а также прямых и транзитивных зависимостей. Цель такого контроля — своевременно выявлять включение в поставочный контур компонентов, содержащих известные уязвимости, устаревшие версии, неподтвержденные источники происхождения либо иные технологические риски. Для этой задачи применяется анализ зависимостей класса SCA (Software Composition Analysis).

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

Проверка состава зависимостей выполняется в автоматизированном режиме в составе CI/CD-конвейера и является частью процесса сборки и поставки программного обеспечения. В рамках автоматизированного SCA-тестирования обеспечивается:

- выявление уязвимостей в используемых библиотеках и зависимостях;

- контроль версий компонентов;

- проверка соблюдения лицензионных ограничений.

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

В Global ERP такой анализ применяется:

- для релизных и предрелизных сборок;

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

- при включении новых внешних библиотек в доверенный репозиторий;

- при разборе инцидентов и адресной проверке конкретного компонента.

Для решения задач данного класса применяются специализированные средства анализа состава зависимостей и известных уязвимостей в сторонних компонентах. В качестве примера могут использоваться инструменты класса Software Composition Analysis, в том числе OWASP Dependency-Check для JVM-контуров, а также аналогичные средства для иных технологических стеков.

При необходимости заказчик может реализовать аналогичный SCA-анализ в своём контуре: платформа предоставляет информацию о составе зависимостей (SBOM).

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

## Динамический анализ веб-интерфейсов и API

Для проверки безопасности развернутых веб-интерфейсов, HTTP-сервисов и прикладных API в Global ERP применяется динамический анализ на выделенных тестовых контурах. Его задача — выявление уязвимостей, проявляющихся не в исходном коде, а в фактическом поведении приложения при обработке запросов, аутентификации, авторизации, навигации, пользовательских сценариев и интеграционных вызовов.

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

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

Для решения задач данного класса используются специализированные DAST-инструменты и прокси-средства анализа веб-приложений, например OWASP ZAP и иные аналогичные инструменты, поддерживающие автоматизированные и ручные сценарии проверки веб-контуров.

Динамический анализ не рассматривается как непрерывная проверка каждой промежуточной сборки. Его применение определяется характером изменений, уровнем риска и профилем выпускаемой версии. Динамический анализ применяется:

- перед крупными выпусками;

- при существенных изменениях пользовательского интерфейса, REST/SOAP-сервисов или механизмов аутентификации;

- при адресной проверке исправлений, связанных с информационной безопасностью;

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

## Дополнительные методы проверки безопасности

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

К дополнительным методам проверки относятся:

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

- ручная верификация сценариев аутентификации, авторизации и разграничения доступа;

- проверка устойчивости прикладных и интеграционных интерфейсов к некорректным, неполным и противоречивым запросам;

- регрессионная проверка ранее исправленных уязвимостей и связанных участков логики;

- адресная проверка изменений, затрагивающих обработку файлов, сериализацию, XML/JSON-обмен и механизмы генерации запросов.

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

## Фаззинг-тестирование

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

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

- при значимых изменениях логики обработки внешних данных;

- при изменении форматов обмена, REST/SOAP-интерфейсов, механизмов сериализации и десериализации;

- при доработках, затрагивающих загрузку файлов, XML/JSON-структур и иные потенциально чувствительные точки входа;

- при адресной проверке устойчивости компонента после исправления дефектов безопасности;

- при дополнительной проверке критичных компонентов перед крупными выпусками.

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

## Управление уязвимостями

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

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

Для каждой выявленной уязвимости фиксируются:

- идентификатор записи;

- дата регистрации;

- источник обнаружения;

- краткое описание проблемы;

- затронутый компонент, модуль или поставка;

- уровень критичности;

- техническое описание, включая предполагаемый сценарий эксплуатации и потенциальные последствия;

- идентификатор задачи и сведения об ответственном;

- сведения о повторной проверке;

- статус обработки;

- релиз компонента с исправлениями.

Уязвимости классифицируются по уровню критичности в соответствии со стандартом CVSS:

- низкий уровень;

- средний уровень;

- высокий уровень;

- критический уровень.

Критические и высокие уязвимости рассматриваются в приоритетном порядке. Уязвимости среднего и низкого уровня подлежат регистрации, учету и устранению в соответствии с внутренними регламентами сопровождения. Решение о допуске версии к поставке принимается с учетом наличия или отсутствия незакрытых уязвимостей недопустимого уровня риска.

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

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

Класс уязвимости | Уровень риска | Выявленные сценарии | Реализованные меры
--- | --- | --- | ---
Внедрение SQL-кода (`SQL Injection`) | Высокий | Возможность влияния пользовательского ввода на формируемые SQL-запросы и получение данных из БД | Параметризация запросов, централизованная валидация и экранирование пользовательских данных, аудит `ORM`-механизмов. Практические правила защиты от SQL-инъекций приведены в разделе SQL-инъекции
Недостаточная авторизация | Высокий | Выполнение пользователем действий, не соответствующих его привилегиям | Строгая серверная проверка прав доступа, централизованная ролевая модель, контроль доступа к `REST`- и `SOAP`-интерфейсам
Внедрение внешних сущностей XML (`XXE`) | Высокий / Средний | Обработка `XML`-данных с поддержкой внешних сущностей и `DTD` | Отключение обработки `DTD` и внешних сущностей, ограничение используемых форматов данных
Раскрытие информации в сообщениях об ошибках | Средний | Раскрытие установочных путей и внутренней структуры приложения | Централизованная обработка ошибок, вывод минимальной информации пользователю, регистрация подробностей только во внутренних журналах
Подделка запроса со стороны сервера (`SSRF`) | Средний | Возможность выполнения `HTTP`-запросов к внутренним сервисам | Ограничение допустимых схем и адресов, фильтрация целевых ресурсов, контроль сетевых взаимодействий
Использование ПО с известными уязвимостями | Средний | Использование уязвимых версий сторонних компонентов | Регулярный аудит зависимостей, контроль версий, регламент обновления программного обеспечения
Подбор учетных данных | Средний | Многократные попытки аутентификации через точки входа системы | Ограничение количества попыток входа, отказ от небезопасных схем аутентификации, применение защищенных механизмов входа. Раздел Защита от подбора паролей
Межсайтовое выполнение сценариев (`XSS`) | Средний | Отображение неэкранированных пользовательских данных в интерфейсе | Обязательное экранирование пользовательского ввода перед отображением. Практические правила обработки HTML-ввода приведены в разделе Защита от HTML-инъекций

## Принятие решения о выпуске

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

- успешное прохождение прикладной сборки и обязательных статических проверок;

- отсутствие неразрешенных нарушений по блокирующим правилам статического анализа;

- завершение проверки состава зависимостей для релизной сборки;

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

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

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

## Учет результатов проверок

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

## Обучение и осведомленность

Все сотрудники, участвующие в разработке, интеграции и сопровождении компонентов Global ERP, обязаны:

- проходить обучение по безопасной разработке, методам контроля кода и управления зависимостями;

- поддерживать актуальный уровень знаний о применимых угрозах и уязвимостях;

- применять полученные знания при выполнении задач, включая разработку, тестирование и приемку релизов.

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