Безопасная разработка (DevSecOps) и сертификация исходного кода ПО

Контроль A.8.28 «Безопасное программирование» — один из новых контролей ISO 27001:2022. В этой статье — как внедрить DevSecOps, интегрировать SAST/DAST в CI/CD и подготовиться к сертификации исходного кода ПО.

Пайплайн DevSecOps: этапы и инструменты

DevSecOps ISO пайплайн интегрирует проверки безопасности в каждую фазу CI/CD. Ниже представлена типовая схема пайплайна с указанием применяемых инструментов и методов анализа:

Ключевой принцип DevSecOps — «shift left», то есть смещение проверок безопасности как можно раньше в процессе разработки. Чем раньше обнаружена уязвимость, тем дешевле и проще её устранить. Автоматизация проверок через CI/CD позволяет выявлять до 85% типичных уязвимостей ещё до того, как код попадёт в тестовую среду.

Рассмотрим детальнее каждый этап. На стадии Plan команда проводит моделирование угроз с использованием методологии STRIDE, анализируя каждый компонент системы по шести категориям: подмена идентичности (Spoofing), нарушение целостности (Tampering), отказ от авторства (Repudiation), раскрытие информации (Information Disclosure), отказ в обслуживании (Denial of Service) и повышение привилегий (Elevation of Privilege). Результатом становится реестр угроз с приоритетами, который определяет фокус проверок безопасности на последующих этапах.

На стадии Code критически важны pre-commit хуки — автоматические проверки, запускаемые до фиксации кода в репозитории. Типовая конфигурация включает запуск GitLeaks для обнаружения паролей, API-ключей и токенов в коде, а также линтеры безопасности (Semgrep), проверяющие код на соответствие правилам OWASP. Если проверка обнаруживает проблему, коммит блокируется до её устранения.

Стадия Build является точкой интеграции SAST-анализа. Статический анализатор встраивается в систему сборки и запускается автоматически при каждом merge request. Результаты сканирования передаются в единую платформу управления уязвимостями (например, DefectDojo), где происходит их триаж, назначение ответственных и контроль устранения. Одновременно SCA-инструменты проверяют все сторонние зависимости на наличие известных CVE и несовместимых лицензий.

На стадии Release артефакты подписываются цифровой подписью с помощью Cosign или Notary, а образы контейнеров сканируются Trivy на наличие уязвимостей в базовых слоях. Используется подход «качественных ворот» (quality gates): если количество критических уязвимостей превышает пороговое значение, релиз автоматически блокируется.

SAST и DAST тестирование: сравнение методов

SAST DAST тестирование — два ключевых метода анализа безопасности приложений, которые дополняют друг друга и обеспечивают комплексное покрытие.

SAST (Static Application Security Testing) — статический анализ исходного кода без его выполнения. Инструменты SAST сканируют код на наличие известных паттернов уязвимостей, соответствующих базам CWE (Common Weakness Enumeration). Анализ выполняется на этапе сборки (Build), что позволяет обнаружить проблемы до развёртывания.

DAST (Dynamic Application Security Testing) — динамический анализ работающего приложения. Инструменты DAST имитируют действия злоумышленника, отправляя специально сформированные запросы к приложению и анализируя ответы. Этот метод эффективен для обнаружения уязвимостей, которые проявляются только в runtime-среде.

Для достижения максимальной эффективности рекомендуется использовать оба метода совместно, дополняя их анализом состава ПО (SCA — Software Composition Analysis) для проверки открытых библиотек и зависимостей на известные уязвимости (CVE). Комплексные платформы, такие как Solar appScreener или PT Application Inspector, объединяют SAST, DAST, SCA и SCS (анализ цепочки поставок) в едином интерфейсе, что упрощает управление безопасностью кода.

OWASP Top 10 (2025): ключевые уязвимости и как их предотвратить

OWASP Top 10 — ежегодно обновляемый рейтинг наиболее критичных уязвимостей веб-приложений, являющийся индустриальным стандартом для разработки безопасного кода. Версия 2025 года содержит две новые категории и отражает сдвиг ландшафта угроз в сторону атак на цепочки поставок и проблем обработки исключений.

Ключевые позиции рейтинга OWASP Top 10 (2025):

1. A01: Broken Access Control — нарушение контроля доступа остаётся угрозой №1. Типичный сценарий эксплуатации: пользователь изменяет параметр идентификатора в URL (например, /api/orders/123 на /api/orders/456) и получает доступ к чужим данным (IDOR-уязвимость). Меры защиты: проверка прав доступа на стороне сервера для каждого запроса, принцип «запрет по умолчанию», ограничение частоты обращений к API
2. A02: Security Misconfiguration — ошибки конфигурации поднялись с 5-го на 2-е место. Примеры: открытые дефолтные учётные записи администраторов, включённый режим отладки в продакшене, публично доступные файлы .env с секретами. Защита: автоматизированная проверка конфигураций через IaC-сканеры (Checkov, tfsec), регулярный аудит настроек
3. A03: Software Supply Chain Failures — новая категория, атаки на цепочку поставок ПО. Злоумышленники внедряют вредоносный код в популярные open-source библиотеки или подменяют пакеты в реестрах (typosquatting). Защита: SCA-анализ, фиксация версий зависимостей, использование приватных зеркал репозиториев, проверка подписей пакетов
4. A04: Cryptographic Failures — криптографические сбои: использование устаревших алгоритмов (MD5, SHA-1), хранение паролей в открытом виде, передача данных без TLS. Защита: применение современных алгоритмов (AES-256, bcrypt/Argon2 для паролей), обязательный TLS 1.3
5. A05: Injection — SQL-инъекции, XSS, command injection (снизились с 3-го места благодаря распространению ORM и параметризованных запросов). Пример: ввод ' OR 1=1 -- в поле авторизации для обхода проверки. Защита: параметризованные запросы, экранирование вывода, Content Security Policy
6. A06: Insecure Design — небезопасное проектирование: отсутствие моделирования угроз, недостаточная валидация бизнес-логики. Защита: threat modeling на этапе проектирования, abuse-case тестирование
7. A07: Authentication Failures — сбои аутентификации: слабые пароли, отсутствие MFA, уязвимые механизмы восстановления пароля. Защита: многофакторная аутентификация, ограничение попыток входа, безопасное управление сессиями
8. A08: Software or Data Integrity Failures — нарушение целостности данных и ПО: автообновления без проверки подписи, десериализация недоверенных данных. Защита: цифровая подпись артефактов, валидация целостности при загрузке
9. A09: Security Logging and Alerting Failures — недостатки логирования: отсутствие записи критических событий безопасности, хранение логов только локально. Защита: централизованное логирование (SIEM), алерты на аномальную активность, регулярный анализ логов
10. A10: Mishandling of Exceptional Conditions — новая категория, некорректная обработка исключений: утечка стек-трейсов пользователю, игнорирование ошибок при криптографических операциях, отсутствие обработки таймаутов. Защита: централизованная обработка ошибок, пользовательские страницы ошибок без технических деталей, fail-safe поведение при исключениях

Появление категории A03 (Supply Chain Failures) подчёркивает необходимость применения SCA-инструментов и проверки зависимостей на каждом этапе сборки. Безопасный код невозможен без контроля всех компонентов, включая сторонние библиотеки. Именно поэтому контроль A.8.28 стандарта ISO 27001 требует применения принципов безопасного кодирования с учётом рекомендаций OWASP.

Подробнее о требованиях ISO 27001 для IT-компаний читайте в нашем материале: безопасная разработка и сертификация.

Сертификация исходного кода ПО: процедура и выгоды

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

1. GAP-анализ — оценка текущего уровня зрелости процессов разработки, выявление расхождений с требованиями ISO 27001 (A.8.25–A.8.28) и ГОСТ Р 56939-2024. Длительность: 1–2 недели. На этом этапе аудиторы интервьюируют ключевых сотрудников (руководителей разработки, DevOps-инженеров, специалистов ИБ), анализируют существующую документацию и оценивают текущий CI/CD-пайплайн
2. Разработка документации — создание политик безопасной разработки, регламентов код-ревью, процедур управления уязвимостями. Длительность: 2–4 недели. Включает подготовку не менее 15–20 документов: политика безопасной разработки, стандарт кодирования, процедура управления уязвимостями, регламент код-ревью, план реагирования на инциденты ИБ и другие
3. Внедрение практик DevSecOps — настройка пайплайна CI/CD с интеграцией SAST, DAST, SCA-инструментов. Длительность: 3–6 недель в зависимости от сложности инфраструктуры и количества проектов
4. Внутренний аудит — проверка работоспособности внедрённых процессов, устранение несоответствий. Длительность: 1–2 недели. Проводится силами организации или с привлечением внешних консультантов
5. Сертификационный аудит — проверка независимым органом по сертификации, выдача сертификата. Проходит в два этапа: аудит документации (Stage 1, 1–2 дня) и аудит практической реализации (Stage 2, 2–5 дней). Общая длительность процедуры от начала GAP-анализа до получения сертификата составляет 2–4 месяца

Стоимость сертификации зависит от масштаба организации, количества разработчиков, числа проектов и текущего уровня зрелости процессов. Для компаний с командой 10–50 разработчиков стоимость варьируется от 300 000 до 800 000 рублей, включая консалтинг и сертификационный аудит. Для крупных организаций (50+ разработчиков, множество проектов) стоимость может достигать 1,5–2 млн рублей. Сертификат действует 3 года при условии прохождения ежегодных надзорных аудитов, стоимость которых составляет 30–50% от первоначальной сертификации.

Выгоды сертификации для организации-разработчика:

• Снижение количества уязвимостей в продуктивном коде на 40–70%
• Соответствие требованиям регуляторов (ФЗ-152, приказы ФСТЭК, требования ЦБ РФ)
• Конкурентное преимущество при участии в тендерах и государственных закупках
• Повышение доверия заказчиков и партнёров
• Выход на международные рынки (ISO 27001 признаётся в 160+ странах)
• Снижение стоимости реагирования на инциденты ИБ

Важно понимать, что безопасная разработка сертификация — это не разовое мероприятие, а непрерывный процесс совершенствования. Стандарты требуют регулярного пересмотра политик, обновления инструментов анализа и повышения квалификации разработчиков.

Как «Астелс» помогает внедрить безопасную разработку

Центр сертификации «Астелс» сопровождает IT-компании на всех этапах внедрения безопасной разработки и получения сертификата ISO 27001. Наши эксперты обладают практическим опытом в области DevSecOps, SAST DAST тестирования и аудита процессов разработки.

Мы предлагаем комплексный подход:

• GAP-анализ текущих процессов разработки на соответствие ISO 27001 (A.8.25–A.8.28) и ГОСТ Р 56939-2024
• Разработку документации СМИБ с учётом специфики DevSecOps-пайплайна вашей организации
• Консультации по выбору инструментов SAST, DAST, SCA для вашего технологического стека
• Проведение сертификационного аудита и выдачу сертификата международного образца
• Пост-сертификационную поддержку — надзорные аудиты, помощь в устранении несоответствий

Безопасный код — это не только требование стандартов, но и инвестиция в репутацию и устойчивость вашего бизнеса. Свяжитесь с «Астелс», чтобы получить бесплатную консультацию по сертификации процессов безопасной разработки и узнать точные сроки и стоимость для вашей компании.