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

Продолжаем цикл публикаций, посвященных специфике создания программного обеспечения на заказ. В прошлом материале речь шла об организации процессов разработки и тестирования. В этой статье начальник отдела 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.

Оригинал статьи можно прочитать здесь.

Управление проектами