Этапы DevSecOps-пайплайна test‑time и post‑deploy и инструменты визуализации данных

В первой части серии статей о DevSecOps мы рассказали о концепции Shift‑left и о структуре DevSecOps‑пайплайна. Основная идея: начинать проверки безопасности продукта нужно как можно раньше, ещё на этапе разработки. Мы упомянули также основные фазы проверки безопасности.

Во второй части мы подробно рассмотрели фазы pre‑commit (проверка безопасности до того, как разработчик закоммитит код в систему контроля версий), pre‑build (проверка безопасности после того, как код попал в систему контроля версий) и post‑build (проверка безопасности артефакта, собранного из исходного кода, например Docker‑файла, RPM‑пакета или JAR‑архива). Речь шла также об инструментах, которые можно использовать на каждом этапе проверок.

В третьей, заключительной, части речь пойдёт об этапах проверок test‑time, post‑deploy и об инструментах визуализации данных.

Материал будет полезен руководителям и сотрудникам отделов информационной безопасности, разработки и DevOps‑команд.

Проверка безопасности на этапе test‑timeПроверка безопасности на этапе test‑time

На этом этапе выполняются динамические проверки методом «серого ящика» (Gray Box Testing) и «чёрного ящика» (Black Box Testing) — когда внутреннее устройство приложения частично или полностью неизвестно. Такие проверки безопасности выполняются с помощью эмуляции действий злоумышленника, который находит уязвимости и пробует сломать приложение, используя их.

Есть три вида проверок test‑time: DAST, IAST и OAST. Рассмотрим каждый из них отдельно.

Проверка DASTПроверка DAST

DAST (Dynamic Application Security Testing) — это динамическое тестирование безопасности приложений. DAST‑сканеры работают автоматически и проверяют приложения, имитируя внешние атаки через различные уязвимости. Получается, что приложение — чёрный ящик для анализатора, о нём ничего не известно.

Для DAST‑проверок необходимо иметь доступный для сканера запущенный экземпляр приложения. Причём чем ближе параметры тестового экземпляра приложения к production‑инсталляции, тем меньше будет ложных срабатываний. Например, если вы развернули тестовый экземпляр приложения, доступный только по протоколу http, а в production приложение доступно только по протоколу https, DAST‑сканер выдаст ряд ошибок, связанных с отсутствием шифрования трафика между клиентом (анализатором) и сервером (экземпляром приложения).

IAST (Interactive Application Security Testing) — интерактивное тестирование безопасности приложений методом «серого ящика», соединяющее в себе достоинства и сильные стороны White Box Testing SAST и Black Box Testing DAST.

Чтобы собрать все плюсы и исключить минусы методов SAST и DAST, придумали IAST — гибридный механизм, объединивший эти методы. Он повышает точность динамического тестирования, потому что даёт больше информации о работе приложения благодаря анализу кода.

Стоит учитывать, что, помимо плюсов, IAST имеет ограничения. Самое основное — зависимость от языка, на котором написано тестируемое приложение: IAST‑решения работают на уровне приложения и требуют доступ к исполняемому коду, чтобы анализировать его поведение. Это означает, что IAST‑решения должны понимать язык программирования, на котором написано приложение. Необходимо отметить, что для одних языков поддержка конкретного IAST‑решения может быть реализована лучше, чем для других.

Также IAST‑анализ занимает продолжительное время. Он зависит от многих факторов — например, размера и сложности приложения, количества внешних зависимостей и производительности используемого IAST‑инструмента.

Кроме этого, в процессе анализа не сканируется сам код, а проверяются только те фрагменты, которые исполняются непосредственно в процессе работы. Поэтому IAST‑анализ лучше всего совместить с функциональным тестированием, когда можно проверить максимально возможное количество сценариев работы приложения.

Проверка OASTПроверка OAST

OAST (Out‑of‑band Application Security Testing) — разработанное компанией PortSwigger расширение DAST. Этот инструмент находит уязвимости, которые не видит DAST, например log4shell.

Проверка безопасности на этапе post‑deployПроверка безопасности на этапе post‑deploy

Это важный этап в обеспечении безопасности и работоспособности приложений. В отличие от проверок pre‑commit, которые выполняются на этапе разработки, проверки post‑deploy позволяют выявить возможные проблемы уже на этапе эксплуатации приложения, когда оно находится в реальной среде.

Мониторинг безопасности артефактовМониторинг безопасности артефактов

Чтобы вовремя обнаружить новые уязвимости, необходимо проводить регулярные проверки артефактов, в том числе после деплоя приложения. Это можно делать с помощью специальных хранилищ или инструментов, например Snyk Container, Trivy, GitLab Container Scanning, или с помощью собственного интеграционного модуля.

Мониторинг безопасности приложенияМониторинг безопасности приложения

Ещё один способ обеспечить безопасность — мониторинг самого приложения. Для этого существует несколько технологий.

Web Application Firewall (WAF) — межсетевой экран для веб‑приложений. Это инструмент для фильтрации трафика. Он работает на прикладном уровне и защищает веб‑приложения, анализируя трафик HTTP/HTTPS.

RASP (Runtime Application Self‑Protection) — технология, которая в реальном времени обнаруживает и блокирует атаки на приложение. Она добавляет функцию защиты в среду исполнения, что даёт приложению возможность самозащиты (self‑protection) в автоматическом режиме.

Главное преимущество технологии RASP перед другими средствами защиты веб‑приложений состоит в том, что она понимает, как работает приложение, и выявляет атаки и нелегитимный трафик. При этом RASP может обнаруживать не только типовые атаки, используя метод сравнения по сигнатуре, но и попытки эксплуатации уязвимостей zero‑day, реагируя на аномалии.

В отличие от WAF RASP работает внутри приложения и вместе с ним. WAF можно обмануть. Если злоумышленник изменит код приложения, WAF не сможет это определить, потому что не понимает контекст исполнения. А RASP имеет доступ к диагностической информации о работе приложения, может анализировать её, выявлять аномалии и блокировать атаки.

Технология RASP имеет особенность — фокус на предотвращении атак по умолчанию. Системе не требуется доступ к исходному коду.

Визуализация результатов работы DevSecOps‑пайплайна и управление уязвимостямиВизуализация результатов работы DevSecOps‑пайплайна и управление уязвимостями

На разных этапах пайплайна мы используем большое количество Application Security Testing/DevSecOps‑анализаторов. Каждый из них формирует отчёт в собственном формате, а некоторые генерируют среди найденных уязвимостей так называемые False Positives — ложные срабатывания. Из‑за этого анализировать безопасность приложения в целом достаточно сложно.

Чтобы эффективно анализировать уязвимости и управлять процессом их устранения, используют специализированные инструменты Vulnerability Management, которые зачастую называют просто Security Dashboards.

Security Dashboards решают проблему, передавая результаты работы DevSecOps‑анализаторов в унифицированном и удобном для анализа виде. Так инженеры по безопасности видят, какие существуют проблемы, какие из них наиболее критичны и какие необходимо устранить в первую очередь.

ЗаключениеЗаключение

В трёх частях материала про DevSecOps на практике мы рассмотрели концепцию Shift‑left, структуру DevSecOps‑пайплайна, все этапы проверок приложения — от pre‑commit до post‑deploy, а также кратко познакомились с инструментами, которые можно использовать на различных этапах проверок.