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

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

Примечание

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

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

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 — ссылка на соответствующий дефект безопасности, если он уже существует.

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

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

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

Примечание

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

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

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

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

    Примечание

    Для проблем безопасности типа SAST отображается исходный код, ставший причиной обнаружения уязвимости. Это возможно только при подключении систем контроля версий с указанием URL их API, см. раздел «Подключение инструментов разработки ПО».

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

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

    Примечание

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

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

    Примечание

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

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

    Примечание

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

  • 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. Информацию о проблемах безопасности можно экспортировать в файл, см. раздел «Экспорт проблем безопасности в файл».

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

Несмотря на то, что импорт 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, предусмотрена возможность загрузки отчетов. Отчеты могут загружаться как через пользовательский интерфейс, так и с использованием CLI.

Примечание

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

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

Добавление имен инструментов

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

  2. Откройте страницу Tools и перейдите на вкладку Custom products.

  3. Нажмите кнопку +Add new. Откроется окно Create custom product.

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

    • Code — код инструмента (значение поля scans:tool:product в JSON-файле импортируемого отчет).
    • Name — имя инструмента (отображается в информации об уязвимости и используется в фильтре by tool на странице Issues).

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

Примечание

На вкладке Custom products страницы Tools система предоставляет список предустановленных инструментов, для которых уже заданы параметры Code и Name.

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

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

  1. Перейдите на страницу Issues.

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

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

    • Application — приложение, в рамках которого будет происходить импорт информации об уязвимостях.
    • Structure unit — структурная единица приложения.
    • Quality gate — применяемые критерии качества.
    • Report file — файл отчета в формате JSON.

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

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

Примечание

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

Примечание

Если информация о ранее импортированной проблеме безопасности отсутствует в очередном отчете, ее статус изменяется на Fixed.

Примечание

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

Примечание

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

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

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

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

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

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

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

  • Фильтрация с использованием 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 state — по состоянию (NEW, REPEATED);
  • by tool — по инструменту, с помощью которого обнаружена уязвимость;
  • by severity — по серьезности (Low, Medium, High и Critical);
  • by source — по источнику;
  • by category — по категории;
  • by branch — по ветке (если проблема безопасности хотя бы один раз была найдена в указанной ветке, то она войдет в результаты фильтрации);
  • by CWE ID — по CWE ID;
  • by CVE ID — по CVE ID;
  • by scan ID — по 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 codebase, by artifact, by instance и by structure unit отображаются первые десять объектов. При поиске объекта в этих полях необходимо ввести не менее трех символов.

    Примечание

    В полях 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) и достоверность этой оценки в процентах.

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

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

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

В списке проблем безопасности отобразятся сформированные с помощью этого правила группы, а в области фильтрации появятся дополнительные поля, являющиеся параметрами выбранного правила корреляции для проблем безопасности соответствующего типа (SAST, DAST, SCA Sеcurity).

Примечание

Корреляция для проблем безопасности 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 Compliance - Scan target, Component name и Component version).
  • No groups — это поле отображается для тех проблем, которые в результате применения правила корреляции не вошли ни в одну из групп. У таких проблем нет общих значений параметров правила корреляции, что отображается в поле Params: N/A.

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

  • Date applied — дата и время создания правила.
  • Expiration date — срок действия созданного правила.
  • Acceptor — логин пользователя, принявшего данный риск.
  • Comments — комментарии.

Примечание

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

Примечание

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

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

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

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

Примечание

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

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

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

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

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

Примечание

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

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

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

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

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

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

На первом шаге создания правила в разделе Rule criteria представлены следующие параметры:

  • Select issue type — тип проблемы безопасности (SAST, DAST, SCA Security и SCA Compliance).

  • Select rule type — тип создаваемого правила (False positive, Accepted risk или Confirmed, в данном случае - Accepted risk).

  • Expiration date — срок действия создаваемого правила. При наступлении указанной даты статус уязвимости изменится с Accepted risk на To verify.

  • Comment — комментарии Инженера ИБ с указанием причины присвоения статуса Accepted risk.

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

Кроме того, для проблем безопасности типа SAST на первом шаге дополнительно представлен переключатель Using AVC prediction. Если он выключен, на следующем шаге не отображаются поля, необходимые для проведения AVC-анализа.

Набор параметров, представленных в виде полей в этом окне на втором шаге создания правила, зависит от типа проблемы безопасности.

Для проблем безопасности типов 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 — имя структурной единицы.

Примечание

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

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

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

  • AVC status и AVC Accuracy — эти параметры присутствуют только у проблем безопасности, имеющих в системе оценку «истинно/ложноположительный». AVC status может иметь значение True Positive или False Positive. AVC Accuracy может иметь значение от 51 до 100 процентов. Эти поля отображаются, если включен переключатель Using AVC prediction.

  • CWE — в этом поле можно указать CWE или список из нескольких CWE, разделенных запятыми. Это поле отображается, если включен переключатель Using AVC prediction.

  • Language — в этом поле можно указать язык программирования, для которого применимо это правило.

  • Path — путь к файлу, содержащему проблему безопасности. Таких путей может быть несколько для одной проблемы. Это поле отображается, если переключатель Using AVC prediction выключен.

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

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

  • Codebase name — имя кодовой базы.

  • Artifact name — имя артефакта.

  • Structure unit — имя структурной единицы.

Примечание

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

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

  • Category — категория проблемы безопасности. В отличие от других типов проблем безопасности, для DAST это поле не предлагает список для выбора. Оно является полем для ввода значения в свободном формате.

  • URL — адрес источника проблемы безопасности.

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

  • Artifact name — имя артефакта.

  • Structure unit — имя структурной единицы.

Примечание

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

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

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

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

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

  • AR Rule — номер правила в системе.

  • Date applied — время присвоения проблеме статуса Accepted risk.

  • Expiration date — срок действия правила (дата и время).

  • Acceptor — имя пользователя, присвоившего проблеме статус Accepted risk.

  • Comments — комментарии Инженера ИБ.

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

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

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

Чтобы просмотреть все добавленные в исключения проблемы безопасности в приложении, нажмите кнопку фильтрации справа вверху и в поле by status выберите значение Accepted risk.

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

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

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

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

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

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

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

Примечание

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

Примечание

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

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

Примечание

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

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

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

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

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

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

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

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

Примечание

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

Примечание

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

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

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

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

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

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

Для этого нажмите кнопку Actions и в раскрывающемся меню выберите пункт To verify. Обратите внимание, что пункты Accept risk, False positive, Confirm и Create rule раскрывающегося меню в этот момент не доступны.

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

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

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

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

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

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

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

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

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

На первом шаге создания правила в разделе Rule criteria представлены следующие параметры:

  • Select issue type — тип проблемы безопасности (SAST, DAST, SCA Security и SCA Compliance).
  • Select rule type — тип создаваемого правила (False positive, Accepted risk или Confirmed, в данном случае - False positive).
  • Expiration date — срок действия создаваемого правила. При наступлении указанной даты статус уязвимости изменится с False positive на To verify.
  • Comment — комментарии Инженера ИБ с указанием причины присвоения статуса False positive.

Набор параметров, представленных в виде полей в разделе Issue parameters в этом окне на втором шаге создания правила, зависит от типа проблемы безопасности. Параметры для всех типов уязвимостей (SAST, DAST, SCA Security и SCA Compliance) совпадают с параметрами, описанными выше в разделе «Безусловное и условное принятие риска с созданием правила».

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

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

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

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

  • FP Rule — номер правила в системе.
  • Date applied — дата и время создания правила.
  • Expiration date — срок действия правила (дата и время).
  • Comments — комментарии Инженера ИБ.

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

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

Примечание

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

Примечание

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

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

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

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

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

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

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

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

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

Примечание

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

Примечание

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

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

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

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

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

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

Для этого нажмите кнопку Actions и в раскрывающемся меню выберите пункт To verify. Обратите внимание, что пункты Accept risk, False positive, Confirm и Create rule раскрывающегося меню в этот момент не доступны.

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

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

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

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

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

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

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

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

В открывшемся окне Create a vulnerability processing rule заполните или отредактируйте необходимые поля аналогично тому, как описано выше в разделе «Присвоение проблеме безопасности статуса False positive с созданием правила». Часть полей данного окна будет заполнена автоматически на основе информации, полученной из инструмента AST. В поле Select rule type необходимо выбрать тип создаваемого правила Confirmed.

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

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

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

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

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

Массовые операции с проблемами безопасности

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

Нажимая значки , выберите из списка необходимые проблемы безопасности. Выбранные проблемы будут отмечены значком . В результате на кнопке Actions справа вверху будет отображаться количество выбранных проблем безопасности.

Нажмите кнопку Actions и выберите необходимый пункт в выпадающем меню, чтобы провести операцию с несколькими проблемами безопасности. В зависимости от статуса выбранных проблем, в меню будут доступны пункты Create defect, Link to defect, Accepted risk, Confirm, False positive и To verify. Доступность пунктов выпадающего меню и последовательность действий при работе с несколькими проблемами безопасности совпадают с приведенными выше для отдельно взятой проблемы безопасности.

Примечание

Условное принятие риска для нескольких проблем безопасности доступно только для SCA Security уязвимостей. Если среди выбранных уязвимостей будет хотя бы одна SCA Compliance, SAST или DAST уязвимость, возможно только безусловное принятие риска.

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

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

Если из инструмента AST уязвимость была импортирована со статусом, отличным от To verify, то на данную уязвимость правила распространяться не будут. В AppSec.Hub такой уязвимости невозможно вручную присвоить статус To verify. Управление статусом уязвимости в AppSec.Hub возможно только в случае, если из инструмента AST уязвимость пришла в статусе To verify.

Правила не применяются к тем уязвимостям, статус которых был изменен вручную (со статусом False positive, Accepted risk или Confirmed), для которых был создан дефект (со статусом Open), или которые были исправлены (со статусом Fixed).

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

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

В целом, правила применяются к уязвимостям в трех случаях:

  • При создании в системе нового правила. Это значит, что правило применяется и начинает работать сразу после его создания, для этого не обязательно заново сканировать проект.
  • При проведении сканирования. Это значит, что правило будет применяться и по отношению к новым уязвимостям, если они появляются при очередном сканировании.
  • При ручном импорте проблем из инструмента AST.

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

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

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

  • # — идентификационный номер правила в системе.

  • В случае, если правило в данный момент не распространяется на какие-либо проблемы безопасности в приложении, рядом с идентификационным номером располагается значок OBSOLETE. Если это правило применено к каким-либо проблемам безопасности, значок OBSOLETE отсутствует.

  • Rule type — тип правила (False positive, Accepted risk или Confirmed).

  • Issue type — тип проблемы безопасности.

  • Component — компонент, к которому применяется правило.

  • CVE — идентификатор уязвимости CVE ID (в данном поле можно также указать CVE в формате, предлагаемом компаниями Sonatype, GitHub и OSS), к которой применяется правило.

  • Category — выбранная категория (-ии).

  • Created — дата создания правила.

  • Expiry date — срок действия правила.

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

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

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

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

Примечание

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

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

Примечание

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

Примечание

Важно заметить, что пока в AppSec.Hub существует действующее правило, все соответствующие импортируемые из инструмента уязвимости, будут получать определенный этим правилом статус (False Positive, Accepted risk или Confirmed), независимо от предыдущих изменений их статусов.

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

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

Примечание

В системе существует возможность открепить проблему безопасности от действующего правила. Для этого достаточно вручную присвоить данной проблеме безопасности статус To verify с помощью соответствующего пункта меню, а затем произвести необходимые изменения. Таким образом можно, например, проблему со статусом False Positive перевести сначала в статус To verify, а затем присвоить ей статус Accepted risk с помощью соответствующих пунктов меню. После таких изменений статуса правило больше не будет применяться к данной проблеме. Однако если в результате ручных изменений проблема получит статус To verify, то при следующем применении правила она вновь попадет под его действие.

В системе предусмотрена возможность фильтрации правил по нескольким параметрам. Чтобы настроить правила фильтрации, нажмите кнопку 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 — по структурной единице.

Примечание

При фильтрации с использованием полей by codebase, by artifact, by instance и 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/Accepted risk/Confirmed, будет изменен на To Verify, также будут удалены комментарии и срок истечения действия удаляемого правила. В противном случае, если данная опция не была выбрана, у уязвимостей останутся без изменений статус, комментарии и срок истечения, до которого будет действовать текущий статус False positive/Accepted risk/Confirmed (после удаления правила этот статус можно будет поменять на To Verify вручную).

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

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

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

Примечание

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

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

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

При определении алгоритма изменения состояний проблем безопасности можно задать настройки на уровне Security Pipeline (поле Issue state policy на вкладке Settings, см. детали в разделе в разделе «Настройки Security Pipeline») и/или на уровне приложения (поле Issue state policy на вкладке General, см. детали в разделе «Настройки приложения»).

Примечание

Расчет состояний проблем безопасности определяется на основе сочетания «объект сканирования и инструмент сканирования».

Для определения необходимости изменений состояния проблем безопасности используются данные о том, были ли ранее занесены в систему проблемы безопасности для данного объекта сканирования, найденные данным инструментом. При наличии таких проблем безопасности, в случае нового импорта из инструмента к ним применяется заданный алгоритм изменения состояний. В случае отсутствия нового импорта из инструмента сканирования, состояние и статус найденных с его помощью проблем безопасности изменяться не будут.

Примечание

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

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

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

Примечание

Если к перечню Security Issues были применены какие-либо фильтры, они учитываются при формировании отчета. Например, если необходимо сформировать отчет, содержащий Security Issues в порядке убывания степени их серьезности, применим фильтр 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.

Отчет ОУД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 не включаются.

    Примечание

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

К началу