Код под охраной: как найти AppSec/DevSecOps-специалиста и измерить отдачу от безопасной разработки

В мире ускоренной разработки ПО безопасность больше не может ждать финального этапа. Ею нужно заниматься с самого начала. Этим сегодня прониклись даже стартапы – по прогнозам экспертов, около 30% российских компаний-разработчиков проприетарного ПО в ближайшие годы внедрят DevSecOps (источник vc.ru). В 2023 году интерес к безопасной разработке стали проявлять даже те, кто раньше не планировал строить процессы ИБ. Вместе с ростом популярности методологии растёт потребность в профильных специалистах.

Но из-за дефицита кадров компаниям непросто найти экспертов по безопасной разработке. В среднем на одну открытую вакансию в сфере информационной безопасности приходится менее одного резюме – рынок фактически «принадлежит» кандидату. В таких условиях чётко и привлекательно прописанная должностная инструкция (JD) для роли Application Security (AppSec) / DevSecOps становится критически важной: она не только поможет заманить нужного профи, но и задаст прозрачные ожидания по его задачам и результатам. А дальше возникает не менее важный вопрос: как измерить эффективность работы этого специалиста? HR-руководители нередко ломают голову над тем, как оценить пользу AppSec/DevSecOps-инициатив, ведь на первый взгляд результат «невидим» (в идеале инциденты просто не происходят).

Чтобы ответить, сперва нужно понять, кто такие специалисты AppSec/DevSecOps и чем они занимаются. Многие почему-то ставят «аппсеков», «девсекопсов», девопсов, пентестеров, аналитиков и разработчиков в один ряд – по мнению экспертов, это фундаментальная ошибка (источник habr.com). Хотя каждый из них точно востребован на рынке, у каждой роли своя специфика. Разберёмся в терминах: Application Security (AppSec) – практика обеспечения безопасности приложений.

Это обнаружение и исправление уязвимостей, внедрение безопасных подходов к кодированию, соответствие требованиям стандартов и регуляторов. DevSecOps – скорее культурная и процессная методология (аббревиатура от Development, Security, Operations), которая встраивает безопасность на всех этапах конвейера разработки (источник securitycompass.com). Проще говоря, DevSecOps интегрирует проверки безопасности непрерывно в жизненный цикл ПО, делая их общей обязанностью команды, а не отдельным финальным шагом.

На практике роли AppSec и DevSecOps могут пересекаться, и нередко в компании ищут «универсала», способного закрыть оба направления. Тем не менее, можно обозначить разницу акцентов. DevSecOps-инженер фокусируется на том, как встроить инструменты безопасности в процессы DevOps. Он обеспечивает, чтобы необходимые проверки запускались автоматически на каждом шаге – от коммита кода до деплоя. Этот специалист выстраивает безопасный CI/CD-пайплайн, автоматизирует сканирование кода, настройку инфраструктуры, следит, чтобы технологический стек (контейнеры, облако и т.д.) был правильно сконфигурирован и интегрирован в процесс разработки. Также DevSecOps-инженер участвует в создании проектной документации, подготовке пользовательских инструкций, формировании базы знаний, консультирует команды разработки, эксплуатации и ИБ по работе инструментов безопасности.

AppSec-инженер же сосредоточен на анализе уязвимостей и обеспечении конкретных приложений защитой. По сути, он разбирает всё, что нашли инструменты безопасной разработки, и добивается устранения этих проблем – занимается триажем уязвимостей, помогает разработчикам исправлять баги. В идеальной картине мира в команде есть и AppSec-аналитики, отвечающие за процессы и методологию (определяют путь развития безопасной разработки, анализируют регуляторику и предлагают инициативы), и тестировщики на предмет безопасности (пентестеры), которые вручную проверяют, не осталось ли в логике приложения брешей, не видимых автоматическим сканерам. Но понятно, что не каждая компания может позволить себе целый штаб. Чаще ищут одного-двух специалистов, чтобы выстроить AppSec/DevSecOps-направление с нуля. А это значит, что в JD (должностной инструкции) надо грамотно обозначить обязанности, охватывающие несколько сфер, чтобы и компания, и кандидат понимали зону ответственности.

Что просить: ключевые задачи и навыки в JD

Описание вакансии AppSec/DevSecOps-специалиста должно отражать многогранность роли. Главная миссия ясна: гарантировать, что безопасность встроена в процесс разработки, а не «прилажена» в конце. Но из чего складывается эта миссия в ежедневной работе? Перечислим ключевые обязанности, которые стоит включить в JD (даже если не списком, они должны быть донесены кандидату между строк):

• Интеграция безопасности в цикл разработки. Ваш будущий специалист будет «вшивать» контрольные точки безопасности в процессы CI/CD – например, настраивать статический анализ кода (SAST) для автоматического поиска уязвимостей перед слиянием изменений, динамическое тестирование (DAST) на тестовых стендах, анализ зависимостей (SCA) на уязвимые библиотеки и т.д.. Он проследит, чтобы каждый коммит триггерил нужные проверки, и незащищённый код не просочился в релиз. Как описывается в одной из статей, DevSecOps-инженер «внедряет ИБ-инструменты в инфраструктуру компании, контролирует безопасность вокруг процессов разработки, строит CI/CD-пайплайны и автоматизирует процессы обеспечения защищенности». Иными словами, он отвечает за то, чтобы все необходимые сканеры, мониторинги и проверки работали непрерывно на каждом этапе.
• Оценка уязвимостей и их устранение. Специалист будет проводить или организовывать анализ безопасности приложений и инфраструктуры. Его задача – не только находить уязвимости, но и доводить дело до конца, то есть устранять их (источник himalayas.app). Это включает ручной просмотр кода на типичные ошибки (SQL-инъекции, XSS, ошибки аутентификации и пр.), запуск автоматических сканеров, проведение проникнового тестирования (самостоятельно или с привлечением внешних команд) и, главное, сотрудничество с разработчиками для исправления найденных дыр. Сюда же относится и реагирование на инциденты: если вдруг случился инцидент (например, утечка или взлом), AppSec/DevSecOps-специалист участвует в расследовании, помогает закрыть уязвимое место и усиливает защиту, чтобы подобное не повторилось.
• Разработка политик и соответствие требованиям. Ожидайте, что ваш специалист возьмёт на себя развитие внутренних стандартов безопасности. Он либо разработает, либо внедрит политики, процедуры и лучшие практики, чтобы все проекты соответствовали нужному уровню защиты. К примеру, пропишет стандарты безопасного кодирования, требования к хранению секретов, правила реагирования на выявленные баги безопасности. Большой пласт – обеспечение соответствия нормативным требованиям. DevSecOps-инженер должен гарантировать, что процесс разработки и сам продукт не нарушают требований регуляторов и индустриальных стандартов. Если у вас e-commerce – следует PCI DSS; работа с персональными данными – будь добр соблюдать закон о защите персональных данных/GDPR; банковский сектор – стандарты Центробанка и ГОСТы, и т.д. Так что знание основных стандартов и нормативов – практически обязательный пункт. В резюме кандидата вы захотите увидеть знакомство с OWASP Top 10 (десять самых распространённых веб-уязвимостей), с ключевыми фреймворками и документами по безопасности. Как отмечает один из ресурсов, понимание принципов информационной безопасности и опыт работы с такими вещами, как NIST SP 800-53 или ISO/IEC 27001, являются необходимыми навыками для работы в DevSecOps-среде (источник it-vacancies.ru). Многие работодатели прямо ожидают, что кандидат знаком с основными фреймворками безопасной разработки – Microsoft SDL, OWASP SAMM, BSIMM – и со стандартами. Причём важно не только международное, но и отечественное: в финсекторе, например, пригодится понимание требований регулятора (стандартов ЦБ РФ 683-П, 802-П, 719-П, ГОСТ 57580 и «Профиля защиты» ЦБ) наряду с ISO 27001 и PCI DSS. Таким образом, юридическая грамотность и знание нормативной базы – это и есть те самые «правовые основы», которые отличают AppSec-специалиста: он должен уметь перевести регуляторные требования в практические меры защиты и удостовериться, что разработки им соответствуют.
• Понимание DevOps и навыки программирования. Поскольку DevSecOps – это надстройка над DevOps, сильному кандидату необходим крепкий фундамент в разработке ПО и инфраструктуре. Ему пригодятся знания операционных систем и администрирования (в 40% вакансий для DevSecOps фигурирует требование опыта с Linux-системами), понимание облачных технологий (рост облаков в РФ ~40% в год – не зря многие компании хотят, чтобы специалист умел безопасно работать с Kubernetes, Docker, Terraform и др. для Infrastructure as Code), опыт с инструментами CI/CD (Jenkins, GitLab CI и пр.). Почти 90% компаний ожидают владения хотя бы одним языком программирования – чаще всего упоминаются Python или Go, также ценятся Java, C#, Ruby, JavaScript, SQL и др.. Это неудивительно: чтобы строить эффективные процессы и разбираться в уязвимостях, специалист должен понимать код, который пишут разработчики, видеть, где могут прятаться ошибки безопасности. Ему, возможно, придётся самому писать скрипты для автоматизации проверок или даже предлагать патчи коду. Короче говоря, кандидат должен разговаривать с разработчиками на одном языке. Если обобщить технический стек знаний, который часто фигурирует в JD: уверенное владение DevOps-инструментами (контейнеризация, оркестрация, автоматизация конфигураций, системы контроля версий), понимание сетевых технологий (протоколы, межсетевые экраны, базовые вещи про VPN и т.д. – безопасность ведь не только на уровне кода), знание методик тестирования безопасности. Последнее подразумевает знакомство хотя бы с самыми распространёнными уязвимостями по OWASP и CWE, понимание причин их появления и методов предотвращения. Если человек знает, как работают SAST, DAST, SCA и прочие практики – и умеет воспользоваться инструментами для них (AppChecker, Positive Technologies Application Inspector, OWASP ZAP, etc.) – это огромное преимущество.
• Знание методологий безопасной разработки и умение моделировать угрозы. Лучшие специалисты – это не просто операторы сканеров, а стратеги. Они понимают, как выстроен Secure SDLC (безопасный жизненный цикл разработки), какие этапы он включает. Поэтому в требованиях нередко указывают умение проводить modeling threats (моделирование угроз) на этапе проектирования, знание принципов безопасного проектирования. Кандидату будет плюсом знакомство с методологиями Microsoft SDL, упомянутыми OWASP SAMM, BSIMM – то есть умение взглянуть на процесс разработки системно, с точки зрения безопасности. Проще говоря, AppSec/DevSecOps-специалист должен уметь настроить сам процесс, а не только реагировать на отдельные баги.
• Обучение и взаимодействие с командой. Эта роль требует постоянного взаимодействия между разными отделами. Ваш специалист по безопасной разработке практически обречён стать коммуникатором и наставником. Он должен быть способен объяснять разработчикам и тестировщикам сложные вещи про уязвимости простым языком, не вызывая отторжения. Провести внутренний митап или мини-курс по безопасному кодингу? Часто именно AppSec этим и занимается. Написать понятные чек-листы «как не надо делать»? Тоже к нему. Поэтому софт-скиллы невероятно важны. В данной профессии умение налаживать коммуникацию играет огромную роль – специалисту предстоит взаимодействовать с разработчиками, тестировщиками, системными инженерами, описывать архитектуру продукта и указывать на её недостатки с точки зрения безопасности. Навыки продуктивной работы с разными командами дают большое преимущество на рынке. Хороший AppSec-инженер становится своего рода евангелистом безопасности внутри компании, формирует культуру, при которой сами разработчики бегут к нему за советом, а не прячут голову в песок при слове «уязвимость». В JD стоит упомянуть, что вы ищете коммуникабельного кандидата, готового учить и наставлять – тогда откликнутся люди, которым действительно интересно взаимодействовать, а не сидеть в одиночку и молча ковырять код.

Очевидно, «идеальный» кандидат получается чуть ли не человек-оркестр: и в ПО разбирается, и в кибербезе дока, и с людьми умеет. Неудивительно, что такие уникумы на вес золота. На рынке за опытными DevSecOps-инженерами идёт настоящая охота – корпорации выделяют огромные ресурсы на расширенный соцпакет и всевозможные плюшки, чтобы переманить их. Зарплатные вилки простираются от ~80 тыс. руб. у джуниоров до 400+ тыс. у сеньоров.

Но деньги – не единственный аргумент: крутые специалисты обращают внимание на технологический стек и возможности развития. Многие давно привыкли к гибкому графику и remote, и компании идут навстречу (в 80% вакансий указана возможность удалённой работы и сдвинутого графика). HR-ам стоит учесть: чтобы заполучить такого кандидата, мало прописать требования – нужно заинтересовать. В тексте вакансии (и на собеседовании) желательно показать, что компания действительно ценит безопасность и даст новому специалисту полномочия, ресурсы и поддержку руководства. Ведь профессионалы охотнее идут туда, где безопасность – реальный приоритет, а не галочка для отчёта. И напротив, если в вакансии перечислить невыполнимый спектр обязанностей без намёка на поддержку, хороший кандидат может пройти мимо. Баланс тут тонкий: JD должен быть честным и прозрачным, но и «продающим» вашу компанию как правильное место для AppSec-энтузиаста.

Итак, с «что просить» (навыки и обязанности) определились. Не менее важно понять, что считать успехом на этой позиции. Как понять через полгода работы AppSec-инженера, что он действительно делает продукты безопаснее? Без четких критериев легко скатиться либо в субъективизм («вроде ничего не сломалось, значит, молодец»), либо в завышенные ожидания («раз у нас теперь есть безопасник, уязвимостей быть не должно вообще»). К счастью, индустрия выработала подходы к метрикам безопасности, которые позволяют оценить эффективность AppSec/DevSecOps – причём в понятных бизнесу показателях.

Как мерить результат: метрики безопасности и успеха

Представьте, прошло три месяца после найма AppSec-специалиста, и генеральный директор спрашивает: «Ну, что мы получили от инвестиций в безопасность? Нам вообще стало безопаснее?» Чтобы уверенно ответить, нужны ключевые показатели эффективности (KPI) для направления AppSec/DevSecOps. Эти метрики должны связывать технические улучшения с бизнес-результатами – показать, что безопасность – это не про «залатать дырки и ни о чём не рассказывать», а про поддержку стратегических целей компании (источник habr.com).

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

Какие же показатели могут служить индикаторами успеха AppSec/DevSecOps? Разделим их на несколько категорий:

1. Метрики снижения риска. Они отвечают на вопрос: насколько уменьшились угрозы для наших продуктов?

• Количество уязвимостей (особенно критических). Самый прямой показатель: сколько дыр в безопасности мы находим и как эта цифра меняется со временем. Успешная программа AppSec должна демонстрировать тенденцию к снижению числа критических уязвимостей. Если при запуске нового проекта находили 10 критичных багов, а через год подобных находок 2-3 – это явный прогресс. Важно смотреть динамику: не только абсолютные числа, но и их тренд от релиза к релизу. И конечно, не менее важно сколько из найденных уязвимостей устраняется – процент закрытых багов безопасности. Если выявляются сотни проблем, а фиксится лишь малая часть, грош цена такому AppSec. Идеальная картина – когда серьезные уязвимости не копятся, а оперативно гасятся.
• Плотность риска (vulnerability density). Этот показатель измеряет концентрацию уязвимостей относительно размера кодовой базы – например, число багов безопасности на 1000 строк кода. Он позволяет сравнивать проекты разной величины или следить, как улучшения в качестве кода снижают «дырявость». Скажем, было 5 уязвимостей на 10k строк, стало 1 на 10k – значит, код стал заметно «чище» в контексте ИБ. Высокая плотность уязвимостей, наоборот, сигналит, что процессы разработки требуют пересмотра: возможно, нужен дополнительный контроль качества, ревью кода, обучение разработчиков.
• Технический долг безопасности. По аналогии с техническим долгом в коде, это накопленные, но не устранённые проблемы безопасности в продуктивных системах. Чем дольше уязвимости остаются не закрыты, тем выше риск, что ими воспользуются злоумышленники. Регулярный мониторинг security technical debt показывает, успеваем ли мы разгребать проблемы. Если долг со временем сокращается – программа AppSec работает эффективно (устраняем бреши быстрее, чем появляются новые). Если растёт – тревожный знак: либо ресурсов не хватает, либо приоритет безопасности низкий. Кстати, сюда можно отнести и показатель средний возраст открытых уязвимостей: сколько в среднем времени баги безопасности висят невыправленными. Чем меньше, тем лучше.
• Сводный индекс риска. Некоторые компании вводят интегральный показатель, сочетающий количество уязвимостей и их критичность, взвешенный по важности системы для бизнеса. Например, 10 багов в публичном веб-сервисе дадут больший индекс риска, чем те же 10 багов в внутреннем приложении для офисных задач. Такой индекс позволяет отслеживать общий уровень безопасности важнейших систем. Если он снижается – риск для бизнеса падает, что, безусловно, хорошо.

2. Метрики покрытия и вовлечённости. Они показывают, насколько широко и глубоко практика безопасной разработки проникла в деятельность команды:

• Процент проектов, охваченных безопасными практиками. Другими словами, сколько наших приложений проверяется на уязвимости регулярно? Например, какой процент репозиториев подключен к SAST-сканеру, сколько сервисов проходит DAST перед релизом. Если при приходе специалиста лишь 20% проектов были под каким-либо контролем безопасности, а через год охват вырос до 80% – это колоссальный прогресс. Идеальная цель – 100%, чтобы не осталось «тёмных уголков», где безопасность неизвестна. Отдельно можно измерять покрытие по типам проверок: допустим, 70% критичных модулей проходят статический анализ, 50% – пен-тесты, и т.д. Рост этих чисел = рост контроля над ситуацией.
• Обучение и осведомлённость команды. Здесь отличные метрики – доля разработчиков, прошедших курсы по безопасной разработке, и количество проведённых внутренних тренингов. Повышение этих показателей означает, что AppSec-специалист активно делится знаниями и формирует культуру. Снижается повторяемость одних и тех же ошибок в коде – косвенно это тоже можно отследить, сравнивая типовые баги «до и после» обучения. Ещё показатель: средний срок подключения безопасности к проекту. В идеале команда ИБ (или ответственный за безопасность) вовлекается ещё на этапе дизайна нового продукта, а не за 2 дня до релиза. Можно замерять, на какой фазе SDLC обычно стартуют активности по безопасности, и стараться сдвинуть их влево (shift left). Чем раньше специалисты подключаются, тем меньше шансов пропустить что-то серьёзное.
• Соблюдение требований и процессов. Если мы внедрили какие-то обязательные правила (скажем, «перед деплоем все уязвимости уровня High должны быть закрыты» или «каждый merge request должен проходить код-ревью с точки зрения безопасности»), стоит мерить процент случаев, когда эти требования выполнены/нарушены. Например, процент невыполненных требований по ИБ – такая метрика предлагается для команды безопасности (источник cisoclub.ru). Она показывает, насколько реально соблюдаются установленные политики. Если сейчас, допустим, 20% релизов выходят с нарушением критериев безопасности (что плохо), стремимся снизить этот процент до нуля.

3. Метрики эффективности управления уязвимостями. Они отвечают за скорость и качество процесса обработки багов безопасности:

• Среднее время обнаружения уязвимости (MTTD). Показывает, сколько времени в среднем уходит с момента появления уязвимости до её выявления. Это во многом отражает эффективность мониторинга и тестирования. Если уязвимости «лежат» месяцы, прежде чем их заметят – беда. Хороший AppSec-процесс сокращает MTTD: уязвимости обнаруживаются, например, в течение недели с момента, когда разработчик допустил ошибку, или даже раньше (ещё на этапе code review).
• Среднее время на исправление (MTTR). В контексте уязвимостей – это сколько в среднем требуется времени, чтобы устранить баг после его обнаружения. Быстрый MTTR означает слаженный процесс: баги вовремя приоритизируются, разработчики оперативно выпускают патчи, DevOps быстро раскатывают фикс. Если раньше на устранение уязвимости уходило, скажем, 30 дней, а теперь 5 дней – это огромный прогресс.
• Среднее время на triage. Полезный промежуточный показатель – время, за которое команда безопасности анализирует новую найденную проблему и определяет приоритет/владельца для фикса. Чем быстрее осуществляется triage, тем быстрее начинается само исправление. Если triage затягивается на недели, фиксы тоже будут буксовать.
• Средний “возраст” открытых уязвимостей. Этот показатель мы упоминали: насколько долго в среднем проблемы безопасности остаются нерешёнными. Он отражает накопление «хвостов». Например, если средний возраст открытого тикета с уязвимостью – 180 дней, значит полгода баги висят непочиненными. Сокращение этого срока до, допустим, 30 дней будет отличным результатом.
• Отношение найденных/устранённых уязвимостей. Можно отслеживать коэффициент: сколько новых проблем обнаружено за период и сколько закрыто. Идеально – закрывать не меньше, чем обнаруживается, тогда общая «копилка» уязвимостей не растёт. На зрелом этапе хочется закрывать больше, чем приходит новых (устраняем старые долги). Если же на каждую исправленную проблему появляется три новых – значит, пока топчемся на месте или даже ухудшаем ситуацию. В DevOps-метриках есть аналогичный показатель open/close rate инцидентов. Здесь – то же самое, но применительно к багам безопасности.

4. Бизнес-метрики и метрики ценности. Эти показатели особенно важны для руководства, так как переводят усилия по безопасности на язык денег, времени и репутации:

• Влияние на скорость выпуска продукта. Одна из ключевых целей DevSecOps – не навредить скорости разработки, а лучше – ускорить её. Поэтому полезно отслеживать сквозное время поставки (lead time, от коммита до деплоя) и частоту деплоя – классические метрики DevOps. Если с внедрением дополнительных проверок эти показатели не ухудшились – уже хорошо (значит, безопасность встроена грамотно). А в идеале безопасная разработка даже сокращает время выхода на рынок: ведь исправлять серьёзные баги после релиза куда дольше, чем предотвратить их заранее. Интересно, что компании, прошедшие путь DevSecOps, отмечают общее ускорение поставок. Кроме того, стоит смотреть долю неуспешных изменений (change failure rate) – процент релизов, которые привели к проблемам и откатам. Если внедрение DevSecOps снижает число аварийных откатов, то безопасность действительно повышает надёжность продукта, уменьшая баги в продакшене. Ну и Mean Time to Restore (MTTR) сервисов после инцидентов – ещё один косвенный показатель: быстрая ликвидация последствий инцидента говорит о высокой готовности команды, которую часто обеспечивает именно наличие отлаженных процессов безопасности.
• Экономия затрат на исправления и предотвращённый ущерб. С точки зрения бизнеса, легко аргументировать пользу безопасности, посчитав, сколько денег она сэкономила. Например, общеизвестно, что баг, найденный на этапе кодинга, устраняется в разы дешевле, чем если его обнаружить уже в продуктиве (когда он мог привести к инциденту). Метрика может быть такой: стоимость предотвращённого ущерба – оценочно, на какую сумму компания могла попасть, если бы не устранили уязвимости до релиза. Конечно, это расчёт на основе допущений, но топ-менеджеры любят подобные оценки. Другой подход – измерить экономию рабочего времени. По данным Forrester, каждый разработчик тратит в среднем ~3,5% времени на устранение уязвимостей, а после внедрения DevSecOps этот показатель можно сократить примерно на 50%. Освобождённое время разработчики потратят на создание фич, то есть на прямую пользу бизнесу. Посчитайте: если у вас 100 девелоперов, 3,5% их времени – это 7 000 человеко-часов в год, половину из которых (3 500 часов) можно высвободить благодаря проактивной безопасности. В денежном выражении (помножив на среднюю зарплату) это может дать экономию в десятки миллионов рублей. Ещё одна бизнес-метрика – процент бюджета, тратимого на безопасность. Его можно сравнивать со средними по отрасли или анализировать динамику: растут ли вложения и приводят ли они к снижению инцидентов.
• Фактические инциденты и потери. В конце концов, цель всей этой деятельности – избежать успешных атак. Поэтому важно отслеживать количество реальных киберинцидентов (утечек, взломов) и ущерб от них – финансовый и репутационный. Если за год «до» у компании было, к примеру, 3 серьёзных инцидента, а за год «после» – ни одного, это самый наглядный результат. Правда, привязывать эффективность конкретного человека к отсутствию инцидентов рискованно (слишком много факторов). Но на уровне команды безопасности – вполне: нулевые инциденты – мечта, к которой стоит стремиться. А если инцидент произошёл, важно анализировать, как сработали механизмы защиты: возможно, атака обнаружена и нейтрализована быстро, ущерб минимален – это тоже показатель эффективности мер безопасности.
• Окупаемость инвестиций (ROI) в безопасность. Для особо скрупулёзных – можно вывести интегральную формулу ценности DevSecOps. В статье на CISOCLUB предложено считать разницу между прибылью, полученной благодаря внедрению безопасной разработки, и суммарными затратами на неё. Прибыль там включает всё вышеперечисленное: и бизнес-ценность новых фич, выпущенных благодаря росту доверия к продукту, и предотвращённый ущерб от рисков, и экономию ресурсов на устранении багов, и ускорение вывода продуктов на рынок. Практика показывает, что при правильном подходе DevSecOps окупается весьма быстро. Например, по данным Forrester, для крупной организации (~1500–2000 разработчиков) точка безубыточности инвестиций в одну из ведущих облачных DevSecOps-платформ может быть достигнута за ~3 месяца, а чистый приведённый эффект – более $2 млн в год. Разумеется, цифры для каждой компании будут свои, но общая тенденция такова: безопасная разработка – это не только затраты, но и прямая выгода (особенно по сравнению с расходами на устранение последствий кибератак, штрафов регуляторов и т.д.).

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

Разработке важны скорость и качество, безопасности – устранение рисков, бизнесу – окупаемость и отсутствие катастроф. Хороший пример: в отчёте DORA (DevOps Research and Assessment) четыре метрики используются для оценки эффективности DevOps-процессов – частота деплоя, время выхода изменений, процент неудачных релизов, время восстановления. Для DevSecOps можно взять их за основу и добавить 1-2 показателя по безопасности, скажем, среднее время на устранение уязвимости и количество критических багов на выпуск. Отслеживая такой набор, вы получите целостную картину: выпускаем быстро и безопасно.

Важно, чтобы ваш AppSec/DevSecOps-специалист с самого начала участвовал в формировании этой «метрической программы». Он поможет определить реалистичные целевые значения, настроить сбор данных (многие инструменты безопасности сразу дают удобные дашборды), и – что немаловажно – интерпретировать результаты. Метрики никогда не существуют в вакууме: если какой-то показатель застопорился или ухудшился, это сигнал обсудить проблему. Допустим, средний возраст уязвимостей растёт – почему?

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

Прежде чем подвести итоги, отметим: регулярная отчётность по выбранным KPI – отличный способ продемонстрировать ценность безопасности руководству. Вместо туманных «мы, кажется, стали безопаснее» у вас будут конкретные факты: «За последний квартал среднее время исправления критических уязвимостей сократилось с 15 до 5 дней, охват проектов проверками вырос до 100%, а потенциальный ущерб, предотвращённый благодаря найденным вовремя уязвимостям, оценивается в 5 млн руб.» Поверьте, такой разговор впечатлит куда больше, чем технические детали про новые файерволы и патчи. А для самого специалиста видеть прогресс в числах – лучшая мотивация (и отличный кейс, чтобы просить повышения в будущем).

Заключение

AppSec/DevSecOps-специалист – это новый ключевой игрок в вашей команде разработки, хотя его работа может быть и незаметна постороннему глазу. Нанимая такого человека, компания фактически приглашает «встроить» безопасность в свою ДНК. Для HR это означает, что нужно тщательно прописать в вакансии сочетание требуемых умений: от навыков программирования и автоматизации до глубоких знаний в кибербезопасности и умения быть наставником. В тексте JD важно отразить, чего вы ждёте от специалиста (внедрит инструменты в pipeline, обучит команду, наладит соответствие стандартам и т.д.) и как будете понимать, что он справляется.

А измерять успех этого направления действительно нужно! Используйте метрики, о которых мы говорили. Отслеживайте, сколько брешей закрывается до того, как они стали проблемой, как команды принимают культуру безопасности, и как всё это сказывается на бизнес-показателях – меньше авралов, легче аудиты, выше доверие клиентов. Показывая результаты в осязаемых величинах – графиках, процентах, экономии времени и денег – вы не только оправдываете выделенный на безопасность бюджет, но и помогаете всей компании понять ценность этой работы. А поняв – поддерживать ее ещё больше.

В сфере, где новости о кибератаках появляются чуть ли не каждую неделю, сильная AppSec/DevSecOps-программа позволяет вашей компании играть на упреждение. В идеале, конечно, хочется, чтобы никаких взломов не происходило – и грамотная работа команды безопасной разработки как раз к этому ведёт. Как говорится, безопасность должна быть встроена, а не привинчена сбоку – и ваш AppSec-специалист как раз тот самый мастер, который это реализует.

Дайте ему чёткие ориентиры (JD и KPI), обеспечьте поддержкой – и он выстроит для вашего кода надёжный невидимый щит. А с этим щитом и бизнесу будет спокойнее, и пользователям приятнее. Ваш продукт будет ассоциироваться не с утечками и патчами в пожарном порядке, а с надёжностью и доверием – а это, согласитесь, дорогого стоит.