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

Правила в системе применяются только к проблемам безопасности, находящимся в статусе 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). При одновременном попадании уязвимости под несколько правил будет применено то, которое было создано раньше (имеет меньший идентификационный номер в системе).

Примечание

Важно заметить, что пока в 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, то при следующем применении правила она вновь попадет под его действие.

Информация о правилах

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

Примечание

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

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

Фильтрация правил

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

Создание правила

Примечание

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

Примечание

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

Новое правило может быть создано несколькими способами:

Непосредственно на странице Rules нажмите на кнопку +Add new и выберите тип создаваемого правила (SAST, DAST, SCA Security, SCA Compliance) в выпадающем меню.
На странице Issues нажмите на идентификатор проблемы безопасности и перейдите на страницу с детальной информацией о ней. Нажмите на кнопку Actions и выберите пункт меню Create rule.
На странице 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).
Expiration date — срок действия создаваемого правила.
Comment — комментарий.

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

SCA Security и SCA Compliance

Для проблем безопасности типа SCA Security и для типа создаваемого правила Accepted risk на первом шаге создания правила можно задать как условное, так и безусловное принятие риска. Чтобы осуществить условное принятие риска, необходимо в поле SAST issue category выбрать значение из выпадающего списка. В случае, если значение в поле SAST issue category не выбрано, производится безусловное принятие риска.

На втором шаге для проблем безопасности типов 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

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

На втором шаге представлены следующие отличные от уже описанных выше параметры:

Category — категория проблемы безопасности.
AI status и AI Accuracy — эти параметры присутствуют только у проблем безопасности, имеющих в системе оценку «истинно/ложноположительный». AI status может иметь значение True Positive или False Positive. AI Accuracy может иметь значение от 51 до 100 процентов. Эти поля отображаются, если включен переключатель Using AI prediction.
CWE — в этом поле можно указать CWE или список из нескольких CWE, разделенных запятыми. Это поле отображается, если включен переключатель Using AI prediction.
Language — в этом поле можно указать язык программирования, для которого применимо это правило.
Path — путь к файлу, содержащему проблему безопасности. Таких путей может быть несколько для одной проблемы. Это поле отображается, если переключатель Using AI prediction выключен.
Source code — фрагмент исходного кода, содержащий проблему. Таких фрагментов может быть несколько для одной проблемы. Это поле отображается, если переключатель Using AI prediction выключен.
Scope — в этом поле можно выбрать из выпадающего списка одно из трех значений: SOURCE (источник проблемы — первая строка в цепочке вхождений), TARGET (целевая последняя строка в цепочке вхождений), ANY (используется при поиске всех значений). Это поле отображается, если переключатель Using AI prediction выключен.

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

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

Примечание

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

DAST

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

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

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

Artifact name — имя артефакта.
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 вручную).

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