Важность безопасности в разработке заказного ПО
За пять лет количество утечек данных и атак на информационные системы увеличилось в 2,3 раза. Это привело к ужесточению требований регуляторов в сфере информационной безопасности (ИБ), особенно в части процессов сборки и доставки ПО.
В ответ на эти вызовы был принят стандарт ГОСТ Р 56939-2024, который определяет ключевые принципы и подходы к внедрению безопасной разработки как эффективного способа защиты от киберугроз.
Что такое безопасная разработка в контексте CI/CD
Безопасная разработка — это не просто «написание хорошего кода». Это системный процесс управления рисками ИБ на всех этапах жизненного цикла ПО. ГОСТ Р 56939-2024 определяет безопасную разработку как деятельность, включающую:Хотя ГОСТ напрямую не описывает практики CI/CD, он отлично сочетается с современными DevSecOps-подходами:
Требования регуляторов в части безопасной разработки
Для корректной настройки CI/CD и процессов безопасной разработки необходимо определить, относится ли организация к субъектам КИИ.
|
Тип компании |
Подход к инструментам |
Рекомендации |
|---|---|---|
| Не является субъектом КИИ | Гибкий, коммерческий или Open Source | Использование популярных DevSecOps-инструментов, адаптация под бизнес-задачи |
| Является субъектом КИИ | С учетом требований регуляторов | Использование сертифицированных ФСТЭК решений, соблюдение ГОСТа и моделей угроз |
| Частично попадает под КИИ | Комбинированный | Разделение пайплайнов на публичную и защищенную части, построение зон доверия |
Необходимо выяснить:
1. Является ли организация субъектом КИИ (орган государственный власти, коммерческие организации, владеющие или управляющие объектом КИИ).
2. Имеются ли в её инфраструктуре объекты КИИ, такие как:
3. Работает ли организация в таких отраслях, как энергетика, транспорт, банковская сфера, здравоохранение, оборонная или ракетно-космическая промышленность, ТЭК, АЭС и т.д.
Если ответ — да, значит, CI/CD и процесс разработки должны быть выстроены с учетом федерального закона № 187-ФЗ, ГОСТ Р 56939-2016 (безопасная разработка) и приказов ФСТЭК РФ (например, о категорировании объектов КИИ и обеспечении их защиты).
После того как мы определили причастность разрабатываемой информационной системы к КИИ, следует переходить к пошаговой реализации ГОСТа по безопасной разработке.
Как реализовать ГОСТ Р 56939-2024: структура внедрения
Все мероприятия в ГОСТе логически сгруппированы — от планирования и архитектуры до поставки и вывода ПО из эксплуатации. Каждое требование сопровождается перечнем конкретных мер, а также примерами подходящих инструментов — как из Open Source, так и из Единого реестра российского ПО (ЕРРП).|
Требование ГОСТ Р 56939 |
Необходимые мероприятия |
Инструменты Open Source |
Инструменты из ЕРРП |
|---|---|---|---|
|
5.1 Планирование процессов разработки безопасного ПО |
Разработать политику безопасной разработки |
Confluence/Jira для документации процессов |
Kaiten / Naumen / Eva |
|
5.2 Обучение сотрудников |
Проводить регулярное обучение разработчиков, тестировщиков и аналитиков по безопасной разработке |
Курсы по кибербезопасности |
Курсы по кибербезопасности с сертификацией ФСТЭК |
|
5.3 Формирование и предъявление требований безопасности к ПО |
Включить требования ИБ в спецификации, архитектуру и технические задания |
Confluence-шаблоны |
Kaiten / Naumen / Eva |
|
5.4 Управление конфигурацией ПО |
Вести контроль версий, логировать изменения |
Git, GitLab/GitHub |
Gitflic / Gitverse |
|
5.5 Управление недостатками и запросами на изменение ПО |
Внедрить процесс triage, управления багами, изменениями |
Jira |
Kaiten / Naumen / Eva + Gitflic / Gitverse |
|
5.6 Разработка, уточнение и анализ архитектуры ПО |
Регулярно проводить архитектурные ревью |
Draw.io |
Kaiten / Эсборд / Яндекс Концепт |
|
5.7 Моделирование угроз и разработка описания поверхности атаки |
Проводить моделирование угроз (STRIDE, LINDDUN) |
OWASP Threat Dragon |
Отсутствует, можно использовать OSS (OWASP Threat Dragon) |
|
5.8 Формирование и поддержание в актуальном состоянии правил кодирования |
Использовать стандарты безопасного кодирования |
ESLint, Bandit, Pylint, SonarQube |
Svace / PT AI / SharpChecker и т.п. |
|
5.9 Экспертиза исходного кода |
Включить ручное ревью с фокусом на ИБ |
GitLab Merge Requests с шаблонами проверок |
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 |
|
5.15 Обеспечение безопасности используемых секретов |
Исключить хранение секретов в коде |
HashiCorp Vault, AWS Secrets Manager, Doppler |
|
|
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) |
Например, в IBS используются следующие инструменты:
Все эти решения интегрированы в DevSecOps-конвейер IBS на базе Jenkins, что позволяет автоматически запускать проверки безопасности на каждом этапе CI/CD, начиная с анализа кода и зависимостей и заканчивая безопасной сборкой, выпуском и поставкой ПО.
Обеспечение безопасности при заказной разработке ПО — это комплексный и систематизированный процесс, охватывающий все этапы жизненного цикла продукта. В IBS данная практика реализуется через интеграцию современных DevSecOps-подходов, соответствующих ГОСТу и нормативам регуляторов, с применением Open Source и сертифицированных отечественных инструментов. Это позволяет минимизировать риски, повысить качество продукта и доверие к нему, а также обеспечить выполнение внутренних и внешних требований ИБ.
Оригинал статьи на GlobalCIO