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

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

Примечание

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

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

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

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

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

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

Нажмите идентификатор или название выбранного приложения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • SEVERITY — серьезность проблемы в инструменте AST (Low, Medium, High или Critical).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • sort by — по уровню серьезности — Severity: High to Low/Low to High (от более серьезных к менее, и наоборот) или по времени занесения/последнего обновления — Newest first/Last updated (сначала новые/сначала старые);
  • by type — по типу (SAST, SCA Compliance, SCA Security и DAST);
  • by structure unit — по структурным единицам приложения;
  • by status — по статусу (To Verify, Confirmed, Open, Fixed и False Positive);
  • by state — по состоянию (NEW, REPEATED);
  • by tool — по инструменту, с помощью которого обнаружена уязвимость (Acunetix, Aqua Security, Checkmarx CxSAST, Clair, CodeScoring, Dependency-Track, Fortify Static Code Analyzer, IBM Security AppScan, MDast, NetSparker, Nexus IQ Server, OWASP ZAP, PT AppInspector, PT Blackbox, Solar appScreener, SonarQube, Trivy и Wallarm FAST);
  • by severity — по серьезности (Low, Medium, High и Critical);
  • by source — по источнику;
  • by category — по категории;
  • 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 structure unit, by type, by codebase, by artifact, by instance и by repository proxy может быть одновременно выбрано несколько параметров, см. рис. ниже.

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

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

  • by upper limit of accuracy — по верхнему пределу точности оценки AVC.

    Примечание

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

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

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

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

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

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

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

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

Если в инструменте (например, Nexus IQ или Aqua Security) уязвимость добавлена в исключения (waived в Nexus IQ или acknowledged в Aqua Security), то при импорте в AppSec.Hub она получает статус Accepted risk.

Примечание

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

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

В системе реализованы два типа механизмов принятия рисков: безусловный и условный. В случае безусловного принятия риска Инженер ИБ безоговорочно допускает наличие определенной уязвимости и она не учитывается при расчете 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 — комментарии.

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

Условное принятие риска доступно только для 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, в данном случае - Accepted risk).

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

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

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

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

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

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

    Примечание

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

    Примечание

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

  • Component group — группа компонента, содержащего проблему безопасности.

  • Component name — наименование компонента, содержащего проблему безопасности.

  • Component version — версия компонента, содержащего проблему безопасности.

    Примечание

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

    Примечание

    Для уязвимостей категории Component-Unknown поля Component name и Component version не являются обязательными для заполнения.

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

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

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

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

  • Repository proxy name — имя прокси-репозитория.

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

Примечание

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

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

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

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

  • Source code — фрагмент исходного кода, содержащий проблему. Таких фрагментов может быть несколько для одной проблемы.

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

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

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

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

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

Примечание

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

В разделе Issue parameters для проблем безопасности типа 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 может быть присвоен только проблемам безопасности, находящимся в статусе 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. Обратите внимание, что остальные пункты раскрывающегося меню в этот момент не доступны.

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

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

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

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

Примечание

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 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), независимо от предыдущих изменений их статусов.

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

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

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

Если необходимо удалить правило, перейдите на страницу 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, будет изменен на To Verify, также будут удалены комментарии и срок истечения действия удаляемого правила. В противном случае, если данная опция не была выбрана, у уязвимостей останутся без изменений статус, комментарии и срок истечения, до которого будет действовать текущий статус False positive или Accepted risk (после удаления правила этот статус можно будет поменять на 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 приведена в разделе «Security Pipelines».

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

Примечание

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

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

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

Примечание

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

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

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

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

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

К началу