Безопасность в основе заказной разработки программного обеспечения

Безопасность в основе заказной разработки программного обеспечения

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

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

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

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

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

Выбор компонентов для будущей системы происходит с учетом их защищенности и пригодности к сертификации: какие библиотеки, фреймворки и сторонние решения соответствуют требованиям регуляторов (ФСТЭК, ФСБ) и не создают скрытых рисков. В проектах с высокими требованиями к безопасности предпочтение отдается компонентам, которые прошли независимую оценку или имеют действующие сертификаты. Есть опыт приведения в соответствие требованиям и сертификации новых компонентов в составе разрабатываемых информационных систем.

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

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

Конвейер безопасной разработки (РБПО)

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

В типовом пайплайне последовательно выполняются несколько категорий проверок. На этапе коммита подключаются линтеры для анализа стиля кода и поиска секретов, а также инструменты статического анализа (SAST), которые выявляют потенциальные уязвимости в исходном коде до сборки. После успешной компиляции запускаются unit-тесты и интеграционные тесты, которые проверяют как функциональность, так и корректность взаимодействия с внешними сервисами – базами данных, брокерами сообщений. Далее следует упаковка сервиса в Docker-образ или другой артефакт с сохранением в хранилище. На этапе развертывания на тестовых и предпродуктивных окружениях проводятся динамический анализ (DAST), нагрузочное тестирование и в отдельных случаях фаззинг.

Ключевым элементом управления уязвимостями сновится централизованная ASOC-платформа (Application Security Orchestration and Correlation), которая выступает единой точкой истины. Все результаты сканирований – от SAST, SCA, DAST и других инструментов – стекаются в нее, коррелируются и дедуплицируются. Без такой платформы сопоставление сотен тысяч находок из разных источников потребовало бы непропорциональных трудозатрат. ASOC позволяет отслеживать состояние защищенности по каждому проекту, автоматически обновлять данные при новых сборках и доставлять разработчикам актуальные результаты именно по их участку работы.

Для управления компонентами открытого происхождения используются фреймворки SBOM (Software Bill of Materials) и VEX (Vulnerability Exploitability Exchange). SBOM формирует структурированный перечень всех сторонних библиотек и зависимостей, входящих в сборку. VEX дополняет его оценкой реальной критичности каждой найденной уязвимости: не всякая CVE требует немедленного исправления, если уязвимый код не вызывается в проекте или не влияет на его безопасность. Такой подход позволяет не тратить ресурсы на ложные срабатывания и сосредоточиться на тех рисках, которые действительно угрожают системе.

Интеграция безопасной разработки в культуру и инженерные принципы

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

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

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

Мы также развиваем практику, когда внутри команд разработки появляются специалисты с углубленными компетенциями в области ИБ – секьюрити-чемпионы. Они консультируют коллег, помогают интерпретировать результаты сканеров и принимают оперативные решения без обращения в отдельную службу безопасности. Такие роли формируются естественным образом по мере накопления экспертизы в проектах с высокими требованиями к защите информации.

Безопасность как инженерная дисциплина

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