Найти в Дзене
CISOCLUB

Какие KPI нужны DevSecOps команде

Изображение: recraft По статистике, 66% российских компаний уже используют в разработке конвейер CI/CD (непрерывную интеграцию и развертывание), но только 38% интегрировали в него практики безопасной разработки — DevSecOps. Один из барьеров — неясные KPI для команд ИТ и ИБ, участвующих в работе над продуктом. Руководитель департамента развития и архитектуры «Кросс технолоджис» Евгений Балк предлагает топ-метрик, которые позволят службам информационной безопасности корректно оценить свое влияние на разработку. 1. Процент ложных срабатываний инструментов анализа (в первую очередь, SAST) — говорит о том, насколько хорошо выбирает и настраивает инструменты для конкретного стека команда AppSec. Каждая ложная сработка тормозит разработку продукта, поэтому мы стремимся минимизировать этот показатель. 2. Процент автоматизированных тестов безопасности в конвейере — проведение ручных проверок может привести к задержке вывода новой версии продукта на рынок, поэтому ИБ необходимо стремиться к тому

Изображение: recraft

По статистике, 66% российских компаний уже используют в разработке конвейер CI/CD (непрерывную интеграцию и развертывание), но только 38% интегрировали в него практики безопасной разработки — DevSecOps. Один из барьеров — неясные KPI для команд ИТ и ИБ, участвующих в работе над продуктом.

Руководитель департамента развития и архитектуры «Кросс технолоджис» Евгений Балк предлагает топ-метрик, которые позволят службам информационной безопасности корректно оценить свое влияние на разработку.

1. Процент ложных срабатываний инструментов анализа (в первую очередь, SAST) — говорит о том, насколько хорошо выбирает и настраивает инструменты для конкретного стека команда AppSec. Каждая ложная сработка тормозит разработку продукта, поэтому мы стремимся минимизировать этот показатель.

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

3. Средняя продолжительность проведения анализа — после пункта 2 нельзя не сказать о том, что продолжительность анализа и передачи выявленных дефектов в команду разработки должны быть минимальными.

4. Количество инцидентов ИБ, связанных с дефектами кода, которые не выявили специалисты по кибербезопасности — в идеале их должно быть 0. Хорошая практика, когда специалисты по безопасности не только указывают командам разработки на выявленные проблемы, но и помогают найти для них решение или компенсирующие меры.

5. Количество дефектов, выявленных на этапе продакшена — должно быть минимальным, поскольку на этапе запуска исправление в 100 раз «дороже» в плане затрат ресурсов команды, чем на этапе разработки.

6. Соответствие требованиям — важный момент, когда необходимо по требованиям регулятора обеспечить соответствие процессов определенным стандартам (например, ГОСТ Р 56939-2024).

«При этом важно, чтобы у ИТ и ИБ помимо личных были общие KPI, поскольку DevSecOps — единый сквозной процесс команд разработки, поддержки инфраструктуры, информационной безопасности и смежных с ними подразделений», — отмечает Евгений Балк.

Оригинал публикации на сайте CISOCLUB: "Как оценить эффективность ИБ в DevSecOps?".

Смотреть публикации по категориям: Новости | Мероприятия | Статьи | Обзоры | Отчеты | Интервью | Видео | Обучение | Вакансии | Утечки | Уязвимости | Сравнения | Дайджесты | Прочее.

Подписывайтесь на нас: VK | Rutube | Telegram | Дзен | YouTube.