Глубокий взгляд на процесс безопасной разработки на платформе контейнеризации

В этой статье мы расскажем, как устроен процесс обеспечения безопасности, в примере нашей флагманской платформы контейнеризации «Боцман». Мы структурировали описание в соответствии с этапами модели РБПО, чтобы дать чёткое представление о методологии. Это будет полезно тем, кто задумывается о внедрении подобной системы.

Обучение и подготовка

Безопасность начинается с компетенций. Мы уделяем большое внимание внутренней экспертизе и непрерывному обучению, и наши сотрудники:

• проходят специализированные курсы на платформе Stellar;
• осваивают международные стандарты и практики OWASP Top 10 и CIS Benchmark;
• регулярно участвуют в тренингах по безопасной разработке и реагированию на инциденты.

Так мы смогли сформировать команду, которая не просто пишет код, а осознанно проектирует и реализует безопасные решения.

Анализ требований и аудит

На старте проекта мы определяем ИБ-требования к продукту и проводим аудит текущих процессов:

• изучаем нормативные документы: предписания ФСТЭК России, ГОСТы Р 56545–2015 («Защита информации. Уязвимости информационных систем. Правила описания уязвимостей») и 56939–2024 («Защита информации. Разработка безопасного программного обеспечения. Общие требования»);
• оцениваем соответствие процессов актуальным стандартам;
• фиксируем требования к контролю уязвимостей, лицензированию компонентов, мониторингу и отчётности.

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

Проектирование и моделирование угроз

Архитектура платформы учитывает ИБ-требования. На этапе проектирования:

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

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

Безопасная разработка (реализация)

Во время написания кода мы сочетаем практики РБПО с автоматизированным контролем:

• следуем правилам Secure Coding — пишем код, устойчивый к типичным уязвимостям: инъекциям, переполнению буфера и т. д.;
• проводим автоматический статический анализ кода (SAST) и выявляем потенциальные уязвимости на ранних стадиях;
• делаем композиционный анализ (SCA) — сканируем итоговый код приложения на наличие уязвимых компонентов и лицензионных рисков;
• внедряем самописные решения на основе лучших SBOM‐генераторов — они формируют точный «паспорт» софта (Software Bill of Materials), включая все зависимости и библиотеки.

Всё это помогает свести к минимуму вероятность внедрения небезопасных компонентов и снижает стоимость исправления дефектов.

Тестирование безопасности (верификация)

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

• динамический анализ (DAST) — проверку работающего приложения на уязвимости;
• тесты на проникновение (пентесты) — имитацию реальных атак, чтобы выявить слабые места;
• фаззинг-тестирование — подачу случайных или специально сформированных данных, чтобы спровоцировать сбои и ошибки;
• операционный анализ безопасности (OSA) — мониторинг компонентов в процессе их загрузки и использования в инфраструктуре. Этот этап предотвращает попадание небезопасных библиотек в рабочую среду и дополняет результаты SCA.

Все результаты фиксируются в единой системе отслеживания задач. Каждая уязвимость получает номер CVE, оценку по CVSS v3.1 и статус (Unresolved, In Progress и Done).

Безопасный релиз (deployment)

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

• настройка защищённой конфигурации (hardening) — отключение ненужных служб, минимизация привилегий, применение безопасных настроек ОС и другого ПО;
• повторная проверка компонентов с помощью SCA и OSA;
• верификация соответствия требованиям регуляторов и внутренним стандартам.

Только после успешного прохождения всех этапов продукт получает статус Release и допускается к развёртыванию в производственной среде.

Сопровождение и реагирование (response)

Безопасность — это непрерывный процесс. После релиза мы обеспечиваем:

• регулярный мониторинг уязвимостей — композиционный анализ выполняем не реже раза в месяц, а также внепланово, если появляются новые угрозы или меняется архитектура;
• оперативное устранение уязвимостей — разработчики вносят исправления, а специалисты департамента сертификации проверяют корректность патчей;
• контроль устранения — после внесения изменений проверяем:
• корректность исправлений в исходном коде;
• отражение исправления в changelog;
• отсутствие возможности эксплуатировать уязвимость при действующих ИБ-политиках;
• прозрачность отчётности — клиенты и партнёры через специальный портал получают доступ к отчётам, где содержится не только список уязвимостей, но и обоснование того, почему их невозможно эксплуатировать или не нужно устранять (когда риск минимален).

Заключение: безопасная разработка как конкурентное преимущество

Описанный алгоритм РБПО — это не набор формальных процедур, а целостная экосистема, объединяющая технологии, людей и процессы для защиты продукта и данных клиентов.

Вот пять ключевых преимуществ нашего подхода.

1. Соответствие регуляторным нормам

Продукт сертифицирован и готов к использованию в защищённых сегментах сети. Мы строго следуем требованиям ФСТЭК и актуальным ГОСТам.

2. Комплексный контроль

Сочетание SCA и OSA позволяет выявлять и предотвращать угрозы на всех этапах жизненного цикла ПО.

3. Экспертная оценка

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

4. Прозрачность и доверие

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

5. Гибкость и развитие

Мы регулярно пересматриваем свои регламенты и инструменты, особенно если меняются нормативная база, стандарты или архитектуры ПО.

Статью подготовил Нияз Козлов, менеджер продукта, платформа «Боцман» (входит в «Группу Астра»).