Покажем на примере и скринах, как может использоваться CyberCodeReview в каноническом виде, некоторый референс, на который мы опираемся и который является лучшей практикой на сегодняшний день в индустрии.
Запрос 1 - у вас несколько сканеров и вы хотите систему, в которой вы бы могли объединить результаты сканирования для их дальнейшего анализа. При этом желательно иметь возможность дедупликации результатов между разными сканерами.
Запрос 2 - вы только собираетесь внедрять какие-то сканеры для выполнения анализа безопасности, например, исходного кода сервисов компании, знаете, что не существует "одного единственного идеального сканера" и также сразу ищете решение для сбора и дедупликации данных, а также решение для управления сканированиями.
Оттолкнемся от этих двух самых частых запросов от клиентов и покажем на практике как их реализовать.
CyberCodeReview может быть установлен в k8s, может быть масштабирован в сколь угодное количество реплик, может общаться с внешними предустановленными БД и системами для сбора кешей. Здесь все по классике и согласно нормальным инженерным практикам.
Итак, начнем решать задачу внедрения ASOC, его настройки и работы с файндингами.
Ассеты
Первое, что необходимо сделать для работы с ASOC - собрать внутри всю необходимую информацию о сервисах и ассетах, которые собираетесь сканировать.
Как правило, в компаниях для реализации задачи инвентаризации/управления инфраструктурой внедряются специальные системы, такие как Базы Данных управления конфигурациями (CMDB) или системы Service Discovery, с помощью которых в автоматическом режиме можно получать актуальную информацию о разрабатываемых сервисах и совмещать это с ассетами, которые они имеют (репозитории, хосты, ендпоинты, контейнеры).
Соответственно первая задача любого инженера при внедрении ASOC - автоматизация обновления информации о сервисах и его ассетах внутри ASOC.
Никто не говорит, что сервисы и ассеты нельзя задать вручную, но это достаточно трудоемко.
Что делать, если нет возможности написать собственный сервис для инвентаризации сканируемых сервисов? Вы можете создавать нужные продукты/ассеты прям из пайплайнов - каждый раз скрипты по API будут проверять существуют ли необходимые ассеты и, если да, отправлять отчет. Если нет - ассеты предварительно будут созданы.
Что предлагает CyberCodeReview для решения задачи сохранения всей необходимой информации о сервисах и ассетах? Удобный UI со всеми необходимыми сущностями. Первая базовая сущность - Продукт. У продукта может быть определенный "Тип" и различные "Теги". Для продукта можно задать различные ассеты/активы - Репозитории, Docker-образы, Домены и Хосты. Для каждого актива также можно определить различные "Теги".
Соответственно тут все просто - под "Продуктом" можно подразумевать некоторый сервис, который может состоять из нескольких репозиториев. Сервис может входить в некоторую бизнес-вертикаль/домен, что можно продемонстрировать указав его "Тип". Также для сервиса можно указать всю необходимую метаинформацию в тегах для фильтрации сервисов внутри ASOC. Что, как пример, удобно сохранять в виде тегов:
- языки программирования, на которых написан сервис
- если у вас внедрена практика AppSec Бизнес Партнеров, то указать Бизнес Партнера, отвечающего за продуктовую безопасность сервиса
- команду разработки/поддержки, если в вашем случае одна команда разработки может быть причастна к разработке нескольких сервисов
- идентификаторы сервиса в других Информационных Системах
Также есть возможность указать бизнес критичность для продукта, что будет влиять на показатель наличия общего риска этого Продукта по результатам проведенных сканирований. Изменения показателей риска удобно отслеживать на общем дашборде с трендами.
Сканирования
С помощью CyberCodeReview можно выполнять сканирования сервисов и настраивать сканирования прямо из UI. Low Code CI во весь рост.
Для конфигурирования определенного сканера необходимо создать определенное Задание (очень перекликается с Job в GitLab CI) - задать образ, исполняемую команду, переменные окружения. Далее эти задания можно объединить в один пайплайн сканирования, так называемую Последовательность. Их можно объединять по типу или цели сканирования: например, full scan будет выполнять все типы сканирования - искать секреты с помощью gitleaks, искать уязвимости с помощью semgrep, а также выполнять композиционный анализ с помощью trivy.
Отдельно можно собрать Последовательность SAST-Go, которая будет совмещать в себе Задания только с SAST анализаторами, например, тот же semgrep + gosec для семантического анализа Go.
Создав Последовательности вы можете переходить к сканированиям - выбрать один или несколько сервисов, "накликать" в них нужные ассеты, в данном случае репозитории с кодом, и запустить сканирование. Результат сканирования можно наблюдать во вкладке Аудитов. Это удобно, чтобы понять в каком сканировании какие проблемы безопасности были найдены. Конечно эти же результаты будут отображены в общей таблице с уязвимостями.
Важно подчеркнуть, что функция сканирования встроенная в ASOC не предназначена для интеграции в пайплайны разработки. Эта функция полезна для выполнения единоразовых сканирований или сканирований по расписанию.
Для чего удобно использовать функцию сканирования в ASOC:
- тестирование новых правил
- выполнение долгих сканирования, которые нельзя внедрить в пайплайны
- тесты новых инструментов
Если вам нужно внедрить сканирования в пайплайны разработки, можете воспользоваться нашими шаблонами - CyberCodeReview / pipeline... @GitLab , где есть готовые интеграции с CyberCodeReview.
Какие есть варианты загрузки файндингов в ASOC:
- отчетом, если есть готовый импортер (вскоре у нас появятся кастомные импортеры, которые можно будет использовать для загрузки отчетов от любых опенсорс и коммерческих сканеров)
- создавать файндинги по API
- через UI можно загрузить как отчет, так и вручную можно создавать файндинги
Работа с результатами сканирования
Самое важное, что должен уметь ASOC, и наш соответственно это делает:
- удалять дубликаты, полученные от разных сканеров
- помогать в триаже файндингов с помощью автоматизации
Первое, про дубликаты
CyberCodeReview поддерживает 2 механизма дедупликации - базовый и продвинутый.
Базовый механизм: вы можете самостоятельно выбрать скоуп определения дубликата. Искать дубликаты в рамках одного репозитория, одной ветки, одного хоста, домена и так далее или не учитывать этот критерий вовсе. Также можно выбрать более общий скоуп.
Продвинутый механизм дедупликации как раз призван решить проблему дедупликации между разными сканерами. Подробнее про механизмы дедупликации в CyberCodeReview рассказали в статье.
Теперь про помощь в триаже
Для того, чтобы помочь вам обработать вновь и вновь появляющиеся файндинги для разных сервисов, вы можете воспользоваться функцией Валидатора. Если вам проще не конфигурировать сканеры, а разгребать файндинги внутри ASOC, не беда.
Например, если вы точно знаете, что файндинги сканера, найденные с помощью определенного правила, всегда фолс позитивы, вы можете создать правило, которое будет переводить эти файндинги в статус отклоненной. Таким же образом можно поступить с файндингами, найденными, например, в тестовых директориях или любых других, потенциальные проблемы в которых вы не хотите отслеживать. Либо наоборот - если определенные файндинги сканера всегда нужно сразу брать в работу, да, вы также можете автоматически переводить их в статус подтвержденных.
Помимо возможности работы со статусами, вы можете автоматически добавлять различные теги для файндингов. Это поможет вам кастомизировать флоу работы с файндингами как вам удобно, а также позволит добавлять необходимую для вас информацию, если вам не хватает нужных полей.
Таким образом с помощью простых инструментов, дедупликатора и валидатора, и без какой-либо магии вы можете наладить работу с большим потоком файндингов из пайплайнов и сократить автоматизированно их число перед тем, как начать с ними работать вручную.
Конечно вам придется затратить определенное время на написание этих правил. Но, если что, мы вам сможем с этим помочь, обращайтесь)
Jira как драйвер процессов
Вот вы завели ассеты, внедрили сканеры, получили результат, автоматически, а затем и вручную его провалидировали. Что делать дальше, если файндинг подтвержден как уязвимость? Поставить команде разработки задачу на устранение и отслеживать ее статус. Можно ли это сделать с помощью CyberCodeReview? Конечно!
Наш ASOC имеет двустороннюю интеграцию с Jira, что позволяет актуализировать статусы где бы они не менялись - если разработчик двигает задачу в jira в Done, она закроется в ASOC. Точно также работает и наоборот - если задача будет закрыта в ASOC, она и в Jira закроется. При этом сопоставление статусов можно кастомизировать - не обязательно закрывать задачу, если ее переводят в Done в Jira. Можете ее перепроверить и если не нашлась, то закрыть. Автоматическое закрытие/удаление уязвимости, если она не нашлась в новом репорте - это настраиваемое действие.
Какие возможности можно выделить при использовании интеграции с Jira, помимо двусторонней связи:
- настройка дефолтного пространства и отдельных пространств для каждого продукта
- настройка одновременно двух отдельных пространств для двух групп участников процесса - отдельно для специалистов по ИБ и отдельно для разработчиков
- получение прямо в карточку с файндингом текста комментария, оставленного разработчиком
После настройки Jira наконец можно выдохнуть и налить себе чаю, потому что процесс управления уязвимостями базово настроен и им можно уже пользоваться.
Если у вас появилось желание пропилотировать продукт, пишите сюда. Мы также можем помочь с построением всего процесса управления уязвимостями на базе нашего продукта и не только.