Заказная разработка ПО в IBS: Безопасная разработка и доставка

21 июля 2025

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

Важность безопасности в разработке заказного ПО

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

В ответ на эти вызовы был принят стандарт ГОСТ Р 56939-2024, который определяет ключевые принципы и подходы к внедрению безопасной разработки как эффективного способа защиты от киберугроз. В этой статье мы разберёмся, как обеспечить безопасность на всех этапах разработки и автоматизации поставки кода.

Что такое безопасная разработка в контексте CI/CD

Безопасная разработка – это не просто «написание хорошего кода». Это системный процесс управления рисками информационной безопасности на всех этапах жизненного цикла программного обеспечения. ГОСТ Р 56939-2024 определяет безопасную разработку как деятельность, включающую:

учёт актуальных угроз и рисков ИБ;
проектирование архитектуры и кода с учётом защиты от атак;
контроль качества и проверку безопасности;
обеспечение защищённости продукта от внедрения до вывода из эксплуатации.

Хотя ГОСТ напрямую не описывает практики CI/CD, он отлично сочетается с современными DevSecOps-подходами:

SAST/SCA/DAST/OSA-анализ интегрируются в пайплайн, что соответствует требованию раннего выявления угроз;
Автоматизированное тестирование безопасности входит в CI-процессы;
Ретроспективы и управление инцидентами закрывают цикл непрерывного улучшения;
Стратегия Shift-Left реализует принцип: чем раньше найдена уязвимость, тем дешевле и безопаснее её устранение.

Требования регуляторов в части безопасной разработки

Для корректной настройки CI/CD и процессов безопасной разработки необходимо определить, относится ли организация к субъектам КИИ:

Тип компании	Подход к инструментам	Рекомендации
Не является субъектом КИИ	Гибкий, коммерческий или open-source	Использование популярных DevSecOps-инструментов, адаптация под бизнес-задачи
Является субъектом КИИ	С учётом требований регуляторов	Использование сертифицированных ФСТЭК решений, соблюдение ГОСТ и моделей угроз
Частично попадает под КИИ	Комбинированный	Разделение пайплайнов (публичная часть vs защищённая), построение зон доверия

На основании таблицы выше нам необходимо выяснить:

Является ли организация субъектом КИИ (орган государственный власти, коммерческие организации, владеющие или управляющие объектом КИИ).
Имеются ли в её инфраструктуре объекты КИИ, такие как:

Информационные системы
Информационно-телекоммуникационные сети
Автоматизированные системы управления (АСУ ТП)

Работает ли организация в таких отраслях, как:

Энергетика
Транспорт
Банковская сфера
Здравоохранение
Оборонная или ракетно-космическая промышленность
ТЭК, АЭС и т.д.

Если ответ – да, значит CI/CD и процесс разработки должны быть выстроены с учётом следующих требований:

Федерального закона № 187-ФЗ
ГОСТ Р 56939-2016 (безопасная разработка)
Приказов ФСТЭК РФ (например, о категорировании объектов КИИ и обеспечении их защиты)

После того как мы определили причастность разрабатываемой информационной системы к КИИ следует переходить к реализации ГОСТ по безопасной разработке.

Как реализовать ГОСТ Р 56939-2024: структура внедрения

После подтверждения принадлежности к КИИ можно переходить к пошаговому внедрению требований ГОСТ. Все мероприятия логически сгруппированы: от планирования и архитектуры до поставки и вывода ПО из эксплуатации.

Каждое требование ГОСТа сопровождается перечнем конкретных мероприятий, а также примерами подходящих инструментов – как из open-source, так и из Единого реестра российского ПО (ЕРРП).

Требование ГОСТ Р 56939	Необходимые мероприятия	Инструменты OpenSource	Инструменты из ЕРРП
5.1 Планирование процессов разработки безопасного ПО	Разработать политику безопасной разработки Встроить ИБ в процессы SDLC Назначить ответственных	Confluence/Jira для документации процессов GitLab/GitHub Projects для управления задачами	Kaiten / Naumen / Eva
5.2 Обучение сотрудников	Проводить регулярное обучение разработчиков, тестировщиков и аналитиков по безопасной разработке	Курсы по кибербезопасности	Курсы по кибербезопасности с сертификацией ФСТЭК
5.3 Формирование и предъявление требований безопасности к ПО	Включить требования ИБ в спецификации, архитектуру и технические задания	Confluence шаблоны	Kaiten / Naumen / Eva
5.4 Управление конфигурацией ПО	Вести контроль версий, логировать изменения Использовать хранилища с разграничением доступа	Git, GitLab/GitHub HashiCorp Terraform / Ansible (для IaC)	Gitflic / Gitverse
5.5 Управление недостатками и запросами на изменение ПО	Внедрить процесс triage, управления багами, изменениям	Jira Gitlab Tasks или аналог	Kaiten / Naumen / Eva + Gitflic / Gitverse
5.6 Разработка, уточнение и анализ архитектуры ПО	Регулярно проводить архитектурные ревью Документировать архитектуру	Draw.io	Kaiten / Эсборд / Яндекс концепт
5.7 Моделирование угроз и разработка описания поверхности атаки	Проводить моделирование угроз (STRIDE, LINDDUN) Описывать потенциальные точки входа	OWASP Threat Dragon Microsoft Threat Modeling Tool	Отсутствует, можно использовать OSS (OWASP Threat Dragon)
5.8 Формирование и поддержание в актуальном состоянии правил кодирования	Использовать стандарты безопасного кодирования Обновлять линтеры и правила	ESLint, Bandit, Pylint, SonarQube	Svace / PT AI / SharpChecker и т.п.
5.9 Экспертиза исходного кода	Включить ручное ревью с фокусом на ИБ	GitLab Merge Requests с шаблонами проверок Gerrit	Gitflic / Gitverse Merge requests
5.10 Статический анализ исходного кода	Интегрировать SAST в CI/CD	SonarQube, Checkmarx, CodeQL, Fortify	PT AI, Solar AppScreener и т.п.
5.11 Динамический анализ кода программы	Проводить анализ во время выполнения	OWASP ZAP, Burp Suite	PT AI, Solar AppScreener и т.п.
5.12 Использование безопасной системы сборки ПО	Изолировать сборочные процессы Проводить валидацию зависимостей	Jenkins, GitLab CI	GitVerse / Gitflic
5.13 Обеспечение безопасности сборочной среды ПО	Изолировать сборочные агенты Сканировать среду на уязвимости	Docker, Clair, Trivy, Anchore	PT AI, Solar AppScreener, CodeScoring и т.п.
5.14 Управление доступом и контроль целостности кода при разработке ПО	Использовать ACL, RBAC Подписывать коммиты и сборки	GPG, Git Hooks, SLSA, Sigstore	КриптоПро CSP, VipNet CSP Хэш-функции ГОСТ Р 34.11
5.15 Обеспечение безопасности используемых секретов	Исключить хранение секретов в коде Использовать защищённые хранилища	HashiCorp Vault, AWS Secrets Manager, Doppler	Secret Manager от РЕД ОС или VipNet Safe Storage и т.п.
5.16 Использование инструментов композиционного анализа	Анализировать сторонние зависимости	Snyk, OWASP Dependency-Check, Syft/Grype	MaxPatrom SCA, PT AI, CodeScoring, Solar AppScreener и т.п.
5.17 Проверка кода на предмет внедрения вредоносного ПО через цепочки поставок	Верифицировать внешние компоненты и поставщиков	Cosign, in-toto, Rebuilderd, SBOM	MaxPatrom SCA, CodeScoring, Solar AppScreener и т.п.
5.18 Функциональное тестирование	Автоматизировать проверку бизнес-логики и ИБ-функций	Postman, Selenium, JUnit/Pytest	TestIT, Кайман и т.п.
5.19 Нефункциональное тестирование	Тестировать отказоустойчивость, стресс и безопасность	k6, JMeter, ChaosMonkey	TestIT, Кайман и т.п.
5.20 Обеспечение безопасности при выпуске готовой к эксплуатации версии программного обеспечения	Проверка уязвимостей перед продом Выпуск только подписанных сборок	GitLab Release Management, Cosign	Подпись через КриптоПро или VipNet Хранилище подписанных артефактов на изолированной инфраструктуре
5.21 Безопасная поставка программного обеспечения пользователям	Цифровая подпись Защищённые каналы доставки	TLS, VPN, Artifact Repositories (Nexus, Artifactory)	VipNet, Континент-АП, TLS по ГОСТ
5.22 Обеспечение поддержки программного обеспечения при эксплуатации пользователями	Регулярные патчи, обновления Обработка инцидентов	Ticketing-системы, Grafana, Prometheus	Zabbix (в РФ-совместимой сборке), MaxPatrol SIEM, СЗИ от ФСТЭК
5.23 Реагирование на информацию об уязвимостях	Создать процесс triage Выпуск исправлений	Bug Bounty платформы, Jira, GitHub Security Advisories	Системы обработки инцидентов на базе MaxPatrol или InfoWatch
5.24 Поиск уязвимостей в программном обеспечении при эксплуатации	Мониторинг рантайма, IDS/IPS, EDR	Falco, Wazuh, CrowdStrike, Sysdig	Luntry
5.25 Обеспечение безопасности при выводе программного обеспечения из эксплуатации	Удалить данные и ключи Отключить системы от сетей	Ansible/Salt, SIEM, удаление образов и артефактов	Средства гарантированного удаления данных (Zecurion, Eraser RU) Автоматизация с Ansible (локально) или Бастион

Например, в IBS используются следующие инструменты:

SAST: SonarQube – для статического анализа кода на уязвимости и нарушения стандартов безопасности.
IAST: Contrast Community Edition – для интерактивного анализа во время выполнения, особенно в средах тестирования.
SCA/OSA: Grype, Trivy – для анализа зависимостей и поиска уязвимостей в сторонних библиотеках и образах контейнеров.
BCA (Binary Composition Analysis): Orbit, DotPeek и аналогичные средства – для анализа составных частей бинарных файлов.
DAST: OWASP ZAP в связке с fuzzer-ами – для динамического анализа веб-приложений в режиме "чёрного ящика".
MAST: Cycript, MobSF – инструменты для анализа мобильных приложений, включая статический и динамический анализ.
RASP: OpenRASP – решение для защиты приложений в рантайме.
API Security: WSO2 – платформа для обеспечения безопасности REST/SOAP API, включая авторизацию, аудит и ограничение доступа.

Все эти решения интегрированы в DevSecOps-конвейер IBS на базе Jenkins, что позволяет автоматически запускать проверки безопасности на каждом этапе CI/CD, начиная с анализа кода и зависимостей и заканчивая безопасной сборкой, выпуском и поставкой ПО.

Обеспечение безопасности при заказной разработке программного обеспечения – это не разовая мера, а комплексный и систематизированный процесс, охватывающий все этапы жизненного цикла продукта: от планирования и архитектуры до поставки, эксплуатации и вывода из обращения. В IBS данная практика реализуется через интеграцию современных DevSecOps-подходов, соответствующих требованиям ГОСТ Р 56939-2024 и нормативам регуляторов, с применением как open-source, так и отечественных сертифицированных инструментов. Такой подход позволяет минимизировать риски, повысить качество и доверие к продукту, а также обеспечить его соответствие как внутренним, так и внешним требованиям информационной безопасности. Всё это – и методология, и инструменты, и практика безопасной разработки – мы в IBS хорошо знаем, умеем применять и готовы внедрять в проектах наших заказчиков.

544