Три квартала я выстраивал систему AppSec-метрик в компании с 40 микросервисами и двумя SAST-сканерами в пайплайне GitLab CI. Первый отчёт для CISO показал MTTR critical-уязвимостей в 14 дней - красиво, пока не выяснилось, что формула не учитывала reopened-тикеты и severity-reclassification. Реальный MTTR оказался 38 дней. Почти втрое. Этот разрыв между «метриками для презентации» и «метриками для реальности» - я встречаю в каждой второй AppSec-программе. Ниже - какие метрики DevSecOps действительно меняют поведение команд, как их считать без самообмана и почему программа Security Champions умирает без измерений.
Почему DORA-метрики недостаточны для оценки безопасности
DORA (DevOps Research and Assessment) определила четыре метрики производительности поставки ПО - фактический стандарт индустрии. По данным dora.dev:Throughput (пропускная способность):
- Change Lead Time - время от коммита до продакшена
- Deployment Frequency - частота деплоев
- Change Failure Rate - доля деплоев, потребовавших немедленного вмешательства
- Failed Deployment Recovery Time - время восстановления после неудачного деплоя
Исследование DORA показало, что скорость и стабильность - не компромисс: лучшие команды лидируют по всем показателям одновременно. Но безопасность в этой модели - слепое пятно.
Исследователи CMU Software Engineering Institute сформулировали проблему прямо: стандартные DORA-метрики основаны на опросах, а не на прямых измерениях; они фиксируют результаты разработки и операций, но не процессы; и они не покрывают безопасность и технический долг. Фокус только на темпе и стабильности, как отмечает CMU SEI, ведёт к накоплению технического долга и дырам в безопасности.
Команда может деплоить десять раз в день с нулевым Change Fail Rate - и при этом катить в каждом релизе непатченные зависимости с critical-уязвимостями. DORA этого не увидит. В ежегодном отчёте DORA за 2022 год появилось признание: безопасность необходимо интегрировать на каждом этапе жизненного цикла разработки. Около 63% респондентов сообщили о встроенных проверках ИБ в CI/CD. Но наличие сканирования не равно эффективности - для оценки зрелости программы безопасности нужен отдельный набор AppSec-метрик.
AppSec-метрики, которые меняют поведение команд
Главная ошибка отчётов по безопасности - показывать «количество найденных уязвимостей». Это vanity-метрика: растёт при добавлении нового сканера, падает при его отключении, никак не коррелирует с реальным уровнем защищённости и не тянет на KPI информационной безопасности. Ниже - набор метрик, которые при правильном расчёте реально меняют поведение разработчиков и security-инженеров.MTTR уязвимостей по severity-уровням
MTTR (Mean Time to Remediate) уязвимостей - ключевая метрика DevSecOps: среднее время от обнаружения уязвимости до её устранения. Агрегированный MTTR по всем severity - бесполезная цифра. Critical, закрытая за 3 дня, и informational, висящая 90 дней, в среднем дают 46.5 дней. И что с этим числом делать? Ничего.Считать нужно раздельно:
| Severity | Целевой MTTR | Триггер эскалации |
|---|---|---|
| Critical | 72 часа (3 дня) | > 5 дней → engineering manager |
| High | 14 дней | > 21 день → security lead |
| Medium | 30 дней | > 45 дней → квартальный отчёт |
| Low | 90 дней | Без эскалации, мониторинг тренда |
Формула:
MTTR(severity) = SUM(дата_закрытия - дата_обнаружения) / COUNT(закрытых_уязвимостей) - для каждого severity отдельно.Подводные камни, на которых горят:
- Reopened-тикеты. Уязвимость закрыта, потом переоткрыта. Считать ли время заново? Да - иначе MTTR будет занижен. Каждый цикл «открытие→закрытие» учитывается как отдельный finding.
- Severity reclassification. Critical понижен до Medium через неделю, закрыт через месяц - в каком severity считать? В исходном. Иначе команды будут «лечить» метрику понижением severity вместо устранения проблемы. Я видел это не раз.
- False positives. Исключать из расчёта MTTR, но отдельно считать False Positive Rate как метрику качества тулинга. FPR выше 30% - сигнал, что сканер настроен криво и разработчики перестали доверять его результатам.
Vulnerability Escape Rate и Security Debt
Vulnerability Escape Rate - доля уязвимостей, прошедших все Quality Gates в пайплайне, но обнаруженных в продакшене (через баг-баунти, пентест, инцидент):Escape Rate = (уязвимости_найденные_в_проде / общее_число_обнаруженных) * 100%Целевое значение - ниже 5%. Рост escape rate - сигнал: Quality Gates настроены неправильно или покрытие сканерами недостаточно. Отдельно стоит отслеживать escape rate для уязвимостей в зависимостях (SCA-слой), потому что атаки через Compromise Software Dependencies (T1195.001, Initial Access) и Supply Chain Compromise (T1195.002) бьют именно в этот слепой угол.
Security Debt - количество открытых уязвимостей, превысивших целевой SLA по MTTR для своего severity. 200 открытых High старше 14 дней - это security debt. Показывать в абсолютных числах и в динамике за квартал: растёт - проблема масштабирования, падает - программа работает.
Частота сканирования vs частота деплоя
Отношение Security Scan Frequency к Deployment Frequency - метрика, которую описала команда Swordfish Security в проекции DORA на DevSecOps. При зрелом DevSecOps это отношение должно быть больше 1: сканирования запускаются чаще деплоев, потому что проверки встроены на ранних стадиях (SAST при каждом merge request, SCA при каждом обновлении lock-файла).Если отношение меньше 1 - сканирования не прикручены к CI/CD и запускаются вручную или по расписанию. Прямой индикатор незрелости shift-left подхода к безопасности.
Отдельно стоит отслеживать Passed Security Gates Ratio - долю сканирований, прошедших Quality Gates. Высокий показатель может означать как зрелость процесса, так и заниженные пороги. Низкий - что разработчики не думают о безопасности или пороги нереалистичны. Тут нет «правильного» числа - нужен контекст команды и тренд.
Для защиты самого пайплайна необходимо мониторить аномалии в CI/CD-конфигурации: несанкционированные изменения в
.gitlab-ci.yml или Jenkinsfile могут указывать на Poisoned Pipeline Execution (CICD-SEC-04 в OWASP Top 10 CI/CD Security Risks) - атаку через внедрение вредоносного кода в конфигурацию пайплайна.Как считать MTTR уязвимостей без самообмана
Самый частый вопрос от команд, начинающих измерение эффективности AppSec: «где взять данные?». Если используете Defect Dojo как агрегатор находок, данные доступны через REST API.
Bash:
curl -s -H "Authorization: Token YOUR_API_TOKEN" \
"https://defectdojo.company.com/api/v2/findings/\
?severity=Critical&is_mitigated=true&date__gte=2025-01-01" \
| jq '[.results[] | {id, severity, date, mitigated,
days: ((.mitigated | fromdateiso8601) -
(.date + "T00:00:00Z" | fromdateiso8601)) / 86400}]'days для каждого finding и считаете среднее - это MTTR Critical за период. Для автоматизации - custom Prometheus exporter, который раз в час опрашивает API и пишет gauge-метрику appsec_mttr_days{severity="critical"}.Критически важно определить, что считать моментом обнаружения:
- Дата запуска сканера? Дата создания тикета в Jira? Дата подтверждения (не false positive)?
mitigated с пройденным ресканом. Между ними - MTTR. Без рескана нет закрытия - иначе команды будут отмечать тикеты «resolved» без реального фикса. Проверено на горьком опыте.Для связки Prometheus + Grafana базовый scrape-конфиг:
YAML:
scrape_configs:
- job_name: 'defectdojo-exporter'
scrape_interval: 3600s
static_configs:
- targets: ['dd-exporter:9090']
metric_relabel_configs:
- source_labels: [severity]
regex: '(Critical|High)'
action: keepЗрелость программы безопасности: [URL="https://codeby.net/threads/devsecops-na-praktike-kak-vnedrit-bezopasnost-v-razrabotku-i-sokhranit-skorost-vypuska.86439/"]OWASP SAMM и BSIMM[/URL]
Метрики уязвимостей показывают текущее состояние. Но как оценить DevSecOps-зрелость программы в целом - процессы, культуру, покрытие? Для этого есть фреймворки оценки зрелости.OWASP SAMM (Software Assurance Maturity Model) - открытая модель, оценивающая 15 практик безопасности по 5 бизнес-функциям: Governance, Design, Implementation, Verification, Operations. Каждая практика оценивается от 0 до 3 по уровню зрелости. Самооценку можно провести за 2-3 дня командой из security lead, архитектора и тимлида.
BSIMM (Building Security In Maturity Model) работает иначе: вместо предписаний описывает, что делают реальные компании. BSIMM полезен для бенчмаркинга - вы видите, какие активности практикуют организации вашего сектора и размера.
Разница принципиальная: OWASP SAMM говорит «вот зрелость уровня 2, достигните уровня 3», а BSIMM показывает «компании вашего сектора делают X, вы не делаете - это gap». Для внутреннего использования я рекомендую OWASP SAMM раз в полгода с отслеживанием прогресса по каждой из 15 практик. CISO получает объективную картину, а не набор разрозненных KPI.
С позиции NIST CSF 2.0 оценка зрелости связана с функцией GOVERN (GV.OC-01): организационная миссия должна информировать управление рисками кибербезопасности. Если AppSec-метрики не привязаны к бизнес-целям компании - они существуют в вакууме и не влияют на решения.
Построение Security Champions - программа, которая умирает без метрик
Программа Security Champions - один из самых действенных механизмов масштабирования AppSec. Идея простая: в каждой команде разработки есть выделенный инженер, прошедший дополнительное обучение по безопасности, участвующий в security-ревью и работающий точкой контакта для security-команды. Реализация сильно сложнее идеи - без метрик вовлечённости программа, по моему опыту, деградирует за 3-4 месяца.Метрики вовлечённости Security Champions
| Метрика | Целевое значение | Источник данных |
|---|---|---|
| Champion-to-Developer Ratio | 1:8 - 1:10 | HR-данные + реестр Champions |
| Training Completion Rate | Выше 70% за квартал | LMS / внутренняя платформа |
| Security Review Participation | Выше 50% security-MR | GitLab/GitHub labels |
| Findings by Champions | Выше 0 за месяц | Defect Dojo, source=manual |
Champion-to-Developer Ratio ниже 1:15 - покрытие недостаточное, Champions перегружены и выгорают. Training Completion Rate ниже 70% - тимлиды не выделяют обещанные 10% времени на security-активности. Security Review Participation на нуле - Champion числится в программе, но не участвует в ревью. Программа фиктивная.
Findings by Champions - количество уязвимостей, найденных Champions при ручном ревью, не сканером. Показывает добавленную ценность программы поверх автоматизации: если Champions не находят ничего сверх того, что ловит Semgrep - значит, обучение не работает или Champions сфокусированы не на тех рисках.
Когда программа Security Champions не работает
Три признака, что программа умирает:- Training Completion Rate падает два квартала подряд - тимлиды забрали время Champions на фичи. Действие: эскалация на VP Engineering с данными о корреляции обучения и MTTR.
- Ratio растёт при найме, Security Review Participation стоит - новые Champions не включаются в работу. Действие: пересмотр онбординга, парное ревью с опытным Champion.
- MTTR не коррелирует с количеством Champions - программа не влияет на скорость устранения уязвимостей. Действие: аудит того, что именно Champions делают vs что от них ожидается.
Дашборд для CISO и дашборд для команды - разные инструменты
Данные для дашбордов агрегируются через связку Defect Dojo (уязвимости) + Dependency-Track (зависимости) + GitLab CI (pipeline metrics) → Prometheus → Grafana. Prometheus собирает метрики через custom exporters, которые опрашивают API этих систем по расписанию.
За два года работы с AppSec-метриками я пришёл к неудобному выводу: большинство метрических программ в DevSecOps существуют для успокоения руководства, а не для изменения поведения команд. MTTR считают агрегированно, Security Debt не считают вообще, а программу Security Champions запускают без единого KPI, потому что «мы за культуру безопасности разработки, а не за цифры». Через год такая программа живёт только в презентации квартального отчёта.
Метрика работает, когда она привязана к конкретному действию: MTTR Critical выше 72 часов → эскалация на engineering manager. Escape Rate выше 5% → аудит Quality Gates. Training Completion ниже 70% → разговор с VP Engineering о бюджете времени. Без связки «метрика → триггер → действие» любой дашборд в Grafana - красивая картинка для стены.
И ещё момент, который часто вызывает споры: OWASP SAMM-оценка должна проводиться не security-командой в изоляции, а совместно с разработчиками и продуктовыми менеджерами. Когда security-инженер выставляет самооценку зрелости «2 из 3» по практике Secure Architecture, а архитектор считает, что «1 из 3» - вот это и есть настоящий разговор о зрелости. Без него метрики остаются самоотчётом безопасников, а не инструментом реального изменения.
