Перейти к содержанию

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

Примечание

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

Каждый инструмент AST в рамках работы пайплайна создает отчет по безопасности во время каждого запуска сканирования безопасности. Отчет по безопасности содержит список проблем безопасности (уязвимостей, security issues), обнаруженных в ходе сканирования. Их следует проанализировать и обработать. Это задачу выполняет Инженер ИБ.

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

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

Вся информация о проблемах безопасности импортируется в AppSec.Hub из инструментов AST. Описание уязвимости обновляется при каждом импорте из инструмента AST или сканировании и, таким образом, является актуальным на момент последнего импорта или сканирования.

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

  • ISSUE DETAILS — краткое описание проблемы. Данное поле может включать следующую информацию в зависимости от типа проблемы:

    • # — идентификатор проблемы в системе и ее заголовок.
    • State — состояние проблемы безопасности (New, Repeated). Настройки алгоритма изменения состояний проблем безопасности можно задать на уровне пайплайна (поле Issue state policy на вкладке Settings, см. детали в разделе «Настройки пайплайна») и/или на уровне приложения (поле Issue state policy на вкладке General, см. детали в разделе «Настройки приложения»).
    • 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 указывает на максимальную опасность.
    • AI status — статус проблемы безопасности на основе предиктивной модели анализа уязвимостей приложения (True Positive/False Positive).
    • AI Accuracy — точность оценки модели анализа уязвимостей приложения.
    • AI Model — используемая модель анализа.
  • SEVERITY — серьезность проблемы в инструменте AST (Low, Medium, High или Critical).

  • STATUS — статус проблемы в системе:

    • To Verify - начальный статус уязвимости в системе, требующий дальнейшей проверки.
    • Confirmed - статус, отражающий, что уязвимость подтверждена.
    • Open - статус, отражающий, что уязвимость подтверждена и для нее заведен дефект.
    • Fixed - статус, отражающий, что ранее найденная уязвимость исправлена и более не обнаруживается при сканировании.
    • Accepted risk - статус исключения, отражающий принятие риска (доступно условное и безусловное принятие риска).
    • False Positive - статус исключения, отражающий ложное срабатывание.
  • DEFECT — ссылка на дефект безопасности, к которому привязана уязвимость (если он существует).

  • BRANCH — ветка, на которой найдена проблема безопасности.

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

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

Для получения детальной информации выберите справа в конце строки проблемы безопасности в выпадающем меню «» пункт Details.

Примечание

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

На экране появится окно с подробной информацией о проблеме безопасности, содержащее несколько вкладок и справа - ее параметры (метаданные).

Метаданные проблемы безопасности включают следующие ее характеристики (если применимо):

  • Type — тип.
  • Status — статус.
  • State — состояние.
  • Severity — серьезность.
  • Found by — каким инструментом сканирования обнаружена уязвимость. Нажмите на ссылку для перехода на страницу авторизации данного инструмента.
  • Category — категория.
  • Threat group — группа угроз, например, Copyleft.
  • CWE ID.
  • CVE.
  • CVSS score — оценка CVSS.
  • Language — язык программирования.
  • Codebase — кодовая база.
  • Artifact — артефакт.
  • Instance — экземпляр приложения.
  • Release object — релизный объект.
  • Defect — дефект.
  • Fixed Version — исправленная версия.
  • Created — дата создания.
  • Updated — дата обновления.
  • Relation — зависимость (прямая/транзитивная).
  • Envs — окружения.
  • Tree link — ссылка на дерево проекта в инструменте сканирования.
  • Publish date — дата публикации.
  • Update date — дата обновления.
  • Has exploit — наличие эксплойта.

Для кодовых баз в верхней части окна дополнительно отображается поле Branches with this issue. В нем можно выбрать ветку, для которой будет отображаться информация о статусе и о времени обнаружения проблемы безопасности.

  • Details — подробная информация о проблеме с указанием потенциальной опасности, причины ее возникновения, а также рекомендаций по устранению. Для проблем безопасности, обнаруженных в ходе сканирования, привязанного к релизному объекту, приводится дополнительная ссылка на релизный объект. Кроме того, в полях AI Status и AI Accuracy приведены результаты анализа уязвимостей приложения, см. раздел «Обработка уязвимостей приложения» Руководства администратора.

  • Path — информация, позволяющая локализовать источник проблемы.

    Для проблем безопасности типа SAST система отображает и подсвечивает строку или участок строки исходного кода, ставший причиной уязвимости.

    Система предоставляет возможность навигации по исходному коду:

    • Для проблем безопасности SAST, полученных при сканировании кодовой базы в GitHub/GitLab/Bitbucket, при выборе пункта Repository storage в меню Open file in - в файле исходного кода из этой кодовой базы.

    • Для проблем безопасности SAST, полученных при сканировании кодовой базы в GitLab, при выборе пункта Repository Web IDE в меню Open file in - в Web IDE инструмента GitLab.

    • Для проблем безопасности SAST из PT Application Inspector, при выборе пункта Scan Tool Web IDE в меню Open file in - в Web IDE инструмента PT Application Inspector.

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

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

    Примечание

    Во избежание проблем с производительностью файлы объемом более 8 Мб не загружаются в AppSec.Hub.

  • Status history — история сканирования проблемы безопасности. Эта вкладка содержит информацию о каждом случае обнаружения проблемы во время выполненных проверок безопасности, а также на ней можно проследить историю изменения статусов уязвимости (поля Old Status и New status). Обновление статуса отображается только в случае его действительного изменения — если, например, было проведено сканирование, но статус уязвимости не изменился, обновляется только дата. Поле Scan Task Id автоматически заполняется по результатам проведенного сканирования, а при нажатии на эту ссылку происходит переход на страницу с детальной информацией об этом сканировании. В поле Author отображается имя автора изменения статуса уязвимости, но только для изменений, выполненных вручную через пользовательский интерфейс системы в версиях AppSec.Hub не ниже 2023.4.2.

  • Severity history — история изменения серьезности проблемы безопасности. Отображаются дата, старое и новое значение, идентификаторы задач импорта и сканирования, комментарий и автор изменения.

  • State history — история изменения состояний проблемы безопасности. Помимо даты, времени и идентификатора сканирования на вкладке отображается состояние проблемы безопасности (New, Repeated), выбранный алгоритм изменения состояния (ISSUE STATE POLICY), а также идентификатор сканирования, с результатами которого осуществлялось сравнение (REGARDING THE SCAN TASK).

    Для проблем безопасности, найденных при сканировании кодовых баз, на вкладке Status history дополнительно отображается колонка Target branch. Информация в ней позволяет определить состояние проблемы безопасности в целевой ветке относительно ветки, выбранной в поле Branches with this issue.

  • Branches — список ветвей, их актуальный статус в каждой ветке и время последнего проявления проблемы безопасности в этой ветви. Эта вкладка присутствует только для проблем безопасности кодовых баз.

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

  • Comments и Recommendation — обеспечивают возможность добавления соответственно комментариев и рекомендаций. Они будут сохранены после нажатия кнопок Send на вкладке Comments или Save на вкладке Recommendation. Если в дальнейшем будут обнаружены похожие проблемы безопасности, все сохраненные рекомендации будут автоматически добавлены к ним. Эта функциональность реализована в AppSec.Hub на основе анализа корреляции проблем.

Фильтрация проблем безопасности

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

В системе реализованы три настраиваемых режима фильтрации:

  • Фильтрация с использованием свойств проблем безопасности Issue properties.
  • Фильтрация с использованием связанных сущностей Linked entities.
  • Фильтрация с использованием данных AI Provider.

Фильтрация по свойствам

Выбрав справа в поле 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 request for change status — по запросу на смену статуса (With request, Without request, My requests).
  • by state — по состоянию (NEW, REPEATED).
  • by tool — по инструменту, с помощью которого обнаружена уязвимость.
  • by severity — по серьезности (Low, Medium, High и Critical).
  • by language — по языку (применимо только для проблем безопасности типа SAST).
  • by source — по источнику.
  • by category — по категории.
  • by branch (if empty, the default branch is used) — по ветке (если проблема безопасности хотя бы один раз была найдена в указанной ветке, то она войдет в результаты фильтрации).
  • by CWE ID — по CWE ID.
  • by CVE ID — по CVE ID.
  • by relation — по зависимости (прямая/транзитивная).
  • by exploit — по наличию эксплойта.
  • by scan ID — по ID сканирования.
  • updated in — по дате последнего обновления (Last week, Last month, Last 3 months, Last 6 months, Last year, Last 2 years и Last 3 years).

Фильтрация по связанным сущностям

Выберите вариант фильтрации 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 codebase, by artifact, by instance и by structure unit отображаются первые десять объектов. При поиске объекта в этих полях необходимо ввести не менее трех символов.

Фильтрация по AI Provider

Выберите вариант фильтрации AI Provider, чтобы отсортировать проблемы безопасности с использованием результатов анализа уязвимостей приложения:

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

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

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

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

  • По группам корреляции.
  • По типу (SAST, DAST, SCA Security, SCA Compliance).
  • По источнику уязвимостей.

Для группировки проблем безопасности нажмите на кнопку Show filters в правом верхнем углу, в поле фильтрации выберите вкладку Grouping, а затем в поле group by выберите значение из выпадающего списка (Correlation, Type, Source).

Группы проблем безопасности будут показаны в порядке убывания количества входящих в них проблем безопасности.

Рассмотрим более подробно работу с группами проблем безопасности на примере групп корреляции.

Применение правил корреляции для группировки проблем безопасности осуществляется при включенном селекторе Apply correlation rules by default на вкладке Correlation в разделе Issue processing на странице администрирования системы (см. детали в разделе «Обработка уязвимостей приложения»).

Для работы с группами корреляции проблем безопасности, нажмите кнопку Show filters в правом верхнем углу страницы, в поле фильтрации выберите вкладку Grouping, затем в поле group by выберите из выпадающего списка значение Correlation, а в поле by group - группу корреляции.

В списке проблем безопасности отобразятся сформированные группы, а в области фильтрации появятся дополнительные поля, являющиеся параметрами выбранной группы корреляции для проблем безопасности соответствующего типа (SAST, DAST, SCA Security & component version, SCA Security & fix version).

Примечание

Корреляция для проблем безопасности SCA Compliance в системе не рассчитывается.

С помощью поля sort by можно отсортировать сформированные группы по значению взвешенного индекса риска (при выборе параметра by WRI) или по количеству проблем безопасности в группе (при выборе параметра by total issues count). С помощью остальных полей можно произвести дополнительную фильтрацию сформированных групп.

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

  • # — идентификатор группы.
  • Total issues — количество проблем безопасности, входящих в группу.
  • WRI (Weighted Risk Index) — взвешенный риск-индекс для данной группы. При расчете WRI для групп корреляции учитываются веса уязвимостей, находящихся в статусе To verify, Open и Confirmed. Веса уязвимостей, находящихся в статусе False Positive, Accepted risk и Fixed, не учитываются.
  • CWE и Path — для группы проблем безопасности SAST в этих полях указываются значения параметров для правила корреляции. Для проблем безопасности других типов вместо них будут указаны другие параметры и их значения (для DAST - CWE и URL, для SCA Security & component version - Scan target, Component name и Component version, для SCA Security & fix version - Scan target, Component name и Fix version).
  • No groups — это поле отображается для тех проблем, которые в результате формирования групп корреляции не вошли ни в одну из групп. У таких проблем нет общих значений параметров, что отображается в поле Params: N/A.

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

Примечание

При группировке проблем безопасности по типу и по источнику уязвимостей выпадающее меню «» отсутствует.

Примечание

Если с одной или несколькими проблемами безопасности после формирования группы были проведены какие-либо действия, например, по ручному изменению статуса с To verify на False positive, то массовая операция, например, изменение статуса у входящих в группу проблем безопасности с To verify на Confirmed, будет проведена только с теми проблемами в группе, к которым она применима на момент проведения этой операции, при этом присвоенный ранее отдельным проблемам статус False positive не будет изменен.

Это замечание применимо не только к ручному изменению статуса проблем безопасности, но также к таким массовым операциям, как Create defect и Link to defect.

Переключить режим отображения проблем безопасности можно с помощью кнопок Plain issues list (список проблем безопасности) и Grouping (список групп).

При нажатии на идентификатор группы # информация о всех входящих в группу проблемах безопасности будет отображена в виде списка в правой части окна. Существует возможность проводить операции по одновременному изменению статуса входящих в группу проблем безопасности, расположенных в этом списке в столбце ISSUE DETAILS (см. раздел «Изменение статуса всех проблем безопасности»).

Этот список можно закрыть, нажав на значок «» в правом верхнем углу.

Кроме того, для работы с группами проблем безопасности можно выполнить следующие шаги:

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

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

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

Обратите внимание, что вкладка Groups содержит выпадающее меню «», с помощью которого также можно выполнять действия с группой. Данный путь к группам корреляции позволяет увидеть уязвимости, которые похожи на рассматриваемую и позволяет сократить время разбора подобных уязвимостей.

Нажмите на идентификатор группы на вкладке Groups.

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

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

Для выполнения действий с проблемами безопасности:

  • Нажимая на значки , выберите из списка одну или несколько уязвимостей. Выбранные уязвимости будут отмечены значком . На кнопке Actions справа вверху будет отображаться количество выбранных проблем безопасности.
  • Нажмите на кнопку Actions и выберите пункт выпадающего меню. Доступность пунктов выпадающего меню зависит от статуса выбранной уязвимости (-ей).

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

Справа в конце строки каждой уязвимости представлено выпадающее меню «», предназначенное для выполнения действий только с данной проблемой безопасности.

Список действий:

  • Create defect — этот пункт используется для создания дефекта на основе проблемы безопасности.

  • Link to defect / Unlink from defect — с помощью этого пункта, в зависимости от текущего статуса проблемы безопасности, можно или привязать ее к существующему дефекту безопасности, или открепить ее от существующего дефекта, см. раздел «Привязка/отвязка уязвимости от дефекта».

  • Accept risk — этот пункт используется для смены статуса вручную и принятия риска путем добавления уязвимости, имеющей статус To verify, в исключения, см. разделы «Смена статуса вручную» и «Accepted risk». Присвоение уязвимости статуса Accepted risk позволяет не учитывать ее при расчете Quality Gates.

  • False Positive — этот пункт используется для смены статуса вручную. С помощью этого пункта можно отмечать проблемы безопасности, имеющие статус To verify, как ложные срабатывания, см. разделы «Смена статуса вручную» и «False Positive». Присвоение уязвимости статуса False Positive позволяет не учитывать ее при расчете Quality Gates.

  • Confirm — этот пункт используется для смены статуса вручную. С помощью этого пункта можно подтверждать проблемы безопасности, имеющие статус To verify, см. разделы «Смена статуса вручную» и «Confirmed».

  • To verify — этот пункт используется для смены статуса вручную. С помощью этого пункта можно перевести в статус To verify проблему безопасности, находящуюся в статусе False positive, Accepted risk или Confirmed, см. разделы «Смена статуса вручную» и «To verify».

  • Create rule — этот пункт используется для присвоения проблеме безопасности статуса False positive, Accepted risk или Confirmed одновременно с созданием в системе соответствующего правила для текущего приложения, см. раздел «Смена статуса с созданием правила».

  • Change severity — этот пункт используется для управления серьезностью проблемы безопасности.

  • Import all issues — этот пункт используется для импорта уязвимостей из инструментов сканирования, см. раздел «Импорт проблем безопасности».

  • Import from report — этот пункт используется для импорта отчетов о проблемах безопасности.

  • Generate report — этот пункт используется для экспорта проблем безопасности в различных форматах.

Смена статуса вручную

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

Присвоенный проблеме безопасности вручную или в результате применения правила статус Accepted risk/False positive/Confirmed автоматически отменяется при создании дефекта с этой проблемой безопасности или при привязке данной проблемы к существующему дефекту, а также если она не обнаруживается в новом сканировании.

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

Страница информации об уязвимости, которой был вручную присвоен статус Accepted risk/False positive/Confirmed, справа в разделе метаданных содержит дополнительный блок со следующими полями:

  • Date applied — время присвоения проблеме статуса.
  • Expiration date — срок, до которого проблеме присвоен статус (дата и время).
  • Acceptor — имя пользователя, присвоившего проблеме статус.
  • Comments — комментарии Инженера ИБ.

Accepted risk

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

Примечание

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

Присвоение проблеме безопасности статуса Accepted risk позволяет не учитывать ее при расчете критериев качества (Quality Gates).

В системе реализованы два типа механизмов принятия рисков: безусловный и условный.

В случае безусловного принятия риска Инженер ИБ безоговорочно допускает наличие определенной уязвимости и присваивает ей статус Accepted risk.

Чтобы присвоить проблеме безопасности статус Accepted risk:

  • На странице Issues в строке выбранной проблемы безопасности в выпадающем меню «» выберите пункт Accept risk.
  • Или перейдите на страницу с детальной информацией о соответствующей проблеме, нажав ее идентификатор на странице Issues. Нажмите на кнопку Actions и в раскрывающемся меню выберите пункт Accept risk.

В появившемся окне Risk acceptance for issue достаточно указать причину в поле Comment и нажать на кнопку Accept risk. При необходимости можно указать срок принятия риска в поле Risk expiration Date. Если срок не указан, риск будет принят на постоянной основе — без ограничений по времени.

Для проблем безопасности типов SCA Security и SCA Compliance в окне Risk acceptance for issue дополнительно представлен флажок Apply to all similar issues. Если он установлен, при нажатии на кнопку Accept risk, в рамках текущего приложения будет создано новое правило для всех проблем безопасности, подобных выбранной (имеющих те же категорию, группу, имя и версию компонента). В результате для всех подобных уязвимостей будет произведено безусловное принятие риска.

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

В случае условного принятия риска риск принимается с определенным условием — он считается допустимым и наличие уязвимости не учитывается при расчете QG, но только до тех пор, пока выполняется определенное условие (правило) — в исходном коде не найдено ни одной уязвимости, обусловленной данным правилом (см. раздел «Категории уязвимостей»).

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

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

Условное принятие риска доступно только для SCA Security уязвимостей. Оно выполняется аналогично безусловному, с той разницей, что в окне Risk acceptance for issue необходимо в поле SAST issue category выбрать значение из выпадающего списка. В этом поле отображаются только SAST-категории, подгружаемые из соответствующих инструментов.

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

False positive

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

Примечание

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

Присвоение проблеме безопасности статуса False positive позволяет не учитывать ее при расчете критериев качества (Quality Gates).

Примечание

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

Чтобы присвоить проблеме безопасности статус False positive:

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

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

Для проблем безопасности типов SCA Security и SCA Compliance в окне Issue status change дополнительно представлен флажок Apply to all similar issues. Если он установлен, при нажатии на кнопку Confirm, в рамках текущего приложения будет создано новое правило для всех проблем безопасности, подобных выбранной (имеющих те же категорию, группу, имя и версию компонента). В результате все подобные уязвимости получат статус False positive.

Confirmed

Чтобы подтвердить проблемы безопасности, Инженер ИБ может присвоить им статус Confirmed.

Примечание

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

Подтвержденные уязвимости, имеющие статус Confirmed, подлежат учету при расчете критериев качества (Quality Gates).

Чтобы присвоить проблеме безопасности статус Confirmed:

  • На странице Issues в строке выбранной проблемы безопасности в выпадающем меню «» выберите пункт Confirm.
  • Или перейдите на страницу с детальной информацией о соответствующей проблеме, нажав ее идентификатор на странице Issues. Нажмите на кнопку Actions и в раскрывающемся меню выберите пункт Confirm.

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

To verify

Проблеме безопасности, которой был вручную присвоен статус Accepted risk/False positive/Confirmed, при необходимости можно вернуть статус To verify.

Для этого:

  • На странице Issues в строке выбранной проблемы безопасности в выпадающем меню «» выберите пункт To verify.
  • Или перейдите на страницу с детальной информацией о соответствующей проблеме, нажав ее идентификатор на странице Issues. Нажмите на кнопку Actions и в раскрывающемся меню выберите пункт To verify.

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

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

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

Существует возможность провести операцию по одновременному изменению статуса всех проблем безопасности, доступных на странице Issues (с учетом установленных на ней фильтров).

Для этого необходимо нажать на значок , расположенный слева от заголовка столбца ISSUE DETAILS. В результате будут выбраны проблемы безопасности, отображенные в данный момент на странице Issues. Также можно выбрать не только отображенные на текущей странице уязвимости, но вообще все доступные проблемы безопасности (с учетом установленных на странице Issues фильтров), нажав на кнопку Select all records в появившемся модальном окне.

Когда выбор проблем безопасности завершен, нажмите на кнопку Actions и выберите необходимый пункт в выпадающем меню, чтобы провести операцию со всеми выбранными проблемами безопасности.

Все проблемы безопасности в сформированном запросе, для которых возможно провести выбранную операцию, например, изменить статус на указанный в выпадающем меню, будут обработаны согласно запросу. Проблемы безопасности, для которых выбранная операция неприменима по каким-либо причинам, останутся без изменений. Например, при выборе всех проблем безопасности, нажатии на кнопку Actions и выбора пункта меню Confirm, статус Confirmed получат уязвимости, находившиеся в статусе To verify, а уязвимости со статусом False positive и Acceped risk сохранят свое состояние.

Смена статуса с созданием правила

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

Чтобы присвоить проблеме безопасности статус Accepted risk/False positive/Confirmed и создать правило в системе:

  • На странице Issues в строке выбранной проблемы безопасности в выпадающем меню «» выберите пункт Create rule.
  • Или перейдите на страницу с детальной информацией о соответствующей проблеме, нажав ее идентификатор на странице Issues. Нажмите на кнопку Actions и в раскрывающемся меню выберите пункт Create rule.

В открывшемся окне Create a vulnerability processing rule с предзаполненными полями дозаполните или отредактируйте необходимые поля. В поле Select rule type укажите тип создаваемого правила Accepted risk/False positive/Confirmed (см. детали в разделе «Правила обработки проблем безопасности»).

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

Создание запроса

Примечание

Для создания запроса на смену статуса проблемы безопасности требуется роль Разработчик (Developer).

Пользователь с ролью Разработчик (Developer) не может самостоятельно изменить статус проблемы безопасности, но может создать запрос на это действие.

Для этого необходимо на странице Issues в строке выбранной проблемы безопасности или на странице с подробной информацией о ней в меню действий «» выбрать один из пунктов меню с целевым статусом: Accept risk (request), False Positive (request), Confirm (request), To verify (request).

При этом необходимо учитывать следующее:

  1. Пункт меню с текущим статусом проблемы безопасности будет недоступен.
  2. Если уязвимость была импортирована в статусе, отличном от To Verify, то изменять статус у такой уязвимости нельзя.
  3. Создавать запросы на смену статуса (и менять статус уязвимости) можно без триажных ограничений. Ранее уязвимость, импортированная в AppSec.Hub в статусе To verify, могла быть переведена в один из трех статусов - Accepted risk, False Positive, Confirmed, а затем возвращена обратно в статус To verify. На переходы между триажными статусами Accepted risk, False Positive и Confirmed были наложены ограничения. Теперь эти ограничения при смене статуса уязвимости сняты.

Примечание

Если у пользователя есть права на изменение статуса уязвимости, создавать запрос ему не нужно и пункты меню будут отображаться как Accept risk, False Positive, Confirm, To verify без слова (request).

После нажатия на пункт меню с целевым статусом, в появившемся окне Requesting issue status change необходимо указать параметры запроса:

  • Comment - комментарий к запросу (обязательный параметр).
  • Expiration date - срок, до которого проблеме присваивается целевой статус.
  • Если создается запрос для уязвимости типа SCA Security на статус Accepted risk, в дополнительном поле Conditional risk acceptance можно выбрать категорию уязвимости SAST для условного принятия риска.

и нажать на кнопку Confirm.

Групповая смена статуса

Существует возможность создания запроса для нескольких проблем безопасности одновременно. Для этого выберите проблемы безопасности из списка на странице Issues, нажмите на кнопку Actions и выберите пункт меню с целевым статусом.

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

  1. Массовые действия доступны только для уязвимостей с одинаковым статусом.
  2. Пункт меню с текущим статусом проблем безопасности будет недоступен.
  3. Если уязвимость была импортирована в статусе, отличном от To Verify, то изменять статус у такой уязвимости нельзя. При этом групповая смена статуса будет выполнена, но только для тех уязвимостей, которые были импортированы в статусе To Verify.
  4. Менять статус уязвимостей (и создавать запросы на групповую смену статуса) можно без триажных ограничений, как и при действиях с одной уязвимостью.

Примечание

При установленном на странице Issues флаге Select all records подача запроса на смену статуса недоступна.

Отображение и принятие решения по запросу

Для пользователя с ролью Разработчик (Developer)

Запрашиваемый статус уязвимости отображается как странице Issues в строке проблемы безопасности в столбце Status, так и на странице с подробной информацией об уязвимости в панели Requested issue status change:

Уже созданный запрос можно отменить, нажав на кнопку Cancel панели Requested issue status change на странице с подробной информацией об уязвимости, или выбрав пункт меню Cancel request в строке уязвимости на странице Issues.

Также можно подать новый запрос на смену статуса уязвимости, выбрав новый статус в поле Apply another request на странице с подробной информацией об уязвимости, или выбрав пункт меню с целевым статусом в строке уязвимости на странице Issues. Предыдущий запрос при этом будет отменен.

Для пользователя с ролью Инженер ИБ (Security Engineer)

Запрашиваемый статус уязвимости будет отображаться на странице Issues и на странице с подробной информацией об уязвимости в панели Requested issue status change.

Можно принять решение по запросу:

  • Утвердить запрос, нажав на кнопку Approve панели Requested issue status change на странице с подробной информацией об уязвимости.
  • Отклонить запрос, нажав на кнопку Reject панели Requested issue status change.

Также можно изменить статус уязвимости, выбрав новый статус в поле Apply another request на странице с подробной информацией об уязвимости, или выбрав пункт меню с новым статусом в строке уязвимости на странице Issues. Запрос на смену статуса при этом будет отменен.

Важно!

Инженер ИБ (Security Engineer) может менять статус уязвимости без триажных ограничений.

Примечание

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

Смена статуса запроса

  1. При ручной смене статуса уязвимости или при смене статуса за счет работы правила (или его удаления) в системе выполняется проверка, имеет ли уязвимость неутвержденный запрос на смену статуса:

    • Если такой запрос существует и запрашиваемый статус этого запроса совпадает с тем, на который меняется статус уязвимости, запрос становится неактуальным и ему присваивается статус Approved (Утвержден).
    • Если такой запрос существует и запрашиваемый статус этого запроса не совпадает с тем, на который меняется статус уязвимости, запрос становится неактуальным и ему присваивается статус Rejected (Отклонен).
  2. При смене статуса уязвимости на статус Open (ее привязывают к дефекту) или Fixed в системе выполняется проверка, имеет ли уязвимость неутвержденный запрос на смену статуса.

    Если такой запрос существует, то ему присваивается статус Rejected (Отклонен).

  3. При подтверждении запроса на смену статуса уязвимости в системе выполняется проверка, имеет ли уязвимость статус Open (привязана к дефекту).

    Если условие выполняется, то уязвимость отвязывается от дефекта и ее статус меняется на запрашиваемый.

  4. Если уязвимость имеет статус Open, и для нее был создан запрос на смену статуса, а затем уязвимость отлинковали от дефекта, то она вернется в изначальный статус, а запрос будет отменен.

Управление серьезностью проблемы безопасности

Примечание

Для управления серьезностью проблемы безопасности требуется роль Инженер ИБ (Security Engineer).

Для изменения серьезности уязвимости необходимо:

  1. На странице Issues в строке выбранной проблемы безопасности или на странице с подробной информацией о ней в меню действий «» выбрать пункт меню Change Severity.
  2. Выбрать новое значение Severity из списка.
  3. В окне Issue severity change ввести комментарий и нажать на кнопку Confirm.

Новое значение Severity уязвимости будет отображено как на странице Issues в строке проблемы безопасности в столбце Severity, так и на странице с подробной информацией об уязвимости в панели Severity level change. Кроме того, запись о смене Severity появится на вкладке Severity history.

Значение Severity, установленное пользователем вручную, имеет приоритет и не обновляется при импорте.

При изменении значения Severity уязвимости происходит пересчет WRI групп корреляции, в которые она входит.

Групповое изменение серьезности

Для изменения серьезности нескольких уязвимостей одновременно выберите их из списка на странице Issues, нажмите на кнопку Actions, выберите пункт меню Change Severity и далее значение Severity.

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

  1. Массовые действия доступны только для уязвимостей с одинаковым значением Severity.
  2. Пункт меню с текущим значением Severity будет недоступен.

Примечание

При установленном на странице Issues флаге Select all records существует возможность одновременно провести изменение серьезности для уязвимостей с различными значениями Severity. В качестве нового значения можно выбрать любое значение Severity из списка.

Возврат к первоначальному значению серьезности

Первоначальным значением серьезности уязвимости является значение, полученное при последнем импорте.

Для возврата к первоначальному значению серьезности уязвимости необходимо:

  1. На странице Issues в строке выбранной проблемы безопасности или на странице с подробной информацией о ней в меню действий «» выбрать пункт меню Change Severity.
  2. Выбрать из списка значение Inintial.
  3. В окне Issue severity change ввести комментарий и нажать на кнопку Confirm.

Для возврата к первоначальному значению серьезности нескольких уязвимостей одновременно выберите их из списка на странице Issues, нажмите на кнопку Actions, выберите пункт меню Change Severity и далее значение Inintial.

При возврате к первоначальному значению Severity уязвимости происходит пересчет WRI групп корреляции, в которые она входит.

Действия с дефектами

Создание дефекта на основе уязвимости

Для создания дефекта на основе уязвимости:

  • На странице Issues в строке выбранной проблемы безопасности в выпадающем меню «» выберите пункт Create defect.
  • Или перейдите на страницу с детальной информацией о соответствующей проблеме, нажав ее идентификатор на странице Issues. Нажмите на кнопку Actions и в раскрывающемся меню выберите пункт Create defect.

Детали см. в разделе «Создание дефекта на основе проблем безопасности».

Привязка/отвязка уязвимости от дефекта

Для привязки или отвязки уязвимости от дефекта, в зависимости от ее текущего статуса:

  • На странице Issues в строке выбранной проблемы безопасности в выпадающем меню «» выберите пункт Link to defect / Unlink from defect.
  • Или перейдите на страницу с детальной информацией о соответствующей проблеме, нажав ее идентификатор на странице Issues. Нажмите на кнопку Actions и в раскрывающемся меню выберите пункт Link to defect / Unlink from defect.

Детали см. в разделах «Добавление проблем безопасности в дефект» и «Удаление проблем безопасности из дефекта».

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

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

Выберите приложение, а затем выберите пункт меню Issues. Нажмите на кнопку Actions и в выпадающем меню выберите пункт Import all issues, чтобы импортировать уязвимости из инструментов AST. После завершения процесса импорта на экране появятся импортированные проблемы.

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

Чтобы импортировать проблемы для нескольких приложений:

  • На глобальной странице выберите в меню пункт Issues.
  • Нажмите на кнопку Actions и в выпадающем меню выберите пункт Import all issues.
  • На экране появится окно Choose application. Выберите в этом окне приложения, для которых необходимо импортировать проблемы. Чтобы выбрать все доступные пользователю приложения, установите флажок Select all. Чтобы начать импорт, нажмите на кнопку Import.

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

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

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

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

Примечание

JSON-схема и пример отчета приведены в «Приложении 17. Отчеты для импорта информации о проблемах безопасности».

Прежде чем приступить к импорту, в AppSecHub следует создать инструменты, отчеты которых будут импортироваться, см. раздел «Кастомные инструменты». Имена инструментов будут отображаться для импортированных проблем безопасности (поле Found by), а также могут использоваться при фильтрации уязвимостей (поле by tool).

Импорт отчета через пользовательский интерфейс

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

  1. Перейдите на страницу Issues выбранного приложения.

  2. Нажмите на кнопку Actions и выберите пункт Import from report. Откроется окно Importing issues.

  3. Укажите следующие параметры:

    • При установленном флаге Inherit QG критерий качества для импорта отчета наследуется с уровня приложения либо с более высокого уровня, если у приложения включено наследование критериев качества (Профиль компании → Структура организации → Приложение). В этом случае поле Quality gate становится неактивным и в нем отображается Inherited или название критерия качества, унаследованного от приложения.

      Если флаг не установлен, поле Quality gate будет доступно для выбора критерия качества из выпадающего списка.

    • Quality gate — выпадающий список для выбора применяемого критерия качества.

    • Structure unit — структурная единица приложения.
    • Release name — название релиза, к которому относится импортируемый отчет.
    • Report file — файл отчета в формате JSON.
  4. Нажмите на кнопку Import.

В результате импорта создается объект сканирования и проблемы безопасности, а пайплайны и сканирования не создаются. Запись об успешном завершении импорта отображается на странице Task log.

Примечание

  1. Правила, заданные до импорта, применяются к импортируемым проблемам безопасности.
  2. Если информация о ранее импортированной проблеме безопасности отсутствует в очередном отчете, ее статус изменяется на Fixed.
  3. Импортированные проблемы безопасности с одинаковыми идентификаторами рассматриваются AppSec.Hub как одна уязвимость.
  4. Для импортированных проблем безопасности типа SAST поле Description на вкладке Details автоматически составляется из содержимого двух полей в отчете – описания уязвимости и описания правила.

Импорт отчета с использованием CLI

Для импорта с использованием командной строки применяется специальный скрипт import_report.py. Параметры скриптов AppSec.Hub CLI приведены в «Приложении 5. Параметры скриптов AppSec.Hub CLI». Пример использования скрипта приведен в «Приложении 6. Примеры запуска скриптов AppSec.Hub CLI».

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

Отчеты в форматах XLSX, PDF и ZIP

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

Примечание

Если к списку проблем безопасности были применены какие-либо фильтры, они учитываются при формировании отчета.

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

Перейдите на страницу Issues, нажмите на кнопку Actions в правом верхнем углу и в выпадающем меню выберите пункт Generate report и далее - необходимый формат (XLSX, PDF или ZIP).

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

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

Отчеты OWASP TOP 10 и ОУД4

Система предоставляет возможность формирования отчетов OWASP TOP 10 или ОУД4 в виде HTML-файла.

Отчет OWASP TOP 10 показывает, существуют ли в выбранном приложении или приложениях проблемы безопасности, относящиеся к OWASP TOP 10.

Примечание

Установленные фильтры не влияют на отчеты OWASP TOP 10 и ОУД4. Эти отчеты генерируются по всему приложению.

Отчет ОУД4 содержит информацию о соответствии выбранного приложения или приложений требованиям, установленным ГОСТ Р 15408-3-2013 к четвертому оценочному уровню доверия (ОУД4) в части класса доверия «AVA:Оценка уязвимостей» (AVA_VAN).

Для получения отчета перейдите на страницу Issues, нажмите на кнопку Actions в правом верхнем углу и в выпадающем меню выберите пункт Generate report и далее тип отчета – OWASP TOP 10 или EAL 4 (GOST 15408-3) для ОУД4.

Сгенерировать отчет можно как для одного приложения на странице Issues данного приложения, так и на глобальной странице Issues для нескольких или всех приложений, к которым пользователь имеет доступ. В последнем случае необходимо дополнительно выбрать приложения, для которых требуется отчет, и нажать на кнопку Generate:

В результате будет сформирован и скачан в виде HTML-файла отчет в выбранном формате, включающий следующую информацию:

  • Дата формирования отчета.
  • Список просканированных приложений.
  • Краткая сводка по сканированию, включая дату последнего успешного сканирования.
  • Сводные данные по статусу, типу и распределению проблем безопасности, относящихся к OWASP TOP 10 или к ОУД4 в зависимости от типа отчета.

    Примечание

    Статусу Подтверждено в отчете в системе соответствуют статусы Confirmed и Open, статусу Опровергнуто – статусы False positive и Accepted risk, статусу Не обработано – статус To verify.

    Проблемы безопасности, имеющие в системе статус Fixed, в отчет не включаются.

  • Сводные данные о проблемах безопасности по категориям OWASP TOP 10 или по результатам проверки критериев ОУД4 в зависимости от типа отчета. Критерии ОУД4 подсвечены в отчете зеленым или красным в зависимости от результата их проверки. Описание критериев ОУД4 включено в состав отчета.

  • Детальные данные о каждой найденной проблеме безопасности. Проблемы безопасности в отчете группируются по категориям OWASP TOP 10 или ОУД4 соответственно, а внутри категорий – по типу (SAST, DAST, SCA Compliance и SCA Security для OWASP TOP 10; SAST, DAST и SCA Security для ОУД4) и по уровню критичности.

    Примечание

    Проблемы безопасности SCA Compliance в отчет ОУД4 не включаются.

    Детальная информация по проблемам безопасности со статусом Опровергнуто в отчет не включается.

К началу