Заказная разработка ПО в 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.