Модель Security Champion многим кажется очевидной: если внутри команды появляется человек, который смотрит на продукт еще и с точки зрения безопасности, всем становится лучше. Но на деле путь от формального назначения до реально работающей роли гораздо длиннее и тернистее, чем кажется.

Привет, Хабр! На связи Илья Шаров (@issharov), Head of DevSecOps, и Николай Лузгин, DevSecOps Lead из МТС Web Services. Мы тоже через это проходили и в какой-то момент пересмотрели весь подход. Если в прошлый раз мы рассказывали о пользе, ролях и о том, что стоит предусмотреть при внедрении Security Champion, то сегодня поделимся опытом трансформации: как сместили фокус на вовлеченность, развитие компетенций и естественное встраивание безопасности в повседневную работу команд.

Как программа работала раньше

Мы не пытались запускать программу Security Champion как абстрактную «лучшую практику» — сразу учитывали ценность для бизнеса и команд. Об этом подробно рассказывали в прошлом посте, а здесь поделимся основной логикой.

Схема была выстроена так.

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

2. Договорились с руководителями. Линейный или функциональный руководитель Security Champion должен был знать о программе и согласовать новые трудозатраты сотрудника. Без этого участие человека легко могло сорваться. Иногда руководители сами брали на себя эту роль.

3. Выбрали Security Champion на команду. В первую очередь искали людей, которым действительно интересна безопасность продуктов. Это снижало риск превращения роли в обязанность «для галочки». Но при этом в каждой команде обязательно должен был быть один Security Champion — его отсутствие влияло на выполнение требований ИБ. Так что если инициативы не было, человека приходилось назначать принудительно.

4. Сделали простой вход. Чтобы программа не отпугивала участников, на старте задачи и трудозатраты закладывались небольшими. В инициативу можно было попасть независимо от текущей экспертизы. Модель строилась не вокруг поиска готовых AppSec-экспертов внутри команд, а вокруг постепенного вовлечения и роста людей, которым тема интересна. На практике вход чаще начинался с базового обучения по DevSecOps — чтобы дать общее понимание направления, его ценности и связи с повседневной инженерной работой.

5. Выбрали помощника. Среди массы Security Champion выбирали тех заинтересованных, кто хотел разобраться в области безопасности. С ними определяли объекты для исследования и инициировали проверки. Дальше проводили их и с помощью инструмента анализа формировали отчет. После этого Security Champion просматривал результаты и при необходимости обращался к эксперту DevSecOps за консультацией. Вместе они разбирали результаты и принимали решение, какие срабатывания действительные, а какие ложные. Это работало, но не всегда.

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

7. Формализовали сценарии работы. Собрали playbook для процессов с участием Security Champion. Такой подход снимал недопонимание: всем заранее понятно, кто за что отвечает, когда подключается ИБ, какие действия предпринимать при нахождении уязвимости и как выглядит завершение процесса.

Но даже при таком выстроенном процессе у системы были недостатки.

С какими сложностями мы столкнулись 

У прежней схемы были сильные стороны: понятная роль, понятная точка входа по вопросам безопасности. Но в этом же скрывались и главные риски:

• Размытый фокус и перегрузки. Очень быстро команда и ИБ начинала воспринимать Security Champion как человека, который отвечает за все вопросы безопасности. К нему шли и по профильным темам, и по смежным — просто потому, что его назначили. Один чемпион со временем сильно перегружался, фокус размывался, а на профильные задачи оставалось все меньше времени.

• Базовых курсов не хватало. Мы поняли, что несистемные обучения и курсы на корпоративном портале не дают желаемых результатов. А перегруз по текущим обязанностям и дополнительная ответственность перед ИБ совсем не мотивируют изучать что-то еще. Сами курсы были скорее для начинающих — это мешало тем, кто хотел развиваться дальше, до продвинутых практик и навыков.

• Назначенные участники не стремились развиваться в безопасности. Они разбирались только с конкретными кейсами от коллег и тем минимумом, который требовали ИБ. Поэтому становились не более ценными и компетентными сотрудниками, а более уставшими и недовольными.

• Непонятно, кого и чему обучать. Команды нужно было обучать информационной безопасности. Но чему именно? Можно сформулировать как «писать безопасный код» или «создавать безопасный продукт». Но за этими формулировками скрываются совершенно разные вещи. Речь о безопасности инфраструктуры: SSL-сертификатах, шифровании, разграничении доступа? Или о валидации и санитизации данных, защите от типовых уязвимостей, фильтрации пользовательского ввода? Мы не знали, какими знаниями уже обладают сотрудники, какие навыки им действительно нужны.

Было очевидно, что нужно что-то менять.

Что поменяли

А теперь о самом главном — что мы придумали, чтобы решить все эти проблемы.

Сделали ставку на рост профессиональной ценности специалистов

Теперь в командах не один формальный Security Champion, а несколько человек, которые развиваются в теме безопасности в рамках своей основной специализации. Это сотрудники, которые не берут на себя обязательства, но целенаправленно прокачивают экспертизу и применяют ее в своей роли. Мы даже выделили более мягкий формат взаимодействия и называем таких коллег «героями безопасности».

Фактически, это попытка исправить ситуацию с «единым окном входа» в лице Security Champion. Конечно, она не исчезла полностью, но через повышение общего уровня осознанности и распределение знаний внутри команды нагрузка снижается — как на ИБ, так и на SC. Становится больше людей, с которыми можно обсуждать изменения и ошибки при проектировании или разработке.

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

Отдельно этот подход оказался полезен и для сильных, опытных специалистов, которым в своей основной роли уже тесно. Условному сеньору не всегда интересно просто продолжать делать то же самое на все более высоком уровне. Иногда ему нужен новый интеллектуальный вызов, новая область, в которой можно собрать дополнительную экспертизу и стать для команды центром знаний. Безопасность как раз может стать таким направлением.

Создали сообщество и стали активнее использовать каналы коммуникаций

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

Созданное сообщество — гильдия DevSecOps — играет важную роль. В компании она стала частью большой инженерной гильдии DevOps. Мы стремимся объединять людей: и тех, кому просто интересны изменения в направлении безопасности, и тех, кто активно развивает экспертизу и готов помогать другим сотрудникам компании.

Поддерживать ритм помогает организационная роль комьюнити-менеджмента. Один человек занимается коммуникациями, второй — лидер гильдии — планированием мероприятий, согласованием, подбором материалов и работой со спикерами. Разумеется, это не их основная работа, а дополнительная важная роль в системе.

Регулярно проводим активности для сообщества

Не только классические митапы, но и демо, воркшопы, Q&A-сессии, разборы практических кейсов. Где-то рассказываем, что уже изменилось и какие новые практики появились, где-то объясняем, как подключиться к инициативе, а еще делимся планами и собираем обратную связь от команд.

Если смотреть на динамику, мы видим, что это постепенно стало устойчивой практикой. В 2023 году, когда направление только формировалось, таких встреч было буквально несколько. В 2024 активность заметно выросла, а в 2025 году мы провели уже 18 мероприятий. Есть и другие признаки масштабирования: ИТ-кластеры стали самостоятельно включать темы безопасной разработки в свои мероприятия, выделяются опорные продуктовые команды, продвигающие инженерные практики DevSecOps. Это хорошие индикаторы того, что тема перестала быть локальной инициативой и стала частью постоянной работы с сообществом.

Встроили ИБ в повседневную работу

Результаты сканирования инструментов доступны всей команде разработки. С ними нужно работать — это влияет на показатели команды и безопасность продукта, на основе которых оценивается технологическая зрелость. Даже если сотрудник не является официальным Security Champion, он все равно погружается в ИБ — через отчеты об уязвимостях, плагины в IDE и другие инструменты, которые доступны всей команде. Такой формат позволяет вовлекать людей без давления и ощущения, что на них повесили новую функцию.

Так ситуация, в которой Security Champion отвечает на вопросы ИБ по продукту, а потом остается один на один с надеждой, что он сам пойдет что-то изучать, изменилась. Теперь обучение вшито с этапа онбординга до непосредственного применения знаний в работе и их расширения через курсы, материалы, сообщество.

Добавили в онбординг вводный курс по DevSecOps

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

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

Создали систему обучения 

Теперь обучение развивается как отдельная система: с картами компетенций, ролевыми треками и постепенным наращиванием материалов. Материалы постоянно дорабатываются: примерно раз в квартал появляются новые курсы, а содержание обновляется по мере выявления новых потребностей и пробелов. Сейчас мы отслеживаем результаты через зрелость прохождения обучения и общий прогресс по ролям, а более детальная аналитика — в планах. 

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

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

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

Включили профиль DevSecOps в карты компетенций

Помните проблему, что мы не понимали, чему обучать команды? Так у нас появилась практика работы с картой компетенций. Мы начали формировать отдельный профиль в области DevSecOps и на его основе собирать обучающие треки — как общие, так и специализированные под конкретные ИТ-роли. 

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

Усовершенствовали систему мотивации 

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

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

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

Активные команды выполняют это легко — они и так вовлечены и просто получают хорошую оценку. А для тех, кто в тени или отрицании, это становится стимулом познакомиться с текущими процессами, не тратя много времени и сил команды.

Какие результаты мы получили

Что нам дали такие изменения?

Органически выросла вовлеченность

Мы сознательно отошли от модели, в которой безопасность становится для человека еще одной обязательной нагрузкой. Если раньше на выделенного чемпиона постепенно замыкались дополнительные обязанности, то теперь мы смотрим на эту историю шире — как на инструмент развития компетенций, осознанности, вовлеченности и профессионализма людей, которые участвуют в создании ИТ-продукта.

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

Тимлиды стали драйверами изменений

Часто Security Champion ставился СТО или DevOps — специалисты, которые понимают и архитектуру, и инфраструктуру, и код. Но один из новых «героев безопасности» — это тимлид. И это максимально логично: он имеет высокую степень ответственности, заинтересован в хорошем продукте, «свой» для разработчиков и имеет среди них авторитет — человек, которого уважают на 100%. Теперь Security Champion не выполняет роль посредника между ИБ и тимлидом, он сам берет на себя эту функцию — задает вопросы, инициирует диалог, а еще к нему можно обратиться напрямую, без лишних согласований. Тимлиду это тоже упрощает жизнь, так как аспект ИБ становится прозрачнее.

Нагрузка перестала замыкаться на одном человеке

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

Появились проводники практик внутри команды

Они помогают не только решать конкретные вопросы, но и снижают трение между безопасностью и разработкой. За счет этого внедрение практик идет мягче, а у ИБ-команды освобождается ресурс. Для самого сотрудника это тоже прикладная ценность: он становится заметнее внутри команды, лучше понимает смежную область, умеет разговаривать и с разработкой, и с безопасностью, помогает коллегам и становится точкой расширенной экспертизы. Это повышает его профессиональный вес и делает роль более устойчивой.

Инженерная зрелость стала выше 

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

Это следующий виток профессионального развития. Например, когда мы показываем продуктовым командам, как пароль пользователя может быть использован для инъекций в запросы баз данных и получения несанкционированного доступа — это часто вызывает разрыв шаблона. Казалось бы, просто пароль — что с ним можно сделать? А оказывается...

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

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

А какие изменения вносили в процессы вы, чтобы улучшить эффект от внедрения практик?