DevSecOps на практике: метрики, автоматизация и новые вызовы безопасности
Изображение: recraft
Интеграция безопасности в процессы разработки больше не тренд, а необходимость. Но переход от DevOps к DevSecOps редко проходит безболезненно. Компании сталкиваются с культурными барьерами, перегруженностью инструментов и отсутствием прозрачных метрик. Чтобы безопасность действительно «встроилась» в пайплайны, а не превратилась в формальность, нужно выстраивать системный подход — от архитектуры и автоматизации до культуры взаимодействия команд.
Редакция CISOCLUB пообщалась с Александром Гадаем, руководителем службы консалтинга Swordfish Security, о том, какие ошибки чаще всего совершают компании при внедрении DevSecOps, как выстроить метрики эффективности, какие задачи можно безопасно автоматизировать, как управлять безопасностью сторонних компонентов и почему следующий шаг после DevSecOps — это MLSecOps и защита ИИ-моделей.
Какие основные ошибки допускают компании при переходе от DevOps к DevSecOps на практике?
Часто видим ситуацию, что компании пытаются закрыть все практики безопасной разработки сразу, а не постепенно. Также при переходе часто забывают договориться о процессе взаимодействия с командой разработки: проверку уязвимостей и их исправление ставят директивной задачей, что приводит к тому, что разработчики ищут креативные способы избежать проверок и вообще не хотят сталкиваться с ИБ.
Как убедиться, что безопасность по-настоящему «вшита» в пайплайны CI/CD, а не остаётся допиливанием после?
Для этого следует выстроить систему сбора метрик DevSecOps. Важно отслеживать процент покрытия кодовых баз в разрезе практик DevSecOps, динамику изменения числа уязвимостей и инцидентов, связанных с ошибками в коде приложения.
Как выстраивать корреляцию данных об уязвимостях из разных инструментов (SAST, DAST и др.) в единую систему при DevSecOps?
Для этого есть отдельный класс инструментов ASPM (Application Security Posture Management). Решения данного класса позволяют собирать находки сканнеров в единый интерфейс для дальнейшего разбора аналитиком. Эти решения в том числе позволяют собирать метрики по уязвимостям и скорости их устранения, а также автоматизировать процесс разбора уязвимостей в целом за счёт правил обработки и моделей искусственного интеллекта.
Насколько реально для команд разработки самостоятельно устранять дефекты безопасности без участия ИБ-экспертов?
Зачастую для разработчика обнаруженные анализатором проблемы не являются очевидными и требуют глубокое погружение в суть уязвимости. Сейчас в Интернете есть множество статей с детальным объяснением деталей уязвимостей, однако они не могут дать прямого ответа о том, как исправить код в конкретной ситуации. То есть разработчику приходится тратить время на обучение, но этого времени у него часто нет. В случае, когда в компании нет эксперта ИБ, разработчик может просто спросить у ИИ чат-бота о том, как исправить уязвимость в коде. Такой способ может сэкономить время, но может привести к негативным последствиям, таким как утечка исходного кода, нарушение работы приложения или его непредвиденная работа.
Какие метрики DevSecOps вы считаете наиболее важными для оценки эффективности практик безопасности в ПО?
В первую очередь это STD (Security Tech Debt — техдолг по безопасности). Метрика отображает общее количество не устранённых уязвимостей. При первичном внедрении DevSecOps на неё следует ориентироваться для понимания динамики и принятия решений. Например, если техдолг лишь растёт, это повод задуматься о проведении обучения разработчиков основам безопасной разработки.
Также следует отслеживать Mean Vulnerability Age (MVA) — средний возраст уязвимости. Чем лучше команда разработки понимает уязвимости, тем быстрее у неё получается их исправлять, иногда даже не прибегая к совету эксперта по ИБ.
Не менее важным в процессе DevSecOps является отслеживание процента ложных срабатываний инструментов (False Positive Rate) – если разработчику или эксперту приходится тратить много времени на анализ ложных срабатываний, его время расходуется неэффективно и следует задуматься о замене инструмента.
Какой уровень автоматизации может быть безопасным и устойчивым, а где нужен человеческий контроль?
В части DevSecOps есть несколько примеров, где уже сейчас автоматизация позволяет получить преимущество, это контроль прохождения порогов безопасности (quality gates) в пайплайнах сборки и доставки ПО, контроль исполнения политик в файлах конфигурации (IaC — Infrastructure as Code). Эти контроли довольно простые и дают чёткое понимание разработчикам о том, что нужно исправить, чтобы приложение стало защищенным.
Также большое внимание сейчас уделяется ИИ-помощникам в процессе анализа уязвимостей из инструментов. Я считаю, что этим помощникам пока нельзя доверять на 100% и они могут лишь помочь приоритизировать найденные уязвимости, но финальное решение должен принимать эксперт.
Как управлять безопасностью сторонних библиотек и компонентов (supply chain) в процессе DevSecOps?
Наибольшую долю угроз supply chain закрывают инструменты классов OSA и SCA. Данные инструменты взаимодействуют со внешним источником данных (фид), который актуализируется в режиме реального времени. Как только становится известно о наличии уязвимости в сторонней библиотеке — эта информация сразу появляется в фиде. При попытке загрузить такую библиотеку, инструмент подсвечивает риск уязвимости и может заблокировать её скачивание в контур организации за счёт интеграции с локальным репозиторием зависимых компонент.
Какие тенденции в DevSecOps вам кажутся наиболее критичными на ближайшие 2–3 года, и как к ним готовиться?
Основная тенденция сейчас это применение принципов DevSecOps в MLSecOps – безопасной разработке ИИ моделей. У этих процессов много сходств и компании пытаются разобраться в том, как обеспечить защиту продуктов, применяющих технологии искусственного интеллекта. От ИБ требуют понимания технологий, стоящих за искусственным интеллектом, чтобы уметь их защищать. В части подготовки я бы рекомендовал изучать архитектуры и технологии, стоящие за современными AI и ML моделями.
