Лидер безопасности в разработке и DevOps
В модуле 2 мы закрыли базовый периметр: менеджер паролей, MFA, защита почты. Это необходимо любой компании. Но если у вас есть команда разработки, периметра недостаточно — потому что атакующие всё чаще ищут не слабый пароль, а уязвимость в приложении, которое ваша команда сама же написала.
SQL-инъекции, сломанная аутентификация, незащищённые API — эти проблемы не возникают сами по себе. Их создают разработчики, которых никто не учил думать о безопасности. Именно здесь в работу вступает лидер безопасности — сотрудник, который берёт на себя вопросы информационной безопасности в команде как дополнительную зону ответственности. Далее по тексту — «лидер безопасности».
Этот модуль — для компаний, которые создают собственное программное обеспечение. Здесь нет инструкций для программистов. Зато есть ответы на вопросы руководителя: какие риски существуют, что требовать от команды, как это бюджетировать и как убедиться, что всё сделано.
Почему уязвимости рождаются в коде
Когда разработчик создаёт форму входа или функцию загрузки файлов, у него одна задача: чтобы работало. Безопасность — отдельная экспертиза, которой большинство разработчиков не имеют. Служба ИБ, в свою очередь, не погружена в архитектуру конкретного приложения и подключается — если вообще подключается — в конце, когда переделывать дорого.
Результат: большинство критичных уязвимостей попадают в продакшн не из-за безответственности, а потому что процесс выстроен неправильно.
Стоимость исправления растёт с каждым этапом:
| Этап обнаружения проблемы | Относительная стоимость исправления |
|---|---|
| При проектировании | ×1 — достаточно изменить дизайн |
| В процессе разработки | ×5 — нужно переписывать готовый код |
| При тестировании | ×15 — срывается спринт, переработки |
| В продакшне | ×50–100 — инцидент, клиенты, возможный штраф |
Принцип «сдвинуть безопасность влево» (shift left) — находить проблемы там, где их исправление стоит ×1, а не ×100. Лидер безопасности встраивается в команду именно на этих ранних этапах.
Роль лидера безопасности в команде разработки
С точки зрения бизнеса, лидер безопасности выполняет несколько функций.
-
На этапе проектирования — задаёт вопросы о безопасности до начала кодирования: с какими данными работает новая функция, какие требования применимы, нужна ли дополнительная проверка. Это предотвращает архитектурные решения, которые потом невозможно исправить без полного переписывания.
-
В процессе разработки — отвечает на вопросы коллег, проверяет критичные части кода (аутентификация, управление доступом, работа с данными пользователей), поддерживает стандарты безопасного кода.
-
В CI/CD-пайплайне — настраивает и поддерживает автоматические инструменты сканирования. Каждый коммит проходит проверку; критичные находки блокируют слияние.
-
При аудитах и запросах заказчиков — обеспечивает доказательную базу: внедрены такие-то меры защиты, проведены такие-то проверки, вот журналы. Это особенно важно при работе с корпоративными клиентами и при проверках регуляторов — ФСТЭК России (Федеральная служба по техническому и экспортному контролю) и Роскомнадзора.
Что нужно обеспечить со стороны руководства
Чтобы лидер безопасности мог работать эффективно:
- Выделите время — 20–30% рабочего времени лидера безопасности на задачи ИБ, зафиксированные в KPI. Без этого задачи безопасности будут вечно отодвигаться ради «срочных» функций.
- Дайте полномочия — право требовать исправления критичных проблем до выхода в продакшн, участвовать в планировании функций. Без полномочий лидер безопасности превращается в декоративную роль.
- Обеспечьте инструменты — базовый набор инструментов сканирования. Большинство open-source решений бесплатны; коммерческие российские продукты стоят от нескольких сотен тысяч рублей в год.
- Транслируйте сигнал команде — безопасность является частью качества продукта, а не отдельным проектом «для проверяющих».
Масштабирование на несколько команд
Если у вас несколько команд разработки, имеет смысл назначить лидера безопасности в каждой. Главный лидер безопасности (или ведущий специалист ИБ) координирует сеть: устанавливает единые стандарты, разбирает сложные случаи, проводит ежемесячные синхронизации.
Такая модель масштабирует безопасность без найма выделенных специалистов ИБ в каждую команду — и без создания отдельного отдела ИБ, который отстаёт от реального темпа разработки.
Метрики для руководителя
| Метрика | Ориентир |
|---|---|
| Доля уязвимостей, закрытых до продакшна | Цель — свыше 70% |
| Среднее время закрытия критичной находки | До 24 часов |
| Охват новых функций проверкой требований ИБ | 100% функций с пользовательскими данными |
| Количество критичных находок на внешнем пентесте | Снижение год к году |
Собирайте эти данные ежеквартально и сравнивайте динамику.
См. также
- Основы безопасного кода — с чего начинается безопасный код
- Учебная программа — какие компетенции требовать от команды
Что дальше
Следующие главы дают конкретный материал для требований к команде разработки:
- Основы безопасного кода — классы уязвимостей OWASP Top 10, что требовать от разработчиков и как убедиться, что требования выполнены
- Управление требованиями безопасности — как формализовать, отслеживать и верифицировать требования ИБ в процессе разработки
- Безопасность CI/CD — автоматическое сканирование кода, зависимостей и образов контейнеров в пайплайне
Начнём с того, что чаще всего идёт не так в коде.