Привет, Хабр! Меня зовут Рома Корчагин, я занимаюсь внедрением процессов безопасной разработки в продукте «Штурвал» от «Лаборатории Числитель». Наша платформа позволяет создавать сотни кластеров и управлять ими силами небольшой команды.
Считается, что практики DevOps действительно ускоряют разработку, но классические методы безопасности за этим прогрессом не успевают. В этой статье я расскажу, можно ли автоматизировать внедрение Sec в DevOps и при этом снизить нагрузку на разработчиков. Разберём четыре основных подхода — и отдельно поговорим про Shift-Down Security, который, на мой взгляд, отлично закрывает недочёты остальных.
Традиционный подход к безопасности
В традиционном подходе проверку безопасности проводят на завершающем этапе разработки (на схеме это предпоследний шаг).
Вся защита здесь нацелена на отражение внешних угроз, а доступы внутри сети строго контролируются. Основной упор — на периметр: доступ к продукту ограничивается с помощью дополнительных средств безопасности.
Как это выглядит в реальном мире: например, в компании X, занимающейся разработкой ПО, используют именно такой подход — все проверки проходят только после завершения функционального тестирования. После того как разработчики добавили новый функционал, QA-инженеры проверяют его: оценивают корректность работы функций, тестируют совместимость с разными ОС и устройствами, следят за стабильностью системы под нагрузкой. Если всё прошло успешно, команда ИБ подключается к процессу: сканирует систему на уязвимости, проводит пентест, анализирует логи и проверяет настройки прав доступа.
Плюсы:
Легко внедрить.
Все практики давно известны (не нужно изобретать велосипед).
А вот дальше начинаются минусы:
Исправлять уязвимости на поздних этапах влетает в копеечку.
Релизы задерживаются, потому что в последний момент приходится допиливать безопасность.
Интересы команды безопасности и команды разработки конфликтуют — каждый тянет одеяло на себя.
Копится технический долг.
Из-за недостатка контроля растут операционные риски.
Автоматизации нет — всё тестируется вручную.
Комплаенс сводится к бюрократии и перекладыванию бумажек.
Разработчики остаются в стороне от процесса безопасности — в итоге уязвимостей находят меньше, чем могли бы.
Ниже наглядно показано, во сколько раз возрастает цена исправления ошибок на более поздних этапах. Например, исправить баг на этапе тестирования примерно в 10 раз дороже, чем на этапе разработки, а на этапе эксплуатации — аж в 640 раз!
Вывод напрашивается сам собой: традиционный последовательный подход к безопасности сегодня неэффективен — ему не хватает гибкости и стоит он слишком дорого. Неудивительно, что появился новый подход — Shift-Left Security.
Shift-Left Security
В этом подходе безопасность «сдвигается влево» по хронологии, ближе к процессу разработки. Проверка кода на уязвимости происходит на каждом этапе, а инструменты интегрируются прямо в существующие DevOps-процессы команды разработки.
Инструменты безопасности становятся частью пайплайна разработки, благодаря чему проверки выполняются автоматически на каждом шаге. Регулярные сканы означают, что уязвимости мониторятся непрерывно. Кроме того, разработчиков обучают принципам безопасного кодирования. В итоге ответственность за безопасность становится коллективной, а разрыв между отделами ИБ и разработки постепенно сокращается.
Реализовать подход Shift-Left Security помогают такие средства, как:
Статический анализ кода (SAST).
Динамический анализ (DAST).
Инструменты анализа контейнеров.
Системы обнаружения секретов.
Инструменты анализа инфраструктуры как кода и так далее.
Список при желании можно расширить — всё зависит от потребностей компании и степени «паранойи» её ИБ-шников.
Плюсы:
Дешевле исправлять уязвимости, так как их обнаруживают быстрее.
Релизы выходят быстрее.
Повышается качество кода.
Улучшается взаимодействие между командами.
Снижается риск успешных атак.
Без минусов не обошлось:
Разработчики могут сопротивляться новым обязанностям по безопасности — их можно понять.
Придется переучивать персонал и адаптировать процессы.
Не так-то просто подобрать инструменты под технологический стек команды.
Чем больше инструментов безопасности внедряем, тем сильнее просаживается скорость разработки.
Сложно масштабировать: в каждой новой команде всё приходится начинать с нуля.
Shift-Right Security
Этот подход, наоборот, смещает акцент безопасности вправо — цикл проверки начинается уже после релиза.
Главные принципы Shift-Right Security:
мониторинг продуктивной среды в реальном времени;
наблюдаемость на основе метрик и логов (никаких догадок вслепую);
реагирование на инциденты по принципу «здесь и сейчас»;
непрерывное улучшение безопасности на основе данных эксплуатации.
Применяются:
Канареечные релизы для проверки новых функций.
A/B-тестирование (одновременное сравнение двух версий продукта).
Тестирование разных версий приложения.
Хаос-инжиниринг для проверки устойчивости системы.
Нагрузочное тестирование в реальных условиях.
Мониторинг пользовательского опыта.
Полезные метрики для такого подхода: время обнаружения инцидентов, скорость реагирования на угрозы, количество предотвращённых атак и эффективность мониторинга.
Плюсы:
Безопасность проверяется в боевых условиях (на реальных пользователях и данных).
Проблемы эксплуатации выявляются быстро.
Растёт отказоустойчивость систем.
Безопасность непрерывно улучшается на основе опыта пользователей.
Минусы:
Shift-Right сам по себе не работает: без анализа до релиза не обойтись.
Канареечные релизы и A/B-тестирование создают дополнительную нагрузку на прод.
А что, если применить оба подхода вместе?
Например, компания Y (разработчик ПО) внедрила у себя комплексный подход, совмещающий идеи Shift-Left и Shift-Right. Это позволяет выявлять и устранять проблемы на всех этапах жизненного цикла продукта.
На этапе разработки (Shift-Left) команда выполняет следующее:
Проводит статический анализ кода (SAST), чтобы выловить уязвимости ещё до компиляции.
Добавляет автоматические тесты безопасности в CI/CD-пайплайн.
Проверяет зависимости и сторонние библиотеки на известные уязвимости (SCA).
Устраивает регулярные code review с упором на безопасность.
Обучает разработчиков основам безопасной разработки.
А после релиза (Shift-Right) команда:
Собирает и анализирует логи эксплуатации для выявления аномалий.
Отслеживает метрики производительности и стабильности в продуктивной среде.
Проводит динамическое тестирование безопасности (DAST) на работающих системах.
Непрерывно собирает обратную связь от пользователей о возможных проблемах.
Оперативно выпускает патчи для устранения обнаруженных уязвимостей.
Теперь перейдём к самой интересной, на мой взгляд, концепции.
Shift-Down Security
Этот подход объединяет в себе все плюсы предыдущих.
Ключевые принципы Shift-Down Security:
Использование уже имеющихся технологий и сервисов. Мы стараемся повторно использовать то, что у нас уже есть и с чем мы набили руку.
Централизованное управление всеми правилами и практиками безопасности для всех команд разработки.
Использование абстракций и управляемых сервисов. Разработчикам больше не нужно разбираться в тонкостях отчётов разных сканеров со своей структурой и визуализацией. Теперь они получают унифицированную задачу — только с той информацией, которая им действительно нужна.
Автоматизация всего процесса: сканирование, интеграция с платформой, получение результатов, заведение задач для разработчиков в таск-трекерах и прочее.
В этой концепции все процессы безопасности выносятся на отдельную платформу и выполняются параллельно самой разработке. Конечно, возможны краткие паузы и тревожные звоночки, но в целом процесс разработки не останавливается во время сканирования. Всё это — благодаря глубокой интеграции процессов.
Как это выглядит на практике: в компании W ключевые виды анализа — статический (SAST), динамический (DAST) и композиционный (SCA) — вынесены в единую интегрированную среду. Эта платформа предлагает командам разработки готовые инструменты безопасности со следующими свойствами:
Легко встраиваются в существующие CI/CD-пайплайны.
Не требуют от разработчиков глубоких знаний в области ИБ.
Обеспечивают единый подход к поиску уязвимостей на всех этапах разработки.
Весь функционал анализа при этом выполняется командой инженеров по безопасности:
Инженеры SAST настраивают правила статического анализа и ловят уязвимости уже на этапе написания кода.
Специалисты DAST проводят динамические тесты на работающих приложениях, моделируют атаки и проверяют устойчивость системы в рабочем режиме.
Эксперты SCA проверяют зависимости и сторонние компоненты, отслеживают известные уязвимости в используемых библиотеках и фреймворках.
Таким образом, платформа выступает «единым окном» для всех проверок безопасности. Разработчики получают прозрачные и понятные отчёты о найденных уязвимостях — и им не нужно вникать в технические детали анализов.
Плюсы:
Разработчики могут сосредоточиться на функционале продукта.
Политики безопасности едины для всех команд.
Масштабирование упрощается: можно расширять охват и функциональность платформы безопасности, не затрагивая конечных пользователей и разработчиков.
Новые команды подключаются к платформе очень быстро.
Появляются новые вызовы и возможности.
Минусы:
Создание такой платформы — процесс сложный и длительный.
Приходится учитывать разные кейсы команд, создавать под них шаблоны и поддерживать их.
Инженерам по безопасности приходится интегрировать множество сервисов для разных команд разработки и централизовать всё на платформе.
Новые вызовы нравятся не всем 🙂
Что в итоге
Для наглядности я свёл плюсы и минусы всех рассмотренных подходов в одну таблицу (см. ниже). Из этой таблицы хорошо видно, почему, на мой взгляд, наиболее оптимальным является подход Shift-Down Security.
Из нашего опыта внедрение решения уровня ASOC/ASPM позволило разработчикам наконец-то работать с конкретными задачами, а не с бесконечными отчётами сканеров. Ложноположительные срабатывания теперь отмечаются не в интерфейсе сканеров, а централизованно на платформе. И хотя это только начало нашего пути к построению собственной Shift-Down-платформы, уже сейчас есть ощутимые результаты.
Напоследок — несколько полезных ссылок для тех, кто хочет изучить тему подробнее:
