Поделиться через

Настройка проверки зависимостей

Проверка зависимостей в GitHub Advanced Security для Azure DevOps обнаруживает компоненты открытого исходного кода, используемые в вашем исходном коде, и обнаруживает наличие связанных уязвимостей. Все обнаруженные уязвимости из компонентов с открытым исходным кодом помечаются как предупреждение. Вам потребуется либо GitHub Advanced Security для Azure DevOps, либо, если вы используете автономный режим, GitHub Code Security для Azure DevOps.

GitHub Advanced Security для Azure DevOps работает с Azure Repos. Чтобы использовать GitHub Advanced Security с репозиториями GitHub, см. GitHub Advanced Security.

Предпосылки

Категория Требования
Разрешения — Чтобы просмотреть сводку всех оповещений для репозитория, нужны разрешения участника для репозитория.
— Чтобы отклонить оповещения в Advanced Security: администратор проекта разрешения.
— Для управления разрешениями в Расширенной безопасности: быть членом группы Администраторов коллекции проектов или иметь разрешение Расширенная безопасность: управление параметрами установлено на Разрешить.

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

Сведения о проверке зависимостей

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

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

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

Для каждого уязвимого компонента, обнаруженного в процессе использования, компонент и уязвимость перечислены в журнале сборки и отображаются в виде оповещения на вкладке "Расширенная безопасность". Только рекомендации, проверяемые GitHub и добавленные в базу данных рекомендаций GitHub, создают оповещение зависимости. Журнал сборки содержит ссылку на конкретное оповещение для более детального изучения. Чтобы получить дополнительные сведения о деталях оповещения, ознакомьтесь с разделом "Исправление оповещений о сканировании зависимостей".

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

Снимок экрана результатов сканирования сборки зависимостей

Список поддерживаемых экосистем компонентов и версий см. в разделе "Поддерживаемые экосистемы пакетов".

Узнайте об оповещениях сканирования зависимостей

Вкладка "Расширенная безопасность" в Repos в Azure DevOps — это центр для просмотра оповещений системы безопасности, которые по умолчанию отображают оповещения проверки зависимостей. Вы можете фильтровать по ветви, конвейеру, пакету и серьезности. Вы можете выбрать оповещение для получения дополнительных сведений, включая рекомендации по исправлению. В настоящее время центр оповещений не отображает оповещения о сканировании, завершенном в ветвях PR.

При обнаружении уязвимого пакета в репозитории исправление оповещений проверки зависимостей обычно включает обновление до более высокой версии пакета или удаление обижающего пакета. Этот совет относится как к прямым, так и к транзитивным (или косвенным) зависимостям. Вкладка "Расширенная безопасность" по умолчанию показывает активные оповещения для ветви по умолчанию вашего репозитория.

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

Снимок экрана: представление оповещений проверки зависимостей для репозитория

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

Снимок экрана: просмотр оповещений проверки закрытых зависимостей

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

Сведения об оповещении

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

Снимок экрана: сведения об оповещении сканирования зависимостей

Раздел Описание
Рекомендация Текст рекомендации поступает непосредственно из нашего поставщика данных об уязвимостях, базы данных рекомендаций GitHub. Как правило, в руководстве предлагается обновить идентифицированный компонент до неуязвимой версии.
Расположение В разделе "Расположения" описаны пути, в которых задача проверки зависимостей обнаруживает уязвимый компонент, используемый. Если файл можно определить из базовой проверки сборки как зафиксированный в исходном коде файл, карточка "Расположение" отображается как щелкабельная ссылка. Если файл был создан как часть сборки (например, артефакт сборки), ссылка недоступна. Просмотрите журналы сборки, чтобы лучше понять, как компонент был доставлен в сборку.
Описание Описание представлено описанием GitHub Advisory.

Обнаружения

Конвейеры, перечисленные на вкладке "Обнаружения" , являются конвейерами, в которых найден уязвимый компонент. Каждая строка содержит последнюю сборку затронутого конвейера и дату первого внедрения пакета. Если уязвимый пакет исправлен в некоторых проводках, но не во всех, вы увидите частично обновленные строки.

Снимок экрана: представление обнаружения зависимостей для оповещения без исправления

Когда оповещение будет разрешено, оно автоматически перемещается в Closed состояние, а последний конвейер выполнения на вкладке "Обнаружения" отображает зеленую галочку, что означает, что код, содержащий обновленный компонент, был запущен в этом конвейере.

Снимок экрана: представление обнаружения зависимостей для оповещения

Серьезность

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

Балл CVSS Серьезность
1.0 < Оценка < 4.0 Низкая
4.0 < Оценка < 7.0 Средняя
7.0 < Оценка < 9.0 Высокая
Score >= 9.0 Критически важно

Поиск сведений

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

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

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

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

Управление оповещениями сканирования зависимостей

Просмотр оповещений для репозитория

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

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

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

Прямая зависимость — это компонент, который у вас есть в репозитории. Транзитивная или непрямая зависимость — это компонент, который используется прямой зависимостью. Ваш проект по-прежнему уязвим независимо от того, найдена ли уязвимость в прямой или транзитной зависимости.

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

Обновление зависимостей для Yarn/Npm

Предположим, что этот пакет имеет две уязвимости. Одна из них — это axios прямая зависимость, а одна — acorn транзитивная зависимость (также известная как косвенная зависимость или зависимость от зависимости).

{
 "name": "my-package",
 "version": "1.0.0",
 "dependencies": {
   "axios": "0.18.0",
   "eslint": "5.16.0",
 }
}

Текущая версия axios имеет уязвимость типа "отказ в обслуживании" (DoS) с рекомендацией по обновлению до версии 0.18.1 или более поздней. Поскольку это прямая зависимость, вы можете контролировать версию axios, которую используете; все, что нужно сделать, это обновить версию axios, которую вы добавляете. Обновленный вид package.json выглядит примерно так:

{
  "name": "my-package",
  "version": "1.0.0",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0",
  }
}

Теперь версия eslint, отображаемая в package.json, зависит от версии acorn, уязвимость которой связана с отказом в обслуживании из-за регулярных выражений, "Re-DoS", с рекомендацией обновиться до версии 5.7.4, 6.4.1, 7.1.1 или выше. Если вы получите оповещение от средства проверки зависимостей, оно должно сообщить о корневой зависимости, требующей уязвимой зависимости.

Пряжа

Если вы используете Yarn, вы можете использовать yarn why, чтобы найти полную цепочку зависимостей.

> $ yarn why acorn
 yarn why v1.22.4
 [1/4] Why do we have the module "acorn"...?
 [2/4] Initialising dependency graph...
 [3/4] Finding dependency...
 [4/4] Calculating file sizes...
 => Found "acorn@6.4.0"
 info Reasons this module exists
   - "eslint#espree" depends on it
   - Hoisted from "eslint#espree#acorn"
 info Disk size without dependencies: "1.09MB"
 info Disk size with unique dependencies: "1.09MB"
 info Disk size with transitive dependencies: "1.09MB"
 info Number of shared dependencies: 0
 Done in 0.30s.

Полная цепочка eslint>espree>acornзависимостей . После того как вы знаете цепочку зависимостей, вы можете использовать другую функцию Yarn — выборочные разрешения зависимостей, чтобы переопределить версию Acorn, которая используется.

Используйте поле "Режимы" в package.json для определения переопределения версии. Показаны три различных метода переопределения пакета в порядке от худшего к лучшему.

{
  "name": "yarn-resolutions",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0"
  },
  "resolutions": {
    // DO NOT USE!
    "**/acorn": "6.4.1",
    // BETTER
    "eslint/**/acorn": "6.4.1",
    // BEST
    "eslint/espree/acorn": "6.4.1"
  }
}

Использование **/acorn шаблона переопределяет все случаи использования пакета acorn во всех зависимостях. Это опасно и вызывает сбои во время выполнения, поэтому мы удалили его в версии Yarn 2.

Использование шаблона eslint/**/acorn переопределяет все виды использования пакета acorn в пакете eslint и в любых пакетах, от которых он зависит. Это безопаснее, чем переопределение пакета для всех зависимостей, но все еще несет в себе некоторые риски, если граф зависимостей пакета большой. Этот шаблон рекомендуется использовать, если существует множество подпакетов, использующих уязвимый пакет, и определение переопределений для отдельных подпакетов будет непрактичным.

Использование шаблона eslint/espree/acorn переопределяет только использование acorn в пакете espree, находящемся в пакете eslint. Он специально нацелен на уязвимую цепочку зависимостей и является рекомендуемым способом переопределения версий пакетов.

npm

Если вы используете npm 8.3 или более поздней версии, вы можете использовать поле overrides в package.json.

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

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2",
    "eslint": "5.16.0"
  },
   "overrides":{
       "eslint": {
        "espree": {
          "acorn": "6.4.1"
        }
    }
   }
}

В показанном примере переопределения демонстрируется, как npm предлагает переопределить использование acorn в пакете espree в контексте пакета eslint. Это специально нацелено на уязвимую цепочку зависимостей и рекомендуется как способ для переопределения версий пакетов. Переопределения — это встроенная функция npm. Он предоставляет способ заменить пакет в дереве зависимостей другой версией или другим пакетом полностью.

После настройки переопределения необходимо удалить package-lock.json и node_modules и снова запустить npm install.

Вам не следует устанавливать переопределение для пакета, от которого вы напрямую зависите, если только зависимость и переопределение не имеют одну и ту же спецификацию. Например, если axios: "0.18.0" уязвим, и мы хотим обновить его до axios: "0.19.2". Измените версию зависимости напрямую вместо её переопределения.

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.18.0"
  },
  "overrides": {
    // BAD, will throw an EOVERRIDE error
    // "axios": "0.19.2",
  }
}

Обновите версию зависимости без задания переопределения:

{
  "name": "npm-overrides",
  "version": "1.0.0",
  "license": "MIT",
  "dependencies": {
    "axios": "0.19.2"
  }
}

Обновление зависимостей для Maven

Механизм разрешения зависимостей не столь сложный, как используемый в Yarn. В результате в проекте может быть только одна версия зависимости. Чтобы устранить эту проблему, Maven использует алгоритм "ближайшего выигрыша". То есть он использует версию ближайшей зависимости к проекту в дереве зависимостей.

Например, у вас есть следующие граф зависимостей:

your-project --- A:1.0.0 --- B:2.0.0
      \
       \__ B:1.0.0

your-project зависит от A:1.0.0, который, в свою очередь, зависит от B:2.0.0, но ваш проект также имеет прямую зависимость от B:1.0.0. Таким образом, у вас есть две разные версии зависимостей B в графе зависимостей, но версия 1.0.0 зависимостей B выигрывает, так как она является "ближайшей" к проекту.

В некоторых случаях этот сценарий может работать, если версии совместимы. Тем не менее, если A:1.0.0 зависит от некоторых функций B, доступных только в версии 2.0.0 , это поведение не работает. В худшем случае этот проект по-прежнему может компилироваться, но завершается сбоем во время выполнения.

Рассмотрим реальный пример.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.microsoft.customer360</groupId>
  <artifactId>maven-dependencies</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>maven-dependencies</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson.jaxrs</groupId>
      <artifactId>jackson-jaxrs-json-provider</artifactId>
      <version>2.10.3</version>
    </dependency>
</project>

Предположим, что версия com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider зависит от версии com.fasterxml.jackson.core:jackson-databind , которая имеет десериализацию уязвимости ненадежных данных.

Эту зависимость можно проверить с помощью подключаемого модуля зависимостей Maven. В этом случае вы запустите mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind и получите следующие выходные данные:

> $ mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
 [INFO] Scanning for projects...
 [INFO]
 [INFO] ------------< com.microsoft.customer360:maven-dependencies >------------
 [INFO] Building maven-dependencies 1.0-SNAPSHOT
 [INFO] --------------------------------[ jar ]---------------------------------
 [INFO]
 [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ maven-dependencies ---
 [INFO] com.microsoft.customer360:maven-dependencies:jar:1.0-SNAPSHOT
 [INFO] \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider:jar:2.10.3:compile
 [INFO]    \- com.fasterxml.jackson.jaxrs:jackson-jaxrs-base:jar:2.10.3:compile
 [INFO]       \- com.fasterxml.jackson.core:jackson-databind:jar:2.10.3:compile
 [INFO] ------------------------------------------------------------------------
 [INFO] BUILD SUCCESS
 [INFO] ------------------------------------------------------------------------
 [INFO] Total time:  0.928 s
 [INFO] Finished at: 2020-04-27T14:30:55+02:00
 [INFO] ------------------------------------------------------------------------

Во-первых, проверьте, есть ли новая версия com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider, которая не зависит от уязвимой версии com.fasterxml.jackson.core:jackson-databind. В этом случае можно обновить com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider и на этом остановиться. В противном случае переопределите версию com.fasterxml.jackson.core:jackson-databind.

Как показано в фрагменте кода, при использовании Maven "ближайшие победы", поэтому разрешение заключается в добавлении прямой зависимости к com.fasterxml.jackson.core:jackson-databind этой уязвимости.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.microsoft.customer360</groupId>
  <artifactId>maven-dependencies</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>maven-dependencies</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>com.fasterxml.jackson.jaxrs</groupId>
      <artifactId>jackson-jaxrs-json-provider</artifactId>
      <version>2.10.3</version>
    </dependency>
    <!-- Dependency resolutions -->
    <!-- jackson-jaxrs-json-provider -->
    <dependency>
      <groupId>com.fasterxml.jackson.core</groupId>
      <artifactId>jackson-databind</artifactId>
      <version>2.9.10.4</version>
    </dependency>
  </dependencies>
</project>

Вы можете проверить, работает ли решение, запустив mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind снова.

$ mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
[INFO] Scanning for projects...
[INFO]
[INFO] ------------< com.microsoft.customer360:maven-dependencies >------------
[INFO] Building maven-dependencies 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ maven-dependencies ---
[INFO] com.microsoft.customer360:maven-dependencies:jar:1.0-SNAPSHOT
[INFO] \- com.fasterxml.jackson.core:jackson-databind:jar:2.9.10.4:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.827 s
[INFO] Finished at: 2020-04-27T14:32:42+02:00
[INFO] ------------------------------------------------------------------------

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

В реальном проекте добавьте зависимость как можно более высокую цепочку. Например, можно добавить разрешение в родительский POM-файл, а не отдельно в каждом файле POM проекта.

Обновление зависимостей для NuGet

Алгоритм разрешения зависимостей, используемый в NuGet, аналогичен Maven, в том, что можно использовать только одну версию зависимости. Однако NuGet не закрепляет версии зависимостей.

Например, если у вас есть зависимость <PackageReference Include="A" Version="1.2.3" />, вы можете ожидать, что этот пакет будет эквивалентен = 1.2.3, но фактически означает >= 1.2.3. Чтобы закрепить точную версию, следует использовать Version="[1.2.3]". Дополнительные сведения см. в документации по диапазонам версий NuGet.

Помимо поведения диапазона по умолчанию NuGet восстанавливает самую низкую применимую версию для удовлетворения диапазона. Это означает, что во многих случаях необходимо определить диапазон.

Рассмотрим этот пример проекта, который имеет зависимость от Microsoft.AspNetCore.App:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <RootNamespace>NuGet.Dependencies</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.14" />
  </ItemGroup>
</Project>

Она зависит от версии, уязвимой для уязвимостиMicrosoft.AspNetCore.Http.Connections выполнения кода (RCE).

Сначала необходимо проверить наличие обновленной версии Microsoft.AspNetCore.App , зависящую от более новой версии Microsoft.AspNetCore.Http.Connections. В этом случае вы можете обновить Microsoft.AspNetCore.App и остановиться здесь. Если нет, необходимо переопределить версию Microsoft.AspNetCore.Http.Connections , от которой она зависит.

NuGet не имеет встроенного эквивалента для yarn why или mvn dependency:tree, поэтому самый простой способ увидеть дерево зависимостей — это часто посетить nuget.org. Если вы посетите страницу Microsoft.AspNetCore.App, вы увидите, что он зависит от Microsoft.AspNetCore.Http.Connectionsversion >= 1.0.4 && < 1.1.0. В диапазоне версий NuGet используется представительный синтаксис [1.0.4,1.1.0).

Уязвимость RCE в Microsoft.AspNetCore.Http.Connections была исправлена в версии 1.0.15, поэтому необходимо переопределить диапазон версий на [1.0.15, 1.1.0).

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <RootNamespace>NuGet.Dependencies</RootNamespace>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.8" />
  </ItemGroup>

  <ItemGroup Label="Dependency Resolutions">
    <!-- Microsoft.AspNetCore.App -->
    <PackageReference Include="Microsoft.AspNetCore.Http.Connections" Version="[1.0.15,1.1.0)" />
  </ItemGroup>
</Project>

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

Что делать, если нет доступных исправлений?

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

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

Отключение оповещений проверки зависимостей

Чтобы закрыть оповещение, сделайте следующее:

  1. Перейдите к оповещению, которое вы хотите закрыть, и выберите это оповещение.

  2. Выберите раскрывающийся список "Закрыть оповещение".

  3. Если этот параметр еще не выбран, выберите "Риск принят " или "Ложный положительный результат " в качестве причины закрытия.

  4. Добавьте необязательный комментарий в текстовое поле "Комментарий ".

  5. Нажмите кнопку "Закрыть", чтобы отправить и закрыть оповещение.

  6. Состояние оповещения меняется с Открыто на Закрыто и отображает причину отклонения.

    Снимок экрана: закрытие оповещений проверки зависимостей

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

Управление уведомлениями проверки зависимостей в pull-запросах

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

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

Снимок экрана: заметка о активном запросе на вытягивание зависимостей.

Чтобы закрыть оповещения pull-реквеста, необходимо перейти в детализированный просмотр оповещения, чтобы закрыть его и разрешить аннотацию. В противном случае простое изменение состояния комментария (1) решает вопрос комментария, но ни закрывает, ни исправляет основное предупреждение.

Снимок экрана аннотации запроса на слияние закрытого компонента.

Чтобы просмотреть весь набор результатов для ветви запроса на вытягивание, перейдите к Repos>Advanced Security и выберите свою ветвь запроса на вытягивание. При нажатии кнопки "Показать дополнительные сведения " (2) на заметке отображается представление сведений об оповещении на вкладке "Расширенная безопасность".

Совет

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