Привет!

Меня зовут Юрий Сергеев, я основатель и управляющий партнер в Swordfish Security.

С 2017 наша компания активно занимается проблематикой построения процессов разработки защищенного ПО (Secure Software Development Lifecycle). За прошедшие годы нам посчастливилось реализовывать поистине уникальные проекты в области DevSecOps, где мы приобретали для себя самое ценное - опыт. Накопленная экспертиза и сформированные компетенции дали нам возможность создать продукт - AppSec.Hub, который позволяет реализовать интеграцию практик информационной безопасности в непрерывный процесс разработки (DevOps) и построить настоящий DevSecOps.

Под катом я поделюсь своим взглядом на вызовы при построении DevSecOps, расскажу о той степени автоматизации, которой удалось достичь на основе анализа и трансформации процессов разработки защищенного ПО.

Статья получилась внушительная, так что мне пришлось разбить ее на две части. Обе будут опубликованы сегодня.

Часть первая:

Индустриальные вызовы DevSecOps
Цели и задачи инструментов класса ASOC
Оркестрация (Orchestration)
Корреляция (Correlation)

Индустриальные вызовы DevSecOps

Индустрия программного обеспечения эволюционировала от водопадных моделей к высокоскоростной разработке. Однако организации – разработчики ПО все еще сталкиваются с трудностями при интеграции инструментов анализа защищенности приложений в DevOps. Мы видим, как многие решают эту задачу созданием кастомных интеграций при помощи разрозненных, немодернизируемых, трудноподдерживаемых скриптов, что часто приводит к нескончаемым проектам с привлечением либо внутренних, либо внешних ресурсов.

С течением времени, переход в общий ландшафт DevSecOps только усложняется из-за ряда причин:

• Всеобщая цифровизация - организации разрабатывают все больше и больше программных продуктов и цифровых сервисов, чтобы максимально приблизиться к своему клиенту;

• Рост числа приложений и их компонент - в современных архитектурах приложения декомпозируются на отдельные модули и независимые микросервисы;

• Разработка ведется географически распределенными командами, а у цифровых продуктов появляется все больше стейкхолдеров - со стороны бизнеса, IT и ИБ;

• Требования бизнеса сократить Time-to-Market приводят к максимальному сжатию циклов разработки;

• Количество релизов в каждом продукте/сервисе непрерывно растет, что влечет за собой рост числа точек контроля ИБ (Quality Gates), которые в свою очередь накладываю дополнительные требования в зависимости от фазы жизненного цикла конкретного релиза для конкретного программного продукта;

• Скоординировать вручную или в полуавтоматическом режиме работу даже пары практик тестирования ИБ (напр. SAST и DAST) становится крайне сложно, не говоря уже о расширении количества этих практик и инструментов анализа защищенности;

• Инструменты ИБ обычно генерируют большое количество ложных срабатываний (False Positives), которые подлежат анализу и приоритизации, что в свою очередь требует вовлечения дорогостоящего человеческого ресурса со стороны
  команды ИБ;

• Рост объема технического долга дефектов ИБ;

• Крайне сложное управление процессом разработки в разрезе отдельно взятых ИБ инструментов, практик, продуктовых команд и релизов из-за отсутствия общего подхода и механизмов сбора метрик.

Таким образом, всем разработчикам ПО, к которым предъявляются требования как по информационной безопасности для их продуктов, так и по соблюдению условий Time-to-Market, необходимо решение, которое:

• поможет стандартизировать и автоматизировать все интеграции между инструментами анализа защищенности и существующими процессами разработки;

• позволит автоматизировать процесс управления уязвимостями и дефектами ИБ, контролировать передачу их в команды разработки и отслеживать исправление;

• даст возможность всесторонне измерять как уровень защищенности ПО, так эффективность самого DevSecOps процесса.

Исходя из этих предпосылок, в 2017 году в Swordfish Security начала создаваться собственная  DevSecOps платформа. В 2018 году  был разработан MVP и построены интеграции с ключевыми элементами инструментального стека. Начиная с 2019 года, наша команда активно проводила пилотные проекты с потенциальными клиентами и собирала обратную связь для улучшения продукта. Успешная коммерческая эксплуатация стартовала в начале 2020 года. На сегодняшний день продуктовая команда инвестировала в общей сложности более 50 человеко-лет в разработку решения, а продукт AppSec.Hub позволяет многим нашим клиентам интегрировать практики информационной безопасности в непрерывный цикл разработки по щелчку мышки.

В то же время в 2018 году Gartner идентифицировал область Application Security Testing Orchestration (ASTO), в своем ежегодном отчете Application Security Hype Cycle, а в 2019 данный сегмент был переименован в Application Security Orchestration and Correlation (ASOC). 

На сегодняшний день Gartner оценивает проникновение решений на рынок от 5% до 20% для клиентов из целевой аудитории. Однако на практике мы наблюдаем гораздо меньшее распространение этой технологии. По мнению Gartner, одним из основных препятствий для внедрения решений класса ASOC остается крайне низкий уровень осведомленности о факте их существования, хотя интерес к ним быстро растет. К сожалению, очень часто организации – разработчики ПО фокусируют свои усилия на более традиционном подходе в формате так называемой “лоскутной автоматизации”, который абсолютно не масштабируем, в отличие от ASOC. В том числе и эта причина сподвигла меня на написание этой статьи.

Цели и задачи инструментов класса ASOC

Итак, полноценная ASOC платформа:

• интегрирует инструменты анализа защищенности - Application Security Tools (AST) со стеком разработки программного обеспечения (DevOps);

• обеспечивает прозрачное взаимодействие в реальном времени между инженерными командами и экспертами информационной безопасности (Software Security Group);

• и реализует автоматизированное управление процессом создания защищенных программных продуктов на основе данных, получаемых из производственных конвейеров (DevSecOps pipelines).

Схематичное представление DevSecOps процесса и место платформы ASOC в нем можно изобразить в виде такой диаграммы:

С точки зрения DevSecOps процесса, ASOC платформа управляет вызовами всех инструментов ИБ на каждом из этапов жизненного цикла программного продукта, фиксирует результаты анализа для каждой версии артефакта приложения и контролирует уровень безопасности финальных дистрибутивов на основе статусов всех входящих в них последних версий элементов и компонент.

На наш взгляд, ASOC платформа для полноценного управления DevSecOps должна реализовывать полный спектр задач из всех трех доменов (функциональных областей) - Оркестрация, Корреляция, Аналитика.

Далее я расскажу про каждый домен чуть более подробно на примере нашего решения - AppSec.Hub.

Оркестрация (Orchestration)

В рамках процесса оркестрации, AppSec.Hub позволяет максимально быстро развернуть DevSecOps периметр для разрабатываемых программных продуктов вне зависимости от типа их архитектуры (от монолитной до микросервисной).

Для упрощения управления процессом DevSecOps платформа оперирует понятием базовых элементов программного продукта (так называемые Software Assets) - репозитории кода, артефакты сборки, дистрибутивы, контейнеры, экземпляры приложений, развернутых в средах тестирования и эксплуатации. Также, в рамках процесса оркестрации для большей гибкости программный продукт (приложение) может быть декомпозирован на структурные компоненты (так называемые Structure Units) - модули, микросервисы, так как за их реализацию часто отвечает отдельная инженерная команда. Включение программных продуктов с их компонентами и элементами в AppSec.Hub производится как в ручном, так и в автоматическом режиме.

Платформа AppSec.Hub позволяет провести интеграцию в режиме Plug&Play как с инструментами анализа защищенности (ИБ), так и с инструментами разработки (DevOps). На текущий момент мы поддерживаем практически полный спектр современного инструментального стека.

Инcтрументы ИБ:

• SAST: Checkmarx SAST, Fortify SAST, Veracode, SonarQube, Solar AppScreener;

• OSA/SCA: Sonatype Nexus Firewall, Sonatype Nexus Lifecycle, Synopsys BlackDuck;

• DAST: Netsparker, Acunetix, Stingray;

• CA: Aqua Security, Clair;

Инструменты разработки:

• Репозиторий исходного кода: GitLab, GitHub, Git, Bitbucket;

• Артифакторий: Sonatype Nexus Repository;

• CI/CD: Jenkins, TeamCity, CircleCI, GitLab CI;

• Дефект-менеджмент: Jira, YouTrack;

• Контейнеры: Docker;

Список поддерживаемых интеграций с инструментами растет и постоянно пополняется.

AppSec.Hub позволяет создать и сконфигурировать все необходимые пайплайны ИБ для каждого из типов элементов программного продукта. Пайплайны могут создаваться автоматически, используя уже существующие шаблоны - это сильно снижает трудозатраты при первоначальном включении большого количества приложений в контур DevSecOps. Для каждого пайплайна ведется история его запусков и отслеживаются результаты выполнения всех задач, а все данные помещаются в хранилище для последующего анализа.

AppSec.Hub позволяет создать и сконфигурировать все необходимые точки контроля качества ПО (Quality Gates), которые определяют критерии для успешного прохождения сканирования. Различные точки контроля могут применяться на различных этапах жизненного цикла программного продукта. Профили с пороговыми значениями и критериями прохождения этих точек контроля создаются отдельно, а сами точки контроля добавляются в пайплайн в рамках процесса конфигурирования задач сканирования.

Корреляция (Correlation)

Применение различных инструментов и технологических практик при выявлении уязвимостей ПО порождает гигантские объемы данных. В рамках технологии ASOC механизм корреляции уязвимостей является основой конвейера производства защищенного программного обеспечения.

Механизм корреляции позволяет:

• фильтровать ложные срабатывания;

• идентифицировать и объединять дубликаты уязвимостей;

• группировать уязвимости в дефекты на основе контекста;

• контролировать статус устраненных уязвимостей при последующих
  (полных и / или инкрементальных) сканированиях;

• формировать и накапливать данные о типовых уязвимостях, обогащая их информацией о способах выявления и устранения.

Такой подход сильно сокращает MTTR (Mean-Time-To-Resolve) в DevSecOps цикле, позволяет держать фокус команд (ИБ и разработчиков) на критических уязвимостях и позволяет инженерам увеличивать скорость распознавания возникающих угроз в разрабатываемых программных продуктах.

Инструменты анализа защищенности являются входными точками для нашей платформы и AppSec.Hub импортирует все уязвимости, обнаруженные в рамках сканирования в непрерывном процессе разработки ПО. AppSec.Hub минимизирует трудозатраты на анализ уязвимостей при помощи специального движка Application Vulnerability Correlation (AVC) и ряда фильтров для работы со списками уязвимостей.

Для анализа уязвимостей и фильтрации ложных срабатываний в AVC применяются технологии машинного обучения. Модель была обучена на базе более 1 миллиона уязвимостей, проанализированных вручную. AVC анализирует исходный код вместе с данными и дает предсказание о статусе уязвимости. AppSec.Hub присваивает уязвимости статус (False Positive / True Positive), если точность сделанного предсказания попадает в определенные заранее пороговые значения (thresholds). В данный момент в основе модели у нас применяются два алгоритма:

• DecisionTreeClassifier;

• KNeighborsClassifier;

В AppSec.Hub предусмотрена возможность совершенствования модели анализа уязвимостей на основе собственных данных клиента с использованием технологии активного обучения.

К уязвимостям, помеченным как True Positives, применяются правила корреляции для их группировки в дефекты ИБ. Правила корреляции основываются на таких параметрах, как - тип, CWE ID, имя файла, номер строки кода в файле, статус, категория и критичность уязвимости.

AppSec.Hub обеспечивает двухстороннюю синхронизацию данных и статусов дефектов с системами управления дефектами.

Процесс управления уязвимостями ПО и дефектами ИБ

1. Уязвимости детектируются инструментами анализа защищенности в процессе сканирования артефактов ПО, вызванным из конвейера DevSecOps.

2. Инструменты анализа являются основными источниками данных об уязвимостях. По завершению сканирования данные импортируются в AppSec.Hub.

3. На основе уязвимостей создаются дефекты ИБ. Один дефект ИБ может соответствовать нескольким уязвимостям, так как они могут иметь общую причину возникновения в исходном коде программного продукта.

4. Дефекты создаются в AppSec.Hub и экспортируются в системы дефект-менеджмента.

5. Для большей гибкости, дефектам ИБ могут присваиваться теги, а категоризация может быть реализована на базе атрибутов “Label” и / или “Component”, в случае Jira, для отслеживания дефектов в рамках конкретного структурного компонента программного продукта, контролируемого в AppSec.Hub.

6. Для упрощения процесса фикса дефектов, AppSec.Hub поддерживает несколько опций назначения дефекта на ответственного специалиста в дефект-трекере команды разработки. Такой специалист может быть в следующих ролях:
   - тимлид команды разработки, отвечающий за весь дефект-менеджмент процесс в рамках конкретного проекта в Jira;
   - ведущий инженер, ответственный за процесс дефект-менеджмента в рамках конкретного компонента ПО;
   - выделенный Security-чемпион, отвечающий за весь спектр задач информационной безопасности в инженерной команде;

7. AppSec.Hub постоянно мониторит статус уязвимостей и сравнивает результаты сканирования новых версий приложений с устраненными дефектами с результатами анализа предыдущих версий приложений в рамках настроенных пайплайнов. На основе истории сканирования и истории устранения дефектов AppSec.Hub выполняет автоматическую проверку и подтверждает, что дефекты действительно устранены.

Ниже представлена диаграмма обобщенного процесса управления уязвимостями и дефектами ИБ при помощи функционала ASOC платформ:

Risk Acceptance процесс для дефектов ИБ

Встречаются ситуации, когда при наличии уязвимости в коде по ряду причин необходимо отложить исправление дефекта. Данный процесс позволяет исключить ряд уязвимостей из анализа при прохождении контрольной точки качества (Quality Gate). Платформа переводит уязвимость в статус “Риск Принят”, при этом наличие уязвимости с данным статусом не учитывается при прохождении артефактом ПО контрольной точки качества. Для уязвимостей с таким статусом назначается целевой срок исправления и применяются специальные правила в рамках процесса работы с риском.

Ниже представлена диаграмма, иллюстрирующая этот процесс:

На этом я завершу первую часть статьи. О Data-Driven подходах к управлению процессом, DevSecOps-метриках и применении технологий искусственного интеллекта я расскажу во второй части, которую также постараюсь заверстать сегодня.

Часть вторая: https://habr.com/ru/company/swordfish_security/blog/596961/