Введение

Привет, Хабр! Меня зовут Вера Багно, я AppSec-инженер в компании Swordfish Security. Сегодня мы поговорим про инструмент управления уязвимостями DefectDojo, а также рассмотрим подход ASPM. О чем это мы?

Практика ASOC (Application Security Orchestration and Correlation, оркестрация и корреляция безопасности приложений), интегрирующая инструменты анализа защищенности со стеком разработки ПО, сегодня широко известна в сфере безопасной разработки. О ней много писали мы и другие авторы на Хабре. Эта концепция была переосмыслена и вышла на новый уровень. Специалисты Gartner даже ввели для нее новый термин ASPM, обозначающий практику, которая вместе с анализом уязвимостей и прочих задач ASOC включает в себя управление рисками. Особенности этого подхода, а также его реализацию в продукте DefectDojo мы и разберем ниже. 

Что такое ASPM?

ASPM (Application security posture management, управление состоянием безопасности приложений) — это целостный подход к безопасности приложений (AppSec), обеспечивающий единый источник достоверных данных для выявления, сопоставления и определения приоритетности уязвимостей на протяжении всего жизненного цикла программного обеспечения, от разработки до развертывания.

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

Отличительные особенности практики ASPM и инструмента DefectDojo

DefectDojo – это Open Source-решение класса ASPM, написанное на Python-фреймворке Django, позволяющее коррелировать результаты сканирований разных инструментов и агрегировать их на одном ресурсе. Этот продукт широко известен среди разработчиков и AppSec-инженеров, поскольку помогает решать множество задач, связанных с управлением уязвимостями.

В DefectDojo используются следующие сущности:

1. Product – программный продукт, включающий в себя сканирования, отчеты, уязвимости;

2. Engagements - сканирования. Они могут быть сгруппированы по инструменту, который проводил анализ;

3. Test – отчет по отдельному сканированию;

4. Finding – найденная уязвимость. 

DefectDojo имеет все отличительные особенности ASPM: интеграцию со сторонними инструментами, обеспечение централизованной политики, приоритизацию и сортировку уязвимостей, управление рисками. Давайте рассмотрим подробнее каждую составляющую.

Интеграция со сторонними инструментами

Решение ASPM должно иметь возможность получать данные из различных источников, включая разработку, развертывание и эксплуатацию программного продукта, программные активы, данные безопасности и выдачу заявок. 

DefectDojo способен обрабатывать результаты сканирования более чем 150 инструментов, среди которых BurpSuite, OWASP Zap, gitleaks, nmap, OWASP Dependency-Track (у него даже есть встроенная интеграция с DefectDojo). Платформа парсит результаты сканирования этих источников благодаря встроенным парсерам, которые анализируют отчеты, предоставленные в заданном формате (JSON, XML и другие). Если нужного инструмента нет в списке доступных, для него можно написать парсер самостоятельно с помощью документации. Сам DefectDojo встраивается в пайплайн DevOps, чтобы отчеты отправлялись автоматически сразу после проведения сканирования.

Таким образом, в DefectDojo есть возможность интеграции как с ручными, так и с автоматическими инструментами тестирования AppSec. 

Централизованная политика

Решения ASPM призваны стандартизировать методы обеспечения безопасности, применяемые в командах, проектах и инструментах. Они централизованно определяют, применяют и отслеживают политики безопасности для тестирования приоритизации. Это позволяет масштабировать рабочие процессы AppSec.

Информация, загружаемая в DefectDojo, содержит оценку критичности для каждой найденной инструментом сканирования уязвимости. Это позволяет приоритизировать наиболее опасные ИБ-проблемы, чтобы исправлять их в первую очередь. 

Определить политики безопасности можно через систему SLA (Service Level Agreement — соглашение об уровне обслуживания). В DefectDojo SLA позволяет выставить количество дней, в течение которых разработчик обязан ликвидировать уязвимость:

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

Приоритизация и сортировка

Наличие средств для консолидации соответствующих точек данных и стандартизации рабочих процессов является первым препятствием в управлении AppSec, но группы безопасности также должны иметь доступ к возможностям ASPM для поддержания производительности разработчиков.

Решение ASPM должно устранять дублирование избыточных результатов между инструментами и помогать в определении приоритетных проблем, которые командам нужно решить в первую очередь, основываясь на определенных политиках для критериев риска. Они могут включать серьезность проблемы, критичность программного обеспечения и определенные соглашения об уровне обслуживания для устранения недостатков ИБ. 

В DefectDojo есть возможность фильтрации уязвимостей по их критичности, CWE, дате возникновения, статусу в системе (Open, Verified, False Positive, Risk Accepted, Closed…) и другим фильтрам. Инструмент назначает статусы уязвимостей, изменяет их критичность и описание и другие аспекты, функционал предоставляется внутри самого DefectDojo через UI. Это позволяет гибко настраивать критичность уязвимости для каждого конкретного программного продукта, дополнять их описание, приоритизировать их исправление для команды разработчиков.

Также в инструменте есть функция тегирования для ПО, уязвимостей и сканирований. В зависимости от политик команды она используется для упрощения ориентации в уязвимостях и ускорения их закрытия. Можно включить наследование тегов от продукта, тогда аналогичными тегами будут помечаться привязанные к этим продуктам сканирования (Engagements), отчеты (Tests), уязвимости (Findings). 

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

В решении задачи дедупликации помогает встроенный в DefectDojo механизм обработки дублирующихся уязвимостей. При срабатывании инструмент помечает их как дубликаты либо удаляет (в зависимости от настроек).

Сами настройки алгоритма дедупликации можно посмотреть в документации, а поменять – в исходном коде. Для SAST-инструмента сравниваются поля 'title', 'cwe', 'line', 'file_path', 'description'; для DAST – 'title', 'cwe', 'line', 'file_path', 'description', 'endpoints'. Однако в той же документации есть предупреждение, что результаты могут быть неожиданными из-за тонкостей настроек, поэтому, в случае возникновения проблем, нужно перейти в режим дебага.

Как один из инструментов приоритизации можно рассматривать функцию Request peer review, позволяющую направить уязвимость на изучение конкретному члену команды.

Благодаря этим возможностям разработчики могут сосредоточиться на наиболее важной деятельности по обеспечению безопасности.

Управление рисками

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

В DefectDojo для этого существуют метрики, благодаря которым можно оценить “здоровье” продукта, количество найденных и закрытых уязвимостей в нем, а также дать оценку эффективности работы каждого инженера в отдельности. Стоит учитывать, что здесь представлены самые базовые метрики, по ним будет сложно оценить результативность процесса по аналогии с DORA для DevOps.

Достоинства DefectDojo

Главное преимущество инструмента DefectDojo в том, что он является Open Source-проектом с опубликованным на Github исходным кодом, написанным на Python. Он легко устанавливается, его можно дорабатывать своими силами, внедрять в исходный код необходимые функции и метрики или запрашивать у разработчиков и сообщества дополнительную функциональность.

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

• Готовые парсеры для 150+ сканеров и возможность написать собственный парсер;

• SLA и отслеживание количества дней для исправления уязвимости;

• Исчерпывающая система фильтров для уязвимостей;

• Тегирование;

• Управление уязвимостями и их дедупликация;

• Функция request peer review для запроса помощи у коллеги;

• Минимальный набор метрик инженерного уровня;

И это еще не всё. К перечисленным преимуществам можно добавить:

• API, позволяющий гибко управлять инструментом через пайплайн. Для интеграции DefectDojo в пайплайн DevOps часто используют API, чтобы запрашивать и отправлять результаты сканирований для определенного программного продукта. Документация к API также понятно написана, в самом инструменте есть Swagger;

  

• Система оповещений, которую можно настроить на определенное событие, например, при нарушении SLA отправлять разработчикам автоматические уведомления с информацией, насколько критична уязвимость и сколько дней им отводится для ее устранения. Оповещения можно получать на email, в мессенджеры и т.д. (настраивается под требования). Из коробки присутствуют Slack и MicrosoftTeams, а также собственные уведомления внутри DefectDojo. Если вы пользуетесь мессенджерами (Telegram, Mattermost, Яндекс-Мессенджер, VK-Teams или собственным внутренним продуктом), то для них нужно будет дорабатывать систему уведомлений;

• Есть поддержка LDAP, OAuth, SAML 2.0;

• Интеграция с Jira, позволяющая настроить выгрузку уязвимостей сразу в систему трекинга. Объединение Jira с DefectDojo двунаправленное и синхронизирует данные программные продукты без привязки к тому, какой из них появился раньше и как долго с ним взаимодействовали разработчики;

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

Недостатки DefectDojo

При использовании данного инструмента могут возникнуть следующие проблемы:

• Неэффективная работа при высокой нагрузке. Этот инструмент не заточен под работу с большим объемом данных. Команда ВК (3:00) также подчеркивает, что у нее были проблемы с производительностью при попытке подключить DefectDojo ко множеству пайплайнов, случались сбои в работе;

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

• Крайне неудобная система организации фильтров. Да, фильтры отлично подходят для осуществления поиска по названиям, тегам и другим полям, однако можно легко потеряться в их настройке. Как пример – фильтры для Findings (уязвимостей). В DefectDojo им может быть присвоено одновременно несколько статусов, например “Active, Verified” или “Inactive, Out of Scope”. Но через фильтр Status можно выбрать только один статус, также там перечислены не все возможные. Для более точечной фильтрации уязвимостей нужно искать дополнительные поля, которые расположены в местах, не слишком очевидных для пользователя;

• Есть особенности работы с Jira: уязвимости синхронизируются только поодиночке (нельзя связать группу с одним тикетом в Jira), и в область синхронизации входит статус, лейбл и комментарии. Так что в заявке не получится указать инженера или связать обращение с практикой через компонент. При этом комментарий будет отправлен в Jira только в случае, если риск будет принят или не принят (Accept или Unaccept), в иных ситуациях он вовсе не будет отправлен. В DefectDojo об этом знают. 

• Метрики только для разработчиков и менеджеров команд. В основном они позволяют выяснить статус “здоровья” продукта и скорость закрытия им уязвимостей, а также оценивать результаты работы команды в течение недели или месяца. Однако мало показателей, которые бы отслеживали бизнес-процессы, повторное появление ранее обработанных или закрытых проблем безопасности и технический долг по разным практикам.

Выводы

Как использовать DefectDojo и с какими целями его дорабатывать – решать только вам. Разработчики предпочитают его за удобство API и возможность автоматизировать собственные процессы, без учета работы AppSec-инженера. ИБ-специалисты выбирают этот инструмент, чтобы собирать все отчеты об уязвимостях в одном месте и на их основании писать репорт о найденных багах.

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

Стоит помнить, что главный плюс в виде Open Source может быть и минусом. Разворачивая OpenSource, нужно быть готовым к тому, что придется править какие-нибудь детали его реализации. А для этого нужны разработчики или AppSec-инженеры, способные дорабатывать код DefectDojo. По нашему опыту, инструменты Open Source чаще используются на начальных этапах развития и внедрения DevSecOps. Конечно, известны случаи использования DefectDojo большими компаниями, но чаще крупные организации выбирают что-то более предсказуемое, так как не справляются с объемами кода, который необходимо отредактировать под себя.

Как и любой Open Source-инструмент, DefectDojo может быть подвержен Supply Chain Attack (атаке на цепочку поставок), поскольку любой желающий способен внести в исходный код зловредные изменения или protestware. 

И еще один тонкий момент, связанный с Open Source-инструментами – потенциальный конфликт интересов в случае, если разработчик вашей организации захочет участвовать в развитии DefectDojo - он может опубликовать в общедоступном репозитории код, написанный для вашего инстанса DefectDojo за деньги организации. Даже если вы юридически защитите себя от подобного исхода, может возникнуть ситуация, когда разработчик, внедряющий новые функции в DefectDojo, уйдет из компании вместе с экспертизой по тому коду, который он написал. Тогда новому специалисту на его месте будет очень сложно разобраться в этом коде, и разработанный ранее функционал станет невозможно поддерживать и развивать.