Продолжаем цикл публикаций, посвященных специфике создания программного обеспечения на заказ. В прошлом материале речь шла об организации процессов разработки и тестирования. В этой статье начальник отдела DevOps компании IBS Артур Галеев расскажет об опыте внедрения принципов безопасной разработки, используемых инструментах и нормативных актах, на которые стоит опираться.
Важность безопасности в разработке заказного ПО
За пять лет количество утечек данных и атак на информационные системы увеличилось в 2,3 раза. Это привело к ужесточению требований регуляторов в сфере информационной безопасности (ИБ), особенно в части процессов сборки и доставки ПО.
В ответ на эти вызовы был принят стандарт ГОСТ Р 56939-2024, который определяет ключевые принципы и подходы к внедрению безопасной разработки как эффективного способа защиты от киберугроз.
Что такое безопасная разработка в контексте CI/CD
Безопасная разработка — это не просто «написание хорошего кода». Это системный процесс управления рисками ИБ на всех этапах жизненного цикла ПО. ГОСТ Р 56939-2024 определяет безопасную разработку как деятельность, включающую:
-
учёт актуальных угроз и рисков ИБ;
-
проектирование архитектуры и кода с учётом защиты от атак;
-
контроль качества и проверку безопасности;
-
обеспечение защищённости продукта от внедрения до вывода из эксплуатации.
Хотя ГОСТ напрямую не описывает практики CI/CD, он отлично сочетается с современными DevSecOps-подходами:
-
SAST/SCA/DAST/OSA-анализ интегрируются в пайплайн, что соответствует требованию раннего выявления угроз;
-
автоматизированное тестирование безопасности входит в CI-процессы;
-
ретроспективы и управление инцидентами закрывают цикл непрерывного улучшения;
-
стратегия Shift — Left реализует принцип: чем раньше найдена уязвимость, тем дешевле и безопаснее ее устранение.
Требования регуляторов в части безопасной разработки
Для корректной настройки CI/CD и процессов безопасной разработки необходимо определить, относится ли организация к субъектам КИИ.

|
Тип компании
|
Подход к инструментам
|
Рекомендации
|
|---|---|---|
|
Не является субъектом КИИ
|
Гибкий, коммерческий или Open Source
|
Использование популярных DevSecOps-инструментов, адаптация под бизнес-задачи
|
|
Является субъектом КИИ
|
С учетом требований регуляторов
|
Использование сертифицированных ФСТЭК решений, соблюдение ГОСТа и моделей угроз
|
|
Частично попадает под КИИ
|
Комбинированный
|
Разделение пайплайнов на публичную и защищенную части, построение зон доверия
|
Необходимо выяснить:
1. Является ли организация субъектом КИИ (орган государственный власти, коммерческие организации, владеющие или управляющие объектом КИИ).
2. Имеются ли в её инфраструктуре объекты КИИ, такие как:
-
информационные системы,
-
информационно-телекоммуникационные сети,
-
автоматизированные системы управления (АСУ ТП).
3. Работает ли организация в таких отраслях, как энергетика, транспорт, банковская сфера, здравоохранение, оборонная или ракетно-космическая промышленность, ТЭК, АЭС и т.д.
Если ответ — да, значит, CI/CD и процесс разработки должны быть выстроены с учетом федерального закона № 187-ФЗ, ГОСТ Р 56939-2016 (безопасная разработка) и приказов ФСТЭК РФ (например, о категорировании объектов КИИ и обеспечении их защиты).
После того как мы определили причастность разрабатываемой информационной системы к КИИ, следует переходить к пошаговой реализации ГОСТа по безопасной разработке.
Как реализовать ГОСТ Р 56939-2024: структура внедрения
Все мероприятия в ГОСТе логически сгруппированы — от планирования и архитектуры до поставки и вывода ПО из эксплуатации. Каждое требование сопровождается перечнем конкретных мер, а также примерами подходящих инструментов — как из Open Source, так и из Единого реестра российского ПО (ЕРРП).
|
Требование ГОСТ Р 56939
|
Необходимые мероприятия
|
Инструменты Open Source
|
Инструменты из ЕРРП
|
|---|---|---|---|
|
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
CodeScoring |
|
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
CodeScoring |
|
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
|
CodeScoring, Secret Manager от РЕД ОС или VipNet Safe Storage и т.п. |
|
5.16 Использование инструментов композиционного анализа
|
Анализировать сторонние зависимости
|
Snyk, OWASP Dependency-Check, Syft/Grype
|
MaxPatrol SCA, PT AI, CodeScoring, Solar AppScreener и т.п.
|
|
5.17 Проверка кода на предмет внедрения вредоносного ПО через цепочки поставок
|
Верифицировать внешние компоненты и поставщиков
|
Cosign, in-toto, Rebuilderd, SBOM
|
MaxPatrol 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, CodeScoring
|
|
5.24 Поиск уязвимостей в ПО при эксплуатации
|
Мониторинг рантайма, IDS/IPS, EDR
|
Falco, Wazuh, CrowdStrike, Sysdig
|
Luntry, CodeScoring
|
|
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 в связке с фаззерами — для динамического анализа веб-приложений в режиме «черного ящика».
-
MAST: Cycript, MobSF — инструменты для анализа мобильных приложений, включая статический и динамический анализ.
-
RASP: OpenRASP — решение для защиты приложений в рантайме.
-
API Security: WSO2 — платформа для обеспечения безопасности REST/SOAP API, включая авторизацию, аудит и ограничение доступа.
Все эти решения интегрированы в DevSecOps-конвейер IBS на базе Jenkins, что позволяет автоматически запускать проверки безопасности на каждом этапе CI/CD, начиная с анализа кода и зависимостей и заканчивая безопасной сборкой, выпуском и поставкой ПО.

Обеспечение безопасности при заказной разработке ПО — это комплексный и систематизированный процесс, охватывающий все этапы жизненного цикла продукта. В IBS данная практика реализуется через интеграцию современных DevSecOps-подходов, соответствующих ГОСТу и нормативам регуляторов, с применением Open Source и сертифицированных отечественных инструментов. Это позволяет минимизировать риски, повысить качество продукта и доверие к нему, а также обеспечить выполнение внутренних и внешних требований ИБ.
Мы хорошо знаем методологию, инструменты и практику безопасной разработки и готовы внедрять их в проектах наших заказчиков. Если вы планируете автоматизировать уникальные бизнес-процессы или создать индивидуальное программное решение, обратитесь за консультацией к экспертам IBS.