Проблемы безопасности

Примечание

Для выполнения нижеописанных действий требуется роль Инженер ИБ.

Каждый инструмент AST создает отчет по безопасности (Security Report) во время каждого запуска тестирования безопасности. Это происходит в рамках работы Security Pipeline. Отчет по безопасности содержит список проблем безопасности (Security Issues), обнаруженных в ходе тестирования. Работу с отчетом по безопасности следует начинать с импорта выявленных проблем из инструментов AST в AppSec.Hub.

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

Импорт проблем безопасности

Несмотря на то, что импорт Security Issues после завершения сканирования осуществляется автоматически, предусмотрена возможность выполнить его «вручную», используя пользовательский интерфейс AppSec.Hub.

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

Нажмите строку выбранного приложения.

Слева в меню выберите пункт Issues, нажмите кнопку Actions в правом верхнем углу и в выпадающем меню выберите пункт Import all issues, чтобы импортировать проблемы из инструментов AST. В правом нижнем углу появится подтверждение начала импорта — Import started.

После завершения на экране появятся импортированные проблемы. В показанном на рисунке выше примере проблемы были обнаружены в результате запуска инструментов SCA.

Общее количество открытых на данный момент проблем безопасности (еще не исправленных и не имеющих статус Fixed), относящихся к данному приложению, отображается рядом с пунктом меню Issues.

Чтобы импортировать проблемы для нескольких приложений из ранее проведенных сканирований, на главном экране AppSec.Hub выберите в меню пункт Issues.

Нажмите кнопку Actions в правом верхнем углу и в выпадающем меню выберите пункт Import all issues. На экране появится окно Choose application.

Выберите в этом окне приложения, для которых необходимо импортировать проблемы. Чтобы выбрать все доступные пользователю приложения, нажмите пункт Select all. Отдельные приложения можно выбрать, нажав на выпадающее меню Enter Application Name. Можно воспользоваться поиском нужных приложений, введя имя или часть имени приложения в поле Search.

Список уже выбранных приложений можно скорректировать. Чтобы исключить из списка уже выбранное приложение, достаточно в списке нажать значок справа от его имени. Чтобы очистить весь список, нажмите кнопку Deselect all в левом нижнем углу окна.

Чтобы начать импорт, нажмите кнопку Import в правом нижнем углу окна. На экране появится окно The import process started. В этом окне содержится информация о том, для каких приложений был начат процесс импорта проблем, а для каких он не стартовал по каким-либо причинам с указанием ID приложения, его имени и описанием ошибки. Нажмите кнопку Ok внизу окна.

После завершения на экране появятся импортированные проблемы.

Информация о проблемах безопасности

AppSec.Hub предоставляет информацию и позволяет работать с проблемами безопасности как для одного выбранного приложения, так и для всех приложений, к которым пользователь имеет доступ. Информация о проблемах безопасности всех доступных пользователю приложений отображается на общей странице проблем безопасности Issues. По сути, собранная на этой странице информация объединяет и дублирует все сведения о проблемах безопасности, содержащиеся на страницах Issues для каждого отдельного приложения.

Каждая проблема представлена на экране отдельной строкой, которая содержит описание проблемы в следующих столбцах:

ISSUE DETAILS — краткое описание проблемы. Данное поле может включать следующую информацию в зависимости от типа проблемы:
- # — идентификатор проблемы в системе и ее краткое описание.
- State — состояние проблемы безопасности (New, Repeated).
- Type — тип проблемы (SAST, DAST, SCA Compliance и SCA Security).
- Application — ссылка на приложение, к которому относится проблема.
- Codebase/Artifact/Instance — источник проблемы, имя кодовой базы/артефакта/экземпляра приложения, в котором была найдена эта проблема безопасности.
- Category — тип категории проблемы (например, Potential_SQL_Injection для проблем, выявленных SAST и т. д.).
- Found by — инструмент AST, обнаруживший проблему.
- CVE ID (Common Vulnerabilities and Exposures ID) — ссылка на описание уязвимости в базе данных общеизвестных уязвимостей информационной безопасности (CVE).
- CWE ID (Common Weakness Enumeration ID) — указывается, если применимо. CW — это список типов слабых мест (weakness) программного и аппаратного обеспечения, разработанный сообществом специалистов в этих областях. Он используется в качестве общего языка и стандарта для инструментов безопасности, а также в качестве базы для идентификации выявленных слабых мест, для уменьшения последствий от их присутствия, и для их предотвращения.
- CVSS (Common Vulnerability Scoring System) — указывается, если применимо. Оценка проблемы по CVSS по шкале от 0 до 10, где 10 указывает на максимальную опасность.
- AVC status — статус проблемы безопасности на основе предиктивной модели анализа AVC (True Positive/False Positive).
- AVC Accuracy — точность оценки AVC-модели.
- AVC Model — используемая AVC-модель.
SEVERITY — серьезность проблемы в инструменте AST (Low, Medium, High, Critical).
STATUS — статус проблемы в системе (To Verify, Confirmed, Open, Fixed, False Positive).
DEFECT — ссылка на соответствующий дефект безопасности, если он уже существует.

Кроме того, справа в конце строки каждой проблемы представлено выпадающее меню «», содержащее пункты:

Create defect — этот пункт используется для создания нового дефекта безопасности на основе данной проблемы безопасности, см. раздел «Создание дефекта безопасности на основе проблем безопасности».
Accept risk — этот пункт используется для принятия риска путем добавления проблемы безопасности, имеющей статус To verify, в исключения, см. раздел «Добавление проблем безопасности в исключения». В случае, если проблема имеет статус, отличный от To verify, пункт меню Accept risk будет находиться в неактивном состоянии. В случае, если для данной проблемы безопасности риск уже был принят, этот пункт в меню меняется на пункт Reject risk acceptance.
False Positive и To verify — с помощью этих пунктов можно отмечать проблемы безопасности, имеющие статус To verify, которые являются результатом ложных срабатываний инструментов сканирования или переводить их обратно в статус To verify, см. раздел «Присвоение проблеме безопасности статуса False positive».
Create rule — этот пункт используется для присвоения проблеме безопасности статуса False positive одновременно с созданием в системе соответствующего правила для текущего приложения, см. раздел «Присвоение проблеме безопасности статуса False positive с созданием правила».

Вся отображенная на экране информация о проблемах безопасности импортируется в AppSec.Hub из инструментов AST.

Нажмите идентификатор проблемы безопасности #, чтобы поработать с этой проблемой. На экране появится окно с подробной информацией о ней. Окно содержит шесть вкладок.

Details — подробная информация о проблеме с указанием потенциальной опасности, причины ее возникновения, а также рекомендаций по устранению. Для проблем безопасности, обнаруженных в ходе сканирования, привязанного к релизному объекту, приводится дополнительная ссылка на релизный объект. Кроме того, в полях AVC Status и AVC Accuracy приведены результаты AVC-анализа (Application Vulnerabilities Correlation), см. раздел «Настройки корреляции уязвимостей приложения» Руководства администратора.
Path — информация, позволяющая локализовать источник проблемы.
Status history — история сканирования проблемы безопасности. Эта вкладка содержит информацию о каждом случае обнаружения проблемы во время выполненных проверок безопасности, а также на ней можно проследить историю изменения статусов уязвимости (поля Old Status и New status). Обновление статуса отображается только в случае его действительного изменения — если, например, было проведено сканирование, но статус Security Issue не изменился, обновляется только дата. Поле Scan Task Id автоматически заполняется по результатам проведенного сканирования, а при нажатии на эту ссылку происходит переход на страницу с детальной информацией об этом сканировании.
State history — история изменения состояний проблемы безопасности. Помимо даты, времени и идентификатора сканирования на вкладке отображается состояние проблемы безопасности (New, Repeated), выбранный алгоритм изменения статуса (ISSUE STATE POLICY), а также идентификатор сканирования, с результатами которого осуществлялось сравнение (REGARDING THE SCAN TASK).
Comments и Recommendation — обеспечивают возможность добавления соответственно комментариев и рекомендаций. Они будут сохранены после нажатия кнопок Send на вкладке Comments или Save на вкладке Recommendation. Если в дальнейшем будут обнаружены похожие проблемы безопасности, все сохраненные рекомендации будут автоматически добавлены к ним. Эта функциональность реализована в AppSec.Hub на основе анализа корреляции проблем.

AppSec.Hub анализирует историю каждой проблемы безопасности. Если проблема была обнаружена во время сканирования безопасности, но затем не обнаружена во время следующего сканирования, она автоматически получает статус Fixed.

Нажмите ссылку на инструмент AST в поле Found by справа на вкладке Details. Откроется страница авторизации соответствующего инструмента AST. Введите учетные данные, чтобы просмотреть и при необходимости отредактировать проблему безопасности в инструменте AST. В AppSec.Hub проблемы безопасности редактировать невозможно. Если проблемы безопасности были отредактированы и обновлены в инструменте AST, необходимо импортировать это обновление в AppSec.Hub. Чтобы импортировать обновленные задачи, нажмите на кнопку Actions и в выпадающем меню выберите пункт Import all issues. Информацию о проблемах безопасности можно экспортировать в файл, см. раздел «Экспорт проблем безопасности в файл».

Группировка проблем безопасности

AppSec.Hub определяет корреляцию между импортированными из инструментов AST проблемами безопасности и группирует их. Система выполняет автоматический анализ выявленных проблем безопасности в контексте истинно/ложноположительных проблем на основе модели машинного обучения. Для схожих истинно положительных результатов в системе документируются один и тот же статус, а также рекомендации, предположения о причинах возникновения и меры по устранению. На основе используемой модели корреляции выявленные проблемы безопасности группируются и объединяются в дефекты безопасности.

Проблемы безопасности можно сгруппировать вручную. Чтобы настроить правила фильтрации, нажмите кнопку Show filters в правом верхнем углу страницы. Реализованы четыре механизма фильтрации: один с применением правил корреляции, а также три настраиваемых.

Кроме того, на общей странице проблем безопасности Issues можно задать фильтр по приложению — by application. После того, как в поле by application выбрано приложение, можно поставить дополнительный фильтр на структурные единицы приложения в поле by structure unit.

Чтобы активировать режим фильтрации с использованием правила корреляции, переведите селектор Apply correlation rules by default в положение «включено» и выберите используемое правило корреляции (только для SAST уязвимостей).

Три настраиваемых режима фильтрации предлагают следующие возможности:

Фильтрация с использованием Issue properties.
Фильтрация с использованием Linked entities.
Фильтрация с использованием AVC.

Выбрав справа в поле Filters вариант фильтрации Issue properties, получаем возможность сортировки проблем безопасности по следующим критериям:

sort by — по уровню серьезности — Severity: High to Low/Low to High (от более серьезных к менее, и наоборот) или по времени занесения/последнего обновления — Newest first/Last updated (сначала новые/сначала старые);
by type — по типу (SAST, SCA Compliance, SCA Security и DAST);
by structure unit — по структурным единицам приложения;
by status — по статусу (To Verify, Confirmed, Open, Fixed и False Positive);
by tool — по инструменту, с помощью которого обнаружена уязвимость (NetSparker, Acunetix, MDast, Wallarm, IBM Security AppScan, Fortify Static Code Analyzer и SonarQube);
by severity — по серьезности (Low, Medium, High и Critical);
by source — по источнику;
by category — по категории;
by CWE ID — по CWE ID;
by CVE ID — по CVE ID;
updated in — по дате последнего обновления (Last week, Last month, Last 3 months, Last 6 months, Last year, Last 2 years и Last 3 years).

Примечание

В полях by type, by status, by tool, by severity и updated in может быть одновременно выбрано несколько параметров, см. рис. ниже.

Выберите группу проблем безопасности из доступных вариантов. Для более точной группировки проблем в AppSec.Hub доступно применение нескольких критериев фильтрации одновременно. Проблемы на рисунке ниже сгруппированы в соответствии с выбранными опциями (SAST, SCA Compliance и SCA Security в поле by type, WEB-INF в поле by source).

Выберите вариант фильтрации Linked entities, чтобы отсортировать проблемы безопасности с учетом связанных с ними сущностей (кодовых баз, артефактов или инстансов), используя следующие поля:

sort by — по уровню серьезности — Severity: High to Low/Low to High (от более серьезных к менее, и наоборот) или по времени занесения/последнего обновления — Newest first/Last updated (сначала новые/сначала старые);
by type — по типу уязвимости (SAST, SCA Compliance, SCA Security и DAST);
by structure unit — по структурным единицам приложения;
by codebase — по кодовым базам;
by artifact — по артефактам;
by instance — по инстансам (экземплярам приложения);
by repository proxy — по проски-репозиториям.

Примечание

В полях by structure unit, by type, by codebase, by artifact, by instance и by repository proxy может быть одновременно выбрано несколько параметров, см. рис. ниже.

Выберите вариант фильтрации AVC, чтобы отсортировать проблемы безопасности с использованием результатов AVC-анализа:

sort by — по уровню серьезности — Severity: High to Low/Low to High (от более серьезных к менее, и наоборот) или по времени занесения/последнего обновления — Newest first/Last updated (сначала новые/сначала старые).
by type — по типу уязвимости (SAST, SCA Compliance, SCA Security и DAST).
by AVC status — по статусу AVC (False Positive (ложноположительные), True Positive (истинно положительные)).
by lower limit of accuracy — по нижнему пределу точности оценки AVC.
by upper limit of accuracy — по верхнему пределу точности оценки AVC.

Примечание

В полях by structure unit, by type и by AVC status может быть одновременно выбрано несколько параметров, см. рис. ниже.

Для каждой проблемы в соответствии с оценкой AppSec.Hub отображаются AVC-статус (False Positive (ложноположительный) или True Positive (истинно положительный)) и достоверность этой оценки в процентах.

Добавление проблем безопасности в исключения

Важное замечание

Для выполнения нижеописанных действий требуется роль Инженер ИБ. Для других ролей в AppSec.Hub данная функциональность недоступна.

Некоторые компоненты (например, open-source библиотеки), используемые при разработке приложений, могут не иметь безопасных версий. В такой ситуации Инженеры ИБ, в результате соответствующих управленческих решений, могут разрешать использование таких компонентов, допуская наличие соответствующего риска (Accepted Risk), путем добавления проблем безопасности в исключения. В результате при сканировании AppSec.Hub не воспринимает данную уязвимость как подлежащую учету при расчете критериев QG. Таким образом, по сути происходит преднамеренный отказ от использования тех или иных критериев или политик безопасности в отношении проблем, добавленных в исключения.

В AppSec.Hub реализован механизм добавления выявленных проблем безопасности в исключения. Наличие уязвимости, добавленной с помощью данного механизма в исключения, считается допустимым и не является блокирующим фактором, например, при принятии окончательного решения о готовности релиза к развертыванию в промышленную эксплуатацию. На данный момент в AppSec.Hub статус Accepted Risk может устанавливаться только для уязвимостей, выявленных инструментами SCA (например, Clair).

Заметим, что добавление уязвимостей в исключения в том или ином виде реализовано во многих инструментах AST. Для получения дополнительной информации, пожалуйста, обращайтесь к сопроводительной документации соответствующих продуктов. Важно подчеркнуть, что обмен информацией о Security Issues между AppSec.Hub и отдельными инструментами (например, Nexus IQ) носит двухсторонний характер. Например, после изменения статуса в AppSec.Hub также изменяется статус в отчете Nexus IQ.

Если в SCA инструменте (например, Nexus IQ или Aqua Security) уязвимость добавлена в исключения (waived в Nexus IQ или acknowledged в Aqua Security), то при импорте в AppSec.Hub она получает статус Accepted risk. И наоборот, если какая-либо уязвимость будет добавлена в исключения в AppSec.Hub, соответствующий компонент автоматически получит статус waived в инструменте. Также в инструмент будут переданы данные о пользователе, создавшем данное исключение, идентификационные данные уязвимости с указанием CVE и соответствующий комментарий.

Примечание

При работе с инструментом Aqua Security уязвимости, добавленные в исключения в AppSec.Hub и получившие в нем статус Accepted risk, при импорте в Aqua Security не получают в этом инструменте статус acknowledged.

Примечание

При импорте проблем безопасности из инструмента Aqua Security в AppSec.Hub передается также информация из полей Delete this rule in X days и Reason в этом инструменте (соответственно в поля Expired at и Comment в AppSec.Hub).

Если для приложения включен прокси-репозиторий и в нем уязвимость добавлена в исключения, а также к исключению добавлен комментарий «Autowaive: True», то при импорте уязвимостей в AppSec.Hub создается правило, которое отображается на вкладке Rules страницы Risk Acceptance. Также аналогичное правило может быть создано и непосредственно из интерфейса AppSec.Hub, см. разделы «Безусловное принятие риска» и «Условное принятие риска».

Для каждого правила указывается следующая информация:

ID — идентификатор правила в системе.
ISSUE TYPE — тип Security Issue.
LIBRARY — используемая библиотека.
CVE — ссылка на описание уязвимости в базе данных общеизвестных уязвимостей информационной безопасности (CVE, Common Vulnerabilities and Exposures).
IS OBSOLETE — статус правила — если правило распространяется на какие-либо проблемы безопасности в приложении, в данном поле появляется значение true, в противном случае — false.
CREATED — дата и время создания.
EXPIRED — срок действия.

Справа от каждого правила располагается иконка , нажав которую его можно удалить.

Если при последующем сканировании кодовой базы или артефакта будет обнаружена уязвимость с таким же названием, такой же версии и идентичным значением severity, то на основе созданного правила ей будет автоматически присвоен статус Accepted risk. Такой подход позволяет избежать заметных временных затрат на повторное изменение статуса с To verify на Accepted risk для аналогичных проблем безопасности — однажды определив риск как допустимый, в дальнейшем нет необходимости изменять статус «вручную».

В AppSec.Hub реализована возможность импорта комментариев из инструментов, т. е. информацию о причине добавления уязвимости в исключения можно посмотреть на вкладке Comments соответствующей Security Issue. Аналогично комментарии передаются из AppSec.Hub в соответствующий инструмент.

В свою очередь, если в AppSec.Hub для уязвимости установлен статус Accepted Risk, в инструмент (например, Nexus IQ) также отправляется запрос на изменение статуса соответствующей уязвимости (в случае Nexus IQ уязвимость получит статус waived).

В системе реализованы два типа механизмов принятия рисков: безусловный и условный. В случае безусловного принятия риска Инженер ИБ безоговорочно допускает наличие определенной уязвимости и она не учитывается при расчете Quality Gates. Во втором случае, как очевидно из названия, риск принимается с определенным условием — он также считается допустимым и наличие уязвимости не учитывается при расчете QG, но только до тех пор, пока выполняется определенное условие (правило) — в исходном коде не найдено ни одной уязвимости, обусловленной данным правилом (см. раздел «Категории уязвимостей» Руководства администратора). Для условного принятия риска зачастую используется термин митигация (от англ. mitigation — ослабление/смягчение условий).

Суть условного принятия заключается в том, что за счет специальных конструкций кода, уязвимость не может быть эксплуатируемой. То есть, код написан так, что он защищает от злоумышленника, фильтрует и контролирует пользовательские данные, передаваемые в компоненту. Либо правило условного принятия контролирует, что уязвимый метод/класс не используется или вызывается.

Проиллюстрируем последнее утверждение следующим примером. Предположим, что необходимо разрешить использование некоторой библиотеки, в которой инструментами SCA выявлена уязвимость, но только до тех пор, пока в исходном коде SAST инструментом не будет обнаружена уязвимость определенной категории, например Find_Anti_XRSF_Actions. Таким образом, понимая, что общая уязвимость библиотеки обусловлена наличием в ней отдельных небезопасных методов или функций и ограничивая именно их использование (посредством задания определенного условия), Инженер ИБ принимает допустимость соответствующего риска. При этом, как только использование небезопасных методов или функций будет обнаружено инструментом SAST (заданное условие, в нашем примере Find_Anti_XRSF_Actions, будет нарушено), добавленная в исключения SCA-уязвимость начнет учитываться при расчете Quality Gate.

В AppSec.Hub создается необходимое правило (о практической реализации ниже), см. блок Risk accepted на рисунке ниже. В соответствии с ним, данная уязвимость учитывается при расчете Quality Gate, только если в ходе сканирования выявлена SAST-уязвимость типа Find_Anti_XRSF_Actions (см. поле Condition).

Примечание

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

Однако если при следующем сканировании эта же уязвимость будет обнаружена вновь, то при импорте в AppSec.Hub она снова получит статус, например, False Positive.

Другими словами, статус, задаваемый правилом в AppSec.Hub, имеет более высокий приоритет, чем статус инструмента.

Чтобы из AppSec.Hub добавить проблему безопасности в исключения, переходим на страницу Issue details и, нажав кнопку Actions , расположенную в правом верхнем углу пользовательского интерфейса, в раскрывающемся меню выбираем пункт Accept risk.

Существует альтернативный способ добавить проблему безопасности в исключения. Для этого необходимо на странице Issues справа в конце строки выбранной проблемы безопасности в выпадающем меню «» выбрать пункт Accept risk.

Безусловное принятие риска

Чтобы выполнить безусловное принятие риска и исключить уязвимость из расчета Quality Gate, в появившемся окне Accept the risk достаточно указать причину в поле Comment и нажать кнопку Accept. При необходимости можно указать срок принятия риска в поле Expiration Date. Если срок не указан, риск будет принят на постоянной основе — без ограничений по времени.

Если выбрана опция With similar issues in the current application, то в исключения будут добавлены все аналогичные уязвимости данного приложения (эта опция доступна только для OSA практики, т. е. уязвимостей, найденных в компонентах из карантина репозитория).

В правом нижнем углу пользовательского интерфейса на странице уязвимости появляется соответствующее подтверждающее сообщение, а в правой колонке вкладки Details — блок Risk Accepted, содержащий краткую информацию о созданном правиле:

Acceptor — логин пользователя, принявшего данный риск.
Accepted at — дата и время создания правила.
Expired at — срок действия созданного правила.
Comment — комментарий.

Условное принятие риска

Условное принятие риска выполняется аналогично безусловному (см. раздел «Безусловное принятие риска»), с той разницей, что в окне Accept the risk необходимо выбрать опцию With condition.

Затем в раскрывающемся меню поля Considered SAST category выбираем необходимое условие.

Примечание

В данном поле отображаются только SAST-категории, подгружаемые из соответствующих инструментов. Более подробная информация приведена в разделе «Категории уязвимостей» Руководства администратора.

При необходимости можно указать срок принятия риска в поле Expiration Date. Если срок не указан, риск будет принят на постоянной основе — без ограничений по времени.

Поле Comment является обязательным для заполнения. Если выбрана опция With similar issues in the current application, то в исключения будут добавлены все аналогичные уязвимости данного приложения (эта опция доступна только для OSA практики, т. е. уязвимостей, найденных в компонентах из карантина репозитория). После нажатия кнопки Accept в правом нижнем углу пользовательского интерфейса отображается подтверждающее сообщение, а в системе создается соответствующее правило. При условном принятии риска в блоке Risk accepted появляется дополнительное поле Condition, в котором указывается выбранное условие.

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

Информация об уязвимостях, добавленных в исключения, отображается на странице Risk Acceptance.

Для каждой Security Issue, имеющей статус Accepted Risk, отображается следующая информация:

ID — идентификационный номер правила, созданного в AppSec.Hub.
ISSUE ID — идентификационный номер Security Issue.
ISSUE TYPE — тип Security Issue.
CONDITIONAL SAST CATEGORY — используемое SAST категория (условие) в случае условного принятия риска.
ACCEPTED — дата и время создания соответствующего правила (принятия риска).
ACCEPTOR — учетная запись пользователя, создавшего соответствующее правило.
EXPIRED — срок действия правила.

Кроме этого, на вкладке Rules данной страницы отображается перечень созданных для данного приложения правил.

Удаление уязвимости из исключений

Чтобы удалить уязвимость из списка исключений, откройте страницу с детальной информацией об этой уязвимости, нажмите кнопку Actions , расположенную в правом верхнем углу, и в раскрывающемся меню выберите пункт Reject risk acceptance.

Существует альтернативный способ удалить уязвимость из списка исключений. Для этого необходимо на странице Issues справа в конце строки выбранной проблемы безопасности в выпадающем меню «» выбрать пункт Reject risk acceptance.

Подтвердите удаление уязвимости из списка исключений в появившемся окне.

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

Настройка алгоритма изменения состояний проблем безопасности

Примечание

Для выполнения нижеописанных действий требуется роль Менеджер.

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

Чтобы более ярко обозначить потенциальную проблему, рассмотрим гипотетическую ситуацию, когда Quality Gate настроен на полное отсутствие новых проблем безопасности (имеющих состояние NEW). Более подробная информация о критериях качества (Quality Gates) и их настройках приведена в разделе «Quality Gates» Руководства администратора. При первой проверке безопасности все проблемы получают состояние NEW, Quality Gate определяет наличие недопустимого количества проблем безопасности, о чем система информирует Инженера ИБ. Однако при последующих сканированиях найденные ранее проблемы безопасности изменяют состояние на REPEATED и настроенный указанным выше способом Quality Gate не срабатывает, что может привести к выпуску в промышленную эксплуатацию приложения, имеющего неустраненные уязвимости. Чтобы исключить описанную ситуацию, необходимо либо более тщательно подходить к определению критериев качества (Quality Gate), либо, при необходимости, использовать предусмотренную в системе возможность настройки алгоритма изменения состояний проблем безопасности.

При настройке Security Pipeline пользователь с ролью Менеджер может выбрать одну из трех настроек (поле Issue state policy на вкладке Settings). Более подробная информация о настройках Security Pipeline приведена в разделе «Security Pipelines».

Compare with the 1st scan — определять состояние обнаруживаемых проблем безопасности в сравнении с результатами первого сканирования (стандартная настройка системы).
Compare with previous scan — определять состояние обнаруживаемых проблем безопасности в сравнении с результатами предыдущего сканирования.
Compare with the custom — определять состояние обнаруживаемых проблем безопасности в сравнении с результатами произвольного успешного сканирования. При выборе этого варианта на вкладке Settings настроек Security Pipelines появляется дополнительное поле Issue state policy scan task, в котором необходимо указать соответствующее сканирование.

Примечание

Для сравнения не могут использоваться сканирования, завершившиеся с ошибкой (статус FAILED), за исключением получивших такой статус в результате непрохождения Quality Gate.

Присвоение проблеме безопасности статуса False positive

Чтобы исключить необходимость обработки проблем безопасности, которые являются результатом ложных срабатываний инструментов, Инженер ИБ может присвоить им статус False positive, указывающий на то, что проблема безопасности является ложноположительной. Такой подход позволят не учитывать соответствующие проблемы безопасности при расчете Quality Gates.

Примечание

Статус False positive может быть присвоен только проблемам безопасности, находящимся в статусе To verify.

Статус False positive может быть присвоен проблеме безопасности двумя различными способами:

Одной отдельно взятой проблеме безопасности без создания в системе правила для всех подобных проблем в приложении (см. раздел «Присвоение проблеме безопасности статуса False positive без создания правила»).
Проблеме безопасности с одновременным созданием в системе правила, работающего для всех подобных проблем в рамках текущего приложения (см. раздел «Присвоение проблеме безопасности статуса False positive с созданием правила»).

Примечание

При импорте из инструментов сканирования проблемы безопасности могут иметь статус False positive. Так, при импорте из Application Inspector уязвимости, отмеченные в инструменте меткой IsSuppressed, будут иметь в AppSec.Hub статус False positive.

Присвоение проблеме безопасности статуса False positive без создания правила

Чтобы присвоить одной проблеме безопасности статус False positive без создания правила в системе, перейдите на страницу с детальной информацией о соответствующей проблеме, нажав ее идентификатор на странице Issues.

Нажмите кнопку Actions .

В раскрывающемся меню выберите пункт False positive.

В открывшемся окне Issue status change в поле Choose expiration date укажите срок, на который проблеме присваивается статус False positive, и добавьте комментарий в поле Add comment.

Нажмите кнопку Confirm. Проблема безопасности получит статус False positive.

Примечание

Проблемы безопасности, которым был присвоен статус False positive указанным выше способом, не будут менять свой статус в случае, если для них извне системы пришел новый отличный от False positive статус, например, в результате импорта проблем безопасности из инструмента сканирования.

Примечание

Присвоенный статус False Positive автоматически отменяется при создании дефекта с соответствующей проблемой безопасности, а также если она не обнаруживается в новом сканировании. Если при последующих сканированиях проблема безопасности будет обнаружена вновь, необходимо повторить присвоение статуса.

Кроме этого, в правом нижнем углу страницы с подробной информацией об уязвимости на вкладке Details появится карточка False positive recognized, содержащая сведения о статусе False positive.

В карточке False positive recognized содержится следующая информация:

FP Status — запись о присвоении статуса False positive одной отдельно взятой проблеме безопасности (Single issue acceptance).
FP accepted by — имя пользователя, присвоившего проблеме статус False positive.
Set as FP — время присвоения проблеме статуса False positive.
Expiration date — срок, до которого проблеме присвоен статус False positive (дата и время).
Vulnerability type — тип проблемы безопасности.
Comments — комментарии Инженера ИБ.

После того как проблеме безопасности был присвоен статус False positive указанным выше способом, при необходимости ее можно перевести обратно в статус To verify.

Для этого нажмите кнопку Actions и в раскрывающемся меню выберите пункт To verify. Обратите внимание, что остальные пункты раскрывающегося меню в этот момент не доступны.

Проблема безопасности получит статус To verify. После этого она снова может поменять свой статус в случае, если для нее извне системы пришел новый отличный от False positive статус, например, в результате импорта проблем безопасности из инструмента сканирования.

Кроме этого, в правом нижнем углу страницы с подробной информацией об уязвимости (вкладка Details) исчезнет карточка False positive recognized.

Присвоение проблеме безопасности статуса False Positive с созданием правила

Одновременно с присвоением проблеме безопасности данного статуса в системе может быть создано соответствующее правило, которое работает только в рамках текущего приложения. В дальнейшем, если среди импортируемых проблем безопасности будут встречаться те, на которые распространяется созданное правило, они будут автоматически получать статус False positive.

Примечание

В настоящее время реализована возможность присвоения статуса False positive проблемам безопасности типа SAST, DAST, SCA Security и SCA Compliance.

Чтобы присвоить проблеме безопасности статус False positive и создать правило в системе, перейдите на страницу с детальной информацией о соответствующей проблеме, нажав ее идентификатор на странице Issues.

Нажмите на кнопку Actions .

В раскрывающемся меню выберите пункт Create rule.

Существует альтернативный способ присвоить проблеме безопасности статус False positive. Для этого необходимо на странице Issues справа в конце строки выбранной проблемы безопасности в выпадающем меню «» выбрать пункт Create rule.

В открывшемся окне Issue processing rule, полное название которого включает в себя тип проблемы безопасности, заполните или отредактируйте необходимые поля. Набор параметров, представленных в виде полей в разделе Issue properties в этом окне, зависит от типа проблемы безопасности. Часть полей данного окна будет заполнена автоматически на основе информации, полученной из инструмента AST.

В разделе Rule properties представлены следующие параметры:

Target status — устанавливаемый статус.
Expiration date — срок действия создаваемого правила. При наступлении указанной даты статус уязвимости изменится с False positive на To verify.
Comment — комментарии Инженера ИБ с указанием причины присвоения статуса False positive.

В разделе Issue properties для проблем безопасности типов SCA Security и SCA Compliance представлены следующие параметры:

Category — категория проблемы безопасности.

Примечание

Для проблем безопасности типа SCA Security поддерживается категория All с необязательным заполнением полей Component name и Component version. Для проблем безопасности типа SCA Compliance при указании категории All заполнение полей Component name и Component version является обязательным.

Примечание

Категории уязвимостей подгружаются из соответствующего инструмента. Более подробная информация приведена в разделе «Категории уязвимостей» Руководства администратора.
Component group — группа компонента, содержащего проблему безопасности.
Component name — наименование компонента, содержащего проблему безопасности.
Component version — версия компонента, содержащего проблему безопасности.

Примечание

В полях Component group, Component name, Component version можно использовать символ «*» в качестве универсального знака, заменяющего один или несколько символов. Например, если в поле Component name указать log*, будет создано правило для всех компонентов, начинающихся с log.

Примечание

Для уязвимостей категории Component-Unknown поля Component name и Component version не являются обязательными для заполнения.
CVE — идентификатор уязвимости в базе данных общеизвестных уязвимостей информационной безопасности, также в данном поле можно указать CVE в формате, предлагаемом компаниями Sonatype, GitHub и OSS. Если поле пустое, добавляются все CVE для данной компоненты.

Указание объектов сканирования, для которых будет применяться создаваемое правило по отношению к найденным в них проблемам безопасности, можно произвести в следующих полях:

Codebase name — имя кодовой базы.
Artifact name — имя артефакта.
Repository proxy name — имя прокси-репозитория.
Structure unit — имя структурной единицы.

В разделе Issue properties для проблем безопасности типа SAST представлены следующие отличные от уже описанных выше параметры:

Path — путь к файлу, содержащему проблему безопасности. Таких путей может быть несколько для одной проблемы.
Source code — фрагмент исходного кода, содержащий проблему. Таких фрагментов может быть несколько для одной проблемы.
Scope — в этом поле можно выбрать из выпадающего списка одно из трех значений: SOURCE (источник проблемы — первая строка в цепочке вхождений), TARGET (целевая последняя строка в цепочке вхождений), ANY (используется при поиске всех значений).
Language — в этом поле можно указать язык программирования, для которого применимо это правило.

В разделе Issue properties для проблем безопасности типа DAST представлены следующие отличные от уже описанных выше параметры:

Category — категория проблемы безопасности. В отличие от других типов проблем безопасности, для DAST это поле не предлагает список для выбора. Оно является полем для ввода значения в свободном формате.
URL — адрес источника проблемы безопасности.
Instance name — имя экземпляра приложения, для которого будет применяться создаваемое правило по отношению к найденным в них проблемам безопасности.

Нажмите кнопку Create.

В случае успешного создания правила в правом нижнем углу интерфейса пользователя появляется подтверждающее сообщение.

Кроме этого, в правом нижнем углу страницы с подробной информацией о соответствующей уязвимости (вкладка Details) появится карточка Risk recognized, содержащая сведения о созданном правиле.

В карточке Risk recognized содержится следующая информация:

FP Rule — номер правила в системе.
Date of recognition — дата и время создания правила.
Expiration date — срок действия правила (дата и время).
Vulnerability type — тип проблемы безопасности.
Category — категория (-ии) уязвимости (-ей).
Component group — группа компонента.
Component name — наименование компонента.
Component version — версия компонента.
Comments — комментарии Инженера ИБ.

Правила обработки проблем безопасности

Информация о всех созданных для приложения правилах обработки проблем безопасности добавляется на страницу Rules.

На данной странице приводится следующая информация о правилах для проблем безопасности всех типов:

# — идентификационный номер правила в системе.
В случае, если правило в данный момент не распространяется на какие-либо проблемы безопасности в приложении, рядом с идентификационным номером располагается значок OBSOLETE. Если это правило применено к каким-либо проблемам безопасности, значок OBSOLETE отсутствует.
Rule type — тип правила.
Issue type — тип проблемы безопасности.
Category — выбранная категория (-ии).
Created — дата создания правила.
Expiry date — срок действия правила.

Также на странице приведены дополнительные параметры для каждой проблемы безопасности в зависимости от ее типа (SAST, DAST, SCA Security и SCA Compliance).

Нажмите идентификационный номер правила в системе #, чтобы перейти на страницу с детальным описанием правила.

На вкладке Description здесь представлена вся доступная информация об этом правиле, состав параметров которой зависит от типа проблемы безопасности, а на вкладке Related issues — все проблемы безопасности, к которым это правило применено. В случае, если правило помечено значком OBSOLETE, вкладка Related issues не будет содержать ни одной проблемы безопасности. Также на этой вкладке можно просмотреть категорию проблемы безопасности.

Новое правило может быть создано непосредственно на странице Rules.Нажмите кнопку +Add new и выберите тип создаваемого правила в выпадающем меню.

Примечание

Для создания нового правила требуется роль Инженер ИБ, иначе кнопка +Add new будет находиться в неактивном состоянии.

В появившемся окне Issue processing rule необходимо заполнить/отредактировать поля аналогично тому, как описано выше.

Примечание

В AppSec.Hub запрещено создавать одинаковые правила, а также правила с несуществующими объектами.

Примечание

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

Однако если при следующем сканировании эта же уязвимость будет обнаружена вновь, то при импорте в AppSec.Hub она снова получит статус, например, False Positive.

Другими словами, статус, задаваемый правилом в AppSec.Hub, имеет более высокий приоритет, чем статус инструмента.

В системе предусмотрена возможность фильтрации правил по нескольким параметрам. Чтобы настроить правила фильтрации, нажмите кнопку Show filters в правом верхнем углу страницы.

Правила можно фильтровать по следующим параметрам:

by Issue type — по типу проблем безопасности (SAST, DAST, SCA Security, SCA Compliance).
by Category — по категории проблем безопасности. Для проблем типа SAST, SCA Security и SCA Compliance в этом поле предоставляется выбор из выпадающего списка. Для проблем типа DAST это поле предназначено для ввода значения в свободном формате.
by Expiration Date — по сроку действия правила.
by Codebase — по кодовой базе.
by Artifact — по артефакту.
by Instance — по экземпляру приложения.
by Proxy Repository — по прокси-репозиторию.
by Structure unit — по структурной единице.

Удаление правил

Если необходимо удалить правило, перейдите на страницу Rules и нажмите расположенную справа от него иконку Cancel rule .

В появившемся диалоговом окне Cancel issue processing rule нажмите кнопку Submit, чтобы отменить правило. Если выбрана опция Change the Status of the all Issue covered by this Rule to To Verify, статус всех проблем безопасности, которым в соответствии с данным правилом был присвоен статус False positive, будет изменен на To Verify, в противном случае — останется без изменений.

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

Примечание

Аналогично правило может быть удалено на вкладке Rules страницы Risk Acceptance соответствующего приложения.

Экспорт проблем безопасности в файл

Предусмотрена возможность скачивания отчета о выбранных проблемах безопасности в файлы формата XLSX или PDF. Кроме этого, можно скачать ZIP-архив, который объединяет XLSX-отчет с описанием уязвимостей в формате HTML.

Примечание

Если к перечню Security Issues были применены какие-либо фильтры, они учитываются при формировании отчета. Например, если необходимо сформировать отчет, содержащий Security Issues в порядке убывания степени их серьезности, применим фильтр Severity: High to Low и сгенерируем отчет.

Перейдите на страницу Issues, нажмите на кнопку Actions в правом верхнем углу и в выпадающем меню выберите пункт Export all issues.

В раскрывающемся меню выберите необходимый формат (XLSX, PDF или ZIP). В правом нижнем углу пользовательского интерфейса появится подтверждающее сообщение и, спустя несколько секунд, начнется скачивание файла отчета в выбранном формате.

Не останавливаясь подробно на структуре отчетов, отметим, что в них, помимо прочего, реализовано отображение ссылок на уязвимости, обнаруженные продуктами Sonatype (CVE id), а также безопасных версий библиотек (Non-vulnerable versions).

При нажатии на идентификатор уязвимости в XLSX-отчете происходит переход на страницу описания соответствующей уязвимости в AppSec.Hub или, если выбран отчет в формате ZIP, открывается скачанная HTML-страница с аналогичным описанием.