Как оценить зрелость процессов безопасности

Безопасность разработки легко свести к набору инструментов.

SAST есть. DAST есть. Пентест сделали. Уязвимости считаем.

Но наличие сканеров ещё не означает, что процесс безопасности зрелый.

Мне больше нравится смотреть на безопасность как на систему: что происходит на всём пути от идеи до production.

Для базовой оценки я использую два фреймворка. OWASP SAMM

OWASP SAMM помогает разложить безопасность разработки на несколько направлений: — Governance — Design — Implementation — Verification — Operations

По каждому направлению можно оценить текущий уровень зрелости и понять, что должно появиться дальше: процессы, роли, практики, метрики и инструменты.

По сути, SAMM помогает ответить на вопрос: «Как должна развиваться наша система безопасной разработки?»

Оценку при этом логично делать совместно CTO и CISO.

Потому что часть изменений лежит в инженерных процессах, а часть — в ИБ и управлении рисками.

BSIMM

Второй полезный инструмент — BSIMM.

Его ценность немного в другом. Он построен на исследовании практик, которые реально применяются в крупных организациях.

То есть позволяет посмотреть не только на целевую модель, но и на то: «А как это делают другие компании?»

Для финтеха это особенно полезно, потому что поверх базовой разработки всегда появляются дополнительные требования: PCI DSS, регуляторика, защита платёжных данных, управление доступом, антифрод и так далее.

При этом я бы не пытался внедрять ни SAMM, ни BSIMM буквально.

Для меня это скорее инструменты диагностики и ориентиры.

А дальше уже начинается самое интересное — как это приземлить в обычный SDLC.

Например, на этапе планирования можно делать threat modeling и фиксировать риски ещё до разработки. На этапе проектирования — архитектурный анализ, проверку доступов и потенциальных поверхностей атаки.

Во время разработки — SAST, проверку зависимостей, поиск секретов в коде.

На тестировании — DAST, fuzzing, ручные проверки.

Перед релизом — финальную проверку артефактов, конфигураций и критичных уязвимостей.

А в production — мониторинг, управление инцидентами, контроль патчей и время реакции.

То есть безопасность перестаёт быть отдельной активностью где-то перед релизом.

Она становится частью всей цепочки: планирование → проектирование → разработка → тестирование → релиз → эксплуатация

Пример такой раскладки — с контролями, инструментами и метриками — вынес отдельно на картинку.

И вот здесь для меня главный показатель зрелости.

Не фраза: «У нас есть DevSecOps».

А возможность показать: какие риски мы контролируем на каждом этапе, чем именно контролируем и как понимаем, что становимся лучше.