Меня зовут Дмитрий Морев, я руководитель Информационной безопасности в RuStore.
В предыдущей статье мы рассказали о роли автоматизации и управления релизами в RuStore, в этой продолжу тему в части проверок безопасности в релизном цикле.
У информационной безопасности нет собственных целей — есть только один общий путь с бизнесом и ИТ (командой разработки), поэтому команда ИБ должна ориентироваться на бизнес-цели и производственные метрики ИТ.
Одной из таких бизнес-целей является быстрая и эффективная проверка продуктовых гипотез, запуск MVP (Minimum Viable Product) и выбор правильных гипотез для дальнейшего развития бизнеса. Для выполнения этих целей ИТ-разработка должна быть быстрой, гибкой и иметь низкий Change Failure Rate.
Инфобез должен быть еще быстрее, потому что необходимо успеть разобраться в логике работы фичи, проверить код, подсветить риски безопасности и желательно снизить их в рамках установленных производственных метрик и TTM (time to market).
Итак, чтобы поспевать за ритмом разработки необходима автоматизация, максимально быстрый подход к «снаряду» (смотрим производственные таски с момента создания), короткий TTS (time to security, общее время всех проверок ИБ) с привлечением QA-команд к тестам безопасности.
В данной статье расскажу про проверку и автоматизацию согласования релизов.
Наша команда ИТ использует быстрый и эффективный подход к разработке, в котором разработчики совместно работают над кодом в одной ветке, называемой «главной» (или master в терминологии Git) — Trunk based development.
Некоторые метрики производства:
- Deployment frequency > 1 раза в день.
- Median cycle time < 84 часов.
- Change Failure Rate < 5%
Релизы катятся по готовности (on demand), и в день их может быть до нескольких десятков.
Что делает инфобез, чтобы соответствовать высокой скорости разработки без потери качества проверок безопасности?
Процессы
В RuStore внедрен процесс согласования/автосогласования релизов командой информационной безопасности.
Проверка релизных задач
Security checks (SCR) — простой флоу, отличный от флоу родительских задач, которые оптимизированы под разработку.
Пример workflow
SCR-задачи (таски) заводятся автоматически (автоматизация в Jira) на все таски производственного цикла, кроме:
- тестов;
- дизайна;
- аналитики.
Таски отфильтровываются по меткам и тэгам в названии. SCR-таски берутся в работу в зависимости от приоритета, статуса и готовности родительской таски. В случае неготовности родительской таски или в случае выявления недочетов по ИБ, SCR кладется в бэклог в статусе «waiting» до момента готовности или устранения замечаний.
Таски закрепляются за ответственными в команде безопасности, и в рамках этих задач проводится проверка безопасности функционала (это может быть новый функционал, эндпоинт, архитектура, конфигурация и т. д.).
Этот подход позволяет не пропускать разработку функционала продукта и проверять ранее выдвинутые требования ИБ. Все задачи SCR прилинкованы к задачам продукта и соответственно к задаче релиза.
Архитектурное ревью
Все фичи проходят архитектурное ревью по итогам которого, командой разработки создается архитектурная запись — ADR (Architecture decision record) и коммитится в репозиторий проекта, одним из апруверов является архитектор ИБ, который проверяет правильность и актуальность требований ИБ к фиче. Далее при проверке SCR очень удобно переходить по ссылке в ADR для быстрой проверки фичи.
Проверка обработки дефектов кода релиз-кандидата
… с использованием нашей Appsec — платформы Security Gate (SG)
По процессу происходит блокировка релиза при отсутствии согласования ИБ.
До момента сбора релиза команда безопасности проводит аудит безопасности функциональности в рамках SCR-задач и проверяет все срабатывания в Security Gate совместно с командами разработки.
Автосогласование релиза
Обработка SCR и сработок в SG
В релизном цикле реализован сервис, который проверяет наличие необработанных дефектов в SG (дефекты безопасности в коде) и открытых тикетов SCR в момент отрезки релизной ветки и перевода продуктовых задач в статусы
regress и ready for deploy.Код написан на Python и часть автоматизации на Jira Query Language. Проверяются SCR c меткой релиза кандидата и сработки в SG. Если все условия выполнены, релиз согласуется автоматически.
Это мотивирует команды вовремя разбирать срабатывания SG, иначе релиз не будет согласован в нужные сроки, и нарушатся производственные метрики.
Проверка условий автосогласования в SG
Для проверки статусов дефектов безопасности в коде релиз-кандидата используется API SG с передачей commit hash в параметре:
commit_sha = git_ops.api_get_commit_id(project_id=project_id,project_path=project_path)Статус срабатывания должен быть отличным от «не обработано». Анализируются срабатывания с критичностью High и Critical.
В случае возникновения ошибок при обращении к API SG сервис осуществляет контроль доступности SG и информирование об отсутствии проекта в SG. При возникновении проблем с доступом к SG или отсутствии проекта в системе, соответствующее сообщение выводится в чат релизов.
Таким образом, данный подход обеспечивает контроль за тем, что все prod-репозитории интегрированы в SG, поскольку любые несоответствия будут немедленно отражаться в канале релизов VK Teams (корпоративный мессенджер) посредством оповещений о незакрытых срабатываниях и SCR-задачах.
Метрика Time to security: как измерять эффективность команды ИБ
В нашем процессе мы приняли количество автосогласований релизов командой ИБ метрикой эффективности TTS.
Доля автоматизированных согласований релизов должна стремиться к 100%, что, в совокупности с метрикой на отсутствие инцидентов, служит показателем эффективности работы команды информационной безопасности.
Согласование релиза вручную означает, что команда ИБ не успела в установленные производством сроки проверить сработки SG и/или обработать SCR, что потенциально влияет на Cycle time и TTM.
Заключение
В итоге, благодаря внедрению автоматизации согласования релизов, нам удалось значительно упростить и упорядочить проверки на каждом этапе релизного цикла.
Это позволило оптимизировать TTS в релизном цикле без нарушения производственных метрик и TTM, сохраняя при этом высокое качество проверок.
О дальнейшем расширении автоматизации и привлечении команд QA к тестам безопасности расскажем в следующих статьях.
