A.14.2: Безопасность в процессах разработки

Подробное описание

Контроль A.14.2 требует интеграции требований информационной безопасности на всех этапах жизненного цикла разработки (SDLC) — от проектирования до эксплуатации и вывода из эксплуатации. Это включает моделирование угроз, безопасное кодирование, тестирование на уязвимости, управление безопасностью зависимостей и конфигураций. Контроль охватывает как внутреннюю разработку, так и привлечение сторонних подрядчиков, требуя формализации требований безопасности в спецификациях и приёмочных критериях. Организация должна внедрить практики безопасной разработки (Secure SDLC), включая пир-ревью кода, автоматизированное тестирование безопасности и управление изменениями с учётом рисков.

Практические шаги внедрения

1. 1

   Разработать и утвердить политику безопасной разработки (Secure Development Policy) с требованиями к моделированию угроз, стандартам кодирования (OWASP, CWE), обработке секретов и управлению зависимостями

2. 2

   Внедрить обязательное моделирование угроз (threat modeling) на этапе проектирования архитектуры с использованием методологий STRIDE, PASTA или LINDDUN

3. 3

   Интегрировать в CI/CD автоматизированные инструменты SAST (статический анализ кода), DAST (динамическое тестирование), SCA (анализ зависимостей) и Secret Scanning

4. 4

   Установить процесс обязательного пир-ревью кода (peer review) с чек-листом безопасности и ролью security champion в каждой команде разработки

5. 5

   Внедрить управление уязвимостями в зависимостях с политикой обновления критических CVE в течение 7 дней и блокировкой сборки при критических находках

6. 6

   Организовать регулярное обучение разработчиков безопасному кодированию (минимум 16 часов в год) с практическими лабораториями и симуляциями атак

7. 7

   Определить приёмочные критерии безопасности (security acceptance criteria) для каждого релиза, включая отсутствие критических уязвимостей и покрытие SAST/DAST тестами не менее 80%

Типичные нарушения

• Отсутствие моделирования угроз — архитектурные решения принимаются без анализа поверхности атаки, что приводит к системным уязвимостям (например, отсутствие защиты от IDOR, SSRF)

• Hardcoded credentials — пароли, API-ключи и токены хранятся в исходном коде или конфигурационных файлах в репозитории вместо безопасных хранилищ (Vault, Secrets Manager)

• Использование устаревших библиотек с известными CVE — зависимости не обновляются годами, при этом отсутствует процесс мониторинга уязвимостей через SCA-инструменты

• Отсутствие безопасности в CI/CD — пайплайны не содержат этапов SAST/DAST, секреты передаются через переменные окружения без шифрования, нет контроля целостности артефактов

• Игнорирование находок сканеров безопасности — критические уязвимости помечаются как "false positive" без документированного обоснования или откладываются на неопределённый срок

Почему это важно

Проверяемые категории

Связанные контроли