Четыре AppSec-инженера на 47 продуктовых команд - с такого расклада я начинал строить программу security champions в компании с тремястами разработчиками. Без чемпионов всё шло предсказуемо: critical-находки из Semgrep зависали в бэклоге неделями, threat modeling случался только перед внешним аудитом, а Slack-канал #appsec-questions работал как чёрная дыра с SLA «ответим через два дня». За полтора года программа амбассадоров безопасности изменила расклад - не лозунгами о «DevSecOps культуре безопасности», а конкретными процессами с измеримым результатом.
Почему AppSec-команда не масштабируется без сети security champions
Проблема не в том, что AppSec-инженеры плохо работают. Проблема в ratio: один security-специалист на 50–100 разработчиков. Нанять ещё одного - полгода поисков на дефицитном рынке плюс согласование бюджета с C-level. Нанять пятерых - утопия для большинства компаний.По OWASP Security Champions Playbook, один специалист по безопасности может тянуть пять Security Champions, каждый из которых работает со своей командой. Без этого промежуточного звена тот же специалист пытается покрыть все пять команд напрямую и проигрывает по контексту. Он не знает кодовую базу, не понимает бизнес-логику, не успевает на design review. Чемпион видит pull request с небезопасной десериализацией раньше, чем её поймает SAST, - потому что сам этот код писал.
OWASP SAMM (Education and Guidance, Stream B) описывает Security Champions как базовый элемент встраивания безопасности в разработку. На практике разница выглядит так: без чемпионов AppSec-команда работает реактивно - нашли уязвимость, создали тикет, ждём фикса. С чемпионами - проактивно: чемпион увидел проблему на этапе проектирования, исправили до того, как код попал в репозиторий. Это напрямую бьёт по OWASP Top 10 A04:2021 - Insecure Design: проблемы проектирования, которые не ловятся одним тестированием.
Security champion в разработке - первая линия обороны на уровне команды. Когда разработчик получает Spearphishing Attachment (T1566.001, Initial Access) или натыкается на подозрительную зависимость в
package.json, чемпион распознаёт вектор быстрее, чем сообщение дойдёт до SOC. Это не замена централизованного мониторинга, а дополнение - с продуктовым контекстом, которого у SOC нет. Подход shift left security здесь работает буквально: безопасность смещается к разработчику, который находится ближе всего к коду.Роль security champion в компании: что входит и что нет
Русскоязычное сообщество часто путает три смежные роли. В Авито описали модель Security Business Partner - выделенного сотрудника ИБ-департамента, погружённого в процессы конкретного бизнес-направления. В VK применяют связку Security Champion + AppSec-аналитик. Разница принципиальная, и без её понимания программа security champions обречена.| Критерий | Security Champion | AppSec-аналитик | Security BP |
|---|---|---|---|
| Принадлежность | Команда разработки | Команда ИБ | Команда ИБ |
| Время на security | 15–20% | 100% | 100% |
| Преимущества | Знает код и продукт; масштабируется (1 на команду) | Глубокая security-экспертиза | Погружён в бизнес-вертикаль |
| Ограничения | Базовая экспертиза; требует мотивации и обучения | Не масштабируется; не знает продукт | Дорого; долгий онбординг в бизнес |
| Когда использовать | 5+ команд разработки, нехватка AppSec-кадров | Любая компания с SSDLC-процессами | Крупная компания с отдельными бизнес-вертикалями |
| Когда не использовать | Менее 3 команд (AppSec справится напрямую) | - | Нет сложной оргструктуры |
Чемпион - не «дежурный по безопасности», назначенный приказом руководителя. По OWASP Security Culture Project, чемпионы должны быть номинированы, а не назначены. На практике принудительное назначение убивает мотивацию за первые два-три спринта: человек формально выполняет обязанности, но инициативы - ноль.
Что входит в обязанности security champion:
- Запуск и сопровождение практик безопасной разработки в своей команде
- Участие в threat modeling по методике STRIDE на этапе проектирования фич
- Первичный разбор находок из SAST/SCA (Semgrep, Snyk, Checkmarx) - определение true/false positive, приоритизация
- Обратная связь с AppSec-командой: эскалация сложных кейсов, участие в еженедельных синках
- Проверка кода на соответствие внутренним гайдам по безопасной разработке
- Самостоятельное проведение пентестов
- Написание detection rules для SIEM
- Ответственность за compliance (PCI DSS, 152-ФЗ)
- Полная замена AppSec-специалиста
Построение security champions программы: три ключевых шага
Шаг 1. Аудит команд и baseline зрелости
Перед запуском зафиксируйте текущее состояние - иначе через полгода не сможете доказать руководству, что программа работает. Я видел, как хорошие программы закрывали просто потому, что никто не записал «было» и не смог показать «стало».Что собрать:
- Карта команд: количество, размер, стек. У Java-команд свои типичные уязвимости (десериализация, JNDI injection), у Python - свои (pickle, SSRF через requests)
- Текущие security-инструменты: что уже внедрено (SAST, SCA, DAST), кто разбирает находки, каково среднее время исправления critical-уязвимостей
- Коммуникации: как разработчики задают вопросы по безопасности - Slack-канал, wiki, email, устно на стендапе
- Зрелость по OWASP SAMM или OWASP DSOMM: хотя бы верхнеуровневая оценка по домену Education and Guidance. DSOMM особенно полезен, если компания уже на пути к DevSecOps
Шаг 2. Согласование роли и бюджета с руководством
Без management buy-in программа мертва. OWASP формулирует прямо: «A Security Champion will need to have a percentage of time set aside from their regular position». На практике это 15–20% рабочего времени, и тут начинается самое интересное - это означает снижение скорости разработки на ту же долю. Если руководство не готово к этому - программа security champions не взлетит. Точка.Что согласовать:
- Объём времени: не менее 20% от рабочей нагрузки чемпиона (рекомендация OWASP)
- Формат отчётности: дашборд в Jira/Confluence, а не устные отчёты. Визуализация - аргумент для следующего раунда бюджетирования
- Критерии успеха пилота: конкретные метрики (подробнее в разделе про KPI)
- Куратор из AppSec: один куратор на пять чемпионов максимум - пропорция из OWASP Playbook
Шаг 3. Отбор кандидатов и пилотный запуск
По данным Security Champion Program Success Guide (Dustin Lehr), generic-запросы на общих встречах - худший способ набора. Разработчики не реагируют на «кому интересна безопасность - запишитесь». Как внедрить security champions без формального принуждения - три работающих подхода:- Рекомендации тимлидов: попросите каждого тимлида назвать одного-двух человек, которые уже проявляют интерес к безопасности - задают вопросы про уязвимости, обращают внимание на проблемы в code review
- Персональные приглашения: объясните конкретному разработчику, почему именно он подходит и что это даёт его карьере. По данным CISO TradeCraft, персональное обращение с указанием конкретного поведения («ты первый заметил проблему с авторизацией в PR-1234 - из тебя отличный чемпион») работает в разы лучше массового запроса
- Анализ поведения: посмотрите, кто чаще обращается в AppSec с вопросами - это естественные кандидаты в security champions
На пилоте отслеживайте:
- Готовность команды выделять время чемпиона на security-задачи
- Качество коммуникации «чемпион - AppSec-куратор»
- Реальную нагрузку на чемпиона (превышает ли 20%)
- Обратную связь от разработчиков и тимлидов
Обучение security champions: от OWASP Top 10 до threat modeling
Чемпион - не AppSec-инженер, и не нужно делать из него такового. Программа обучения security champions строится ступенчато, и тут главное - не перегрузить человека в первый же месяц.Уровень 1 (первый месяц) - базовые концепции:
- OWASP Top 10: не слайды, а разбор реальных находок из вашей кодовой базы. Покажите, как выглядит SSRF в конкретном микросервисе, а не абстрактная диаграмма из презентации
- Безопасное управление зависимостями (SCA: Snyk, OWASP Dependency-Check). Чемпион должен понимать, когда обновление зависимости критично, а когда можно подождать
- Процедура эскалации: что чемпион решает сам, что передаёт в AppSec
- Threat modeling по STRIDE: чемпион должен уметь провести 60-минутную сессию для своей команды с фиксацией результатов в Confluence
- Secure code review: не full-scale review, а checklist-подход - проверка авторизации, валидации input, обработки ошибок, использования криптографических функций
- Работа с SAST: разбор findings в Semgrep или Checkmarx, навык определения true/false positive. Тут, кстати, самый частый вопрос от новых чемпионов - «а откуда я знаю, что это false positive?». Ответ: контекст. Чемпион знает свой код, и именно поэтому он справляется с этой задачей лучше, чем AppSec-инженер, который видит этот репозиторий впервые
- Архитектурные паттерны безопасности (zero trust, defence in depth на уровне микросервисов)
- OWASP ASVS как чеклист для верификации безопасности приложений
- Участие во внутренних CTF для поддержания интереса и прокачки навыков
Формат синков с AppSec-командой: еженедельная встреча на 30 минут. Повестка - разбор находок за неделю, сложные кейсы, обновления инструментов. Отдельный Slack-канал для быстрых вопросов с SLA «ответ в течение четырёх рабочих часов».
Мотивация security champions и защита от выгорания
Самый частый провал программ - выгорание чемпионов через 4–6 месяцев. Человек берёт дополнительные обязанности, не получает за это ни признания, ни карьерного роста и тихо уходит обратно в чистую разработку. Я наблюдал это не раз, и каждый раз причина одна - компания хочет security champions «бесплатно».Модель SAPS из руководства CISO TradeCraft предлагает четыре уровня мотивации security champions:
- Status (Статус): публичное признание. Чемпион упоминается в отчётах команды, его вклад виден руководству. Левелинговая система - Junior Champion, Senior Champion, Security Advocate - с привязкой к грейду разработчика
- Access (Доступ): чемпион получает информацию, недоступную остальным - результаты пентестов, инсайты об инцидентах компании, ранний доступ к новым security-инструментам
- Power (Влияние): голос в security-решениях для своей команды, участие в архитектурных review, право блокировать merge request с critical-уязвимостью
- Stuff (Материальное): оплата конференций, мерч, бонусы. Работает как дополнение, не как основной мотиватор
- Жёсткий лимит времени: не более 20% на security-задачи. Если чемпион тратит больше - это сигнал перегрузки, а не эффективности
- Ротация: через 12–18 месяцев предложите чемпиону передать роль и перейти на уровень ментора новых чемпионов - или вернуться к чистой разработке без стигмы
- Официальное снижение sprint velocity: команда чемпиона получает пересчитанный target. Без этого чемпион разрывается между основными задачами и информационной безопасностью бизнес-подразделения - и проигрывает на обоих фронтах
Метрики программы security champions: какие KPI работают
Измерять программу нужно с первого дня пилота. Без метрик программа security champions неизбежно превратится в «активность для галочки».KPI, которые реально показывают эффект:
- MTTR (Mean Time to Remediate): среднее время от находки SAST/DAST до фикса - сравниваете команды с чемпионом и без. Это самый честный показатель
- Доля проблем, найденных на design review: чем она выше, тем эффективнее shift left. Целевой рост - 30–50% за первый год
- Покрытие threat modeling: доля команд, регулярно проводящих threat modeling за квартал (цель - 100%)
- NPS чемпионов: довольны ли они ролью, не выгорают ли. Анонимный опрос раз в квартал
- «Количество обученных разработчиков» - показывает охват, не влияние
- «Число проведённых тренингов» - метрика активности, не результата
- «Количество закрытых тикетов по безопасности» - провоцирует создание мусорных тикетов ради красивой отчётности. Видел это своими глазами: чемпион создавал тикеты на missing security headers для внутренних сервисов, чтобы набить счётчик
В Авито использовали Team Maturity Model (TMM) с секцией «информационная безопасность», включающей регулярное обновление уязвимостей, оценку рисков и моделирование угроз. Аналогичную модель зрелости можно выстроить на базе OWASP DSOMM, адаптировав категории Culture и Education под специфику компании.
Чеклист: запуск программы security champions за 90 дней
Большинство программ security champions в российских компаниях, которые я наблюдал, проваливаются не из-за нехватки кандидатов и не из-за плохих инструментов. Они проваливаются по одной причине: руководство не готово официально выделить чемпиону время. Формально программа объявлена, чемпионы отобраны, Slack-канал создан - но sprint velocity команды не пересчитана. Чемпион работает «в свободное от работы время», которого у разработчика нет по определению. Через три-четыре месяца он тихо перестаёт заходить в канал по безопасности. Через полгода программа существует только в презентации для совета директоров.
Если вы не готовы снизить скорость разработки на 15–20% в командах с чемпионами - не запускайте программу. Запустите вместо этого набор AppSec-аналитиков и встройте их напрямую в команды по модели Security BP, как сделали в Авито. Это дороже, но честнее: вы платите за полную ставку человека, а не за волонтёрство, которое умирает без подпитки.
Security champions - инвестиция, которая окупается только при полном организационном commitment. Полумеры дают полурезультат: формальных чемпионов, формальные тренинги и реальные уязвимости в production. Попробуйте пройти чеклист выше и честно ответить на пункт 4 - если management buy-in нет, всё остальное не имеет смысла. Выбор всегда за тем, кто подписывает бюджет.
