Beroendegenomsökning

Artikel
11/07/2024

Genomsökning av beroenden i GitHub Advanced Security för Azure DevOps identifierar de öppen källkod komponenter som används i källkoden och identifierar om det finns några associerade säkerhetsrisker. Eventuella sårbarheter som hittas från öppen källkod komponenter flaggas som en avisering.

GitHub Advanced Security för Azure DevOps fungerar med Azure Repos. Om du vill använda GitHub Advanced Security med GitHub-lagringsplatser läser du GitHub Advanced Security.

Om beroendegenomsökning

Beroendegenomsökning genererar en avisering för alla komponenter med öppen källkod, direkta eller transitiva, som visar sig vara sårbara som koden är beroende av. Direkta sårbarheter är de bibliotek som din kod använder direkt. Transitiva beroenden är de bibliotek eller annan programvara som direktberoenden använder.

Om identifiering av beroendegenomsökning

En ny ögonblicksbild av dina komponenter lagras när beroendediagrammet för en lagringsplats ändras och efter att en pipeline som innehåller beroendegenomsökningsuppgiften har körts.

För varje sårbar komponent som identifieras vid användning visas komponenten och säkerhetsrisken i byggloggen och visas som en avisering på fliken Avancerad säkerhet. Endast rekommendationer som granskas av GitHub och läggs till i GitHub Advisory Database skapar en avisering om beroendegenomsökning. Byggloggen innehåller en länk till den enskilda aviseringen för vidare undersökning. Mer information om aviseringsinformationen finns i Åtgärda beroendegenomsökningsaviseringar.

Byggloggen innehåller också grundläggande information om varje upptäckt sårbarhet. Den här informationen omfattar allvarlighetsgraden, den berörda komponenten, sårbarhetens titel och tillhörande CVE.

Skärmbild av utdata från en beroendegenomsökningsversion

En lista över komponentekosystem och versioner som stöds finns i Paketekosystem som stöds.

Om aviseringar om beroendegenomsökning

Fliken Avancerad säkerhet i Lagringsplatser i Azure DevOps är hubben för att visa dina säkerhetsaviseringar, som som standard visar aviseringar om beroendegenomsökning. Du kan filtrera efter gren, pipeline, paket och allvarlighetsgrad. Du kan välja i en avisering för mer information, inklusive reparationsvägledning. För närvarande visar inte aviseringshubben aviseringar för genomsökning som slutförts på PR-grenar.

När ett sårbart paket identifieras på lagringsplatsen innebär det vanligtvis att du uppgraderar till en högre paketversion eller tar bort ett felande paket när du åtgärdar aviseringar om beroendegenomsökning. Detta råd gäller för både direkta och transitiva (eller indirekta) beroenden. Standardvyn på fliken Avancerad säkerhet är aktiva aviseringar för standardgrenen för lagringsplatsen.

Resultatet påverkas inte om pipelines eller grenar byts namn – det kan ta upp till 24 timmar innan det nya namnet visas.

Skärmbild av aviseringsvyn för beroendegenomsökning för en lagringsplats

En aviserings tillstånd uppdateras automatiskt till Closed när den sårbara komponenten inte längre identifieras i den senaste versionen för pipelines där beroendegenomsökningsaktiviteten är installerad. Om du vill visa dina lösta aviseringar använder du State filtret i huvudverktygsfältet och väljer Closed.

Skärmbild av att visa aviseringar om stängd beroendegenomsökning

Om du inaktiverar Avancerad säkerhet för lagringsplatsen förlorar du åtkomsten till resultaten på fliken Avancerad säkerhet och byggaktiviteten. Byggaktiviteten misslyckas inte, men eventuella resultat från byggen körs med uppgiften medan Avancerad säkerhet är inaktiverad och behålls inte.

Aviseringsinformation

Du kan också öka detaljnivån för en avisering genom att klicka på en specifik avisering och reparationsvägledning.

Skärmbild som visar information om en avisering om beroendegenomsökning

Avsnitt	Förklaring
Rekommendation	Rekommendationstexten kommer direkt från vår leverantör av sårbarhetsdata, GitHub Advisory Database. Vägledningen föreslår vanligtvis att du uppgraderar den identifierade komponenten till en icke-vulnerbar version.
Plats	Avsnittet Platser beskriver sökvägarna där beroendegenomsökningsaktiviteten har identifierat den sårbara komponenten som används. Om filen kan matchas från den underliggande build-genomsökningen till en bekräftad fil i källan visas kortet Platser som en klickbar länk. Om en fil har skapats som en del av ett bygge (till exempel en byggartefakt) kan länken inte klickas. Granska byggloggarna för att bättre förstå hur komponenten togs med i bygget.
beskrivning	Beskrivningen tillhandahålls av GitHub Advisory-beskrivningen.

Upptäckter

Pipelines som visas under fliken Identifieringar är pipelines där den sårbara komponenten hittades. Varje rad beskriver den senaste versionen av den berörda pipelinen och det datum då paketet först introducerades. Om det sårbara paketet har åtgärdats i vissa pipelines men inte alla visas delvis fasta rader.

Skärmbild av identifieringsvyn för beroendegenomsökning för en avisering utan en korrigering

När en avisering har lösts flyttas aviseringen automatiskt till Closed tillståndet och den senaste körningspipelinen under fliken Identifieringar visar en grön bockmarkering, vilket innebär att kod som innehåller den uppdaterade komponenten kördes i pipelinen:

Skärmbild av identifieringsvyn för beroendegenomsökning för en avisering

Allvarlighet

GitHub Advisory Database tillhandahåller en CVSS-poäng som sedan översätts till en låg, medelhög, hög eller kritisk allvarlighetsgrad för en avisering via följande riktlinjer:

CVSS-poäng	Allvarlighet
1,0 < Poäng < 4,0	Låg
4,0 < Poäng < 7,0	Medium
7,0 < Poäng < 9,0	Högt
Poäng >= 9,0	Kritiskt

Hitta information

Två avsnitt finns ofta under Hitta information: sårbara paket och rotberoende. Det sårbara paketet är den potentiellt sårbara komponenten. Avsnittet rotberoende innehåller komponenter på den översta nivån som ansvarar för den beroendekedja som leder till en säkerhetsrisk.

Om det sårbara paketet bara refereras till som ett direkt beroende ser du bara avsnittet "sårbart paket".

Om det sårbara paketet refereras både som ett direkt och transitivt beroende visas paketet i både avsnittet "sårbart paket" och "rotberoende".

Om det sårbara paketet endast refereras till som ett transitivt beroende visas paketet i avsnittet "sårbart paket" och rotberoendena som refererar till det sårbara paketet visas i avsnittet "rotberoende".

Hantera aviseringar för beroendegenomsökning

Visa aviseringar för en lagringsplats

Alla med deltagarbehörigheter för en lagringsplats kan visa en sammanfattning av alla aviseringar för en lagringsplats i Repos>Advanced Security.

Som standard visar aviseringssidan resultat av beroendegenomsökning för lagringsplatsens standardgren.

Statusen för en avisering återspeglar tillståndet för standardgrenen och den senaste körningspipelinen, även om aviseringen finns på andra grenar och pipelines.

Åtgärda aviseringar om beroendegenomsökning

Ett direkt beroende är en komponent som du har i lagringsplatsen. Ett transitivt eller indirekt beroende är en komponent som används av ett direkt beroende. Ditt projekt är fortfarande sårbart oavsett om sårbarheten hittas i ett direkt eller transitivt beroende.

Att åtgärda ett sårbart transitivt beroende är vanligtvis i form av att uttryckligen åsidosätta den version av den sårbara komponenten som används för varje identifierat direkt beroende. När rotberoendena har uppgraderat sin användning av den sårbara komponenten till en säker version kan du uppgradera varje rotberoende i stället för flera enskilda åsidosättningar.

Uppdatera beroenden för Yarn/Npm

Anta hypotetiskt sett att det här paketet har två säkerhetsrisker. En är för axios, ett direkt beroende och ett är för acorn, ett transitivt beroende (även kallat indirekt beroende eller beroende av beroende).

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

Den aktuella versionen av axios har en DoS-säkerhetsrisk (Denial of Service) med en rekommendation att uppdatera till v0.18.1 eller senare. Eftersom det är ett direkt beroende har du kontroll över den version av axios som du använder. Allt du behöver göra är att uppdatera den version av axios som du hämtar. Den uppdaterade package.json ser ut ungefär så här:

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

Nu beror versionen av eslint i den package.json som visas på en version av acorn som är en säkerhetsrisk med reguljära uttryck för denial of service (ReDoS) med en rekommendation om att uppdatera till version 5.7.4, 6.4.1, 7.1.1 eller senare. Om du får en avisering från verktyget för beroendegenomsökning bör du få en beskrivning av rotberoendet som kräver det sårbara beroendet.

Garn

Om du använder Yarn kan du använda yarn why för att hitta den fullständiga beroendekedjan.

> $ 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.

Den fullständiga beroendekedjan är eslint>>espreeacorn. När du känner till beroendekedjan kan du använda en annan funktion i Yarn, selektiva beroendematchningar, för att åsidosätta den version av ekollon som används.

Använd fältet resolutioner i package.json för att definiera en åsidosättning av version. Tre olika metoder för att åsidosätta ett paket visas i den ordning som är sämst till bäst:

{
  "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 Om du använder mönstret åsidosätts alla användningar av ekollonpaketet över alla beroenden. Det är farligt, och bryta vid körning. Därför har den tagits bort i Yarn v2.

Med hjälp eslint/**/acorn av mönstret åsidosätts alla användningar av ekollonpaketet under eslint-paketet och i alla paket som det är beroende av. Det är säkrare än att åsidosätta paketet för alla beroenden, men det finns fortfarande vissa risker om beroendediagrammet för ett paket är stort. Det här mönstret rekommenderas när det finns många underpaket som använder ett sårbart paket och det skulle vara opraktiskt att definiera åsidosättningar för enskilda underpaket.

Om du använder mönstret eslint/espree/acorn åsidosätts endast användningen av acorn i espree paketet i eslint paketet. Den riktar sig specifikt till den sårbara beroendekedjan och är det rekommenderade sättet att åsidosätta paketversioner.

npm

Om du använder npm 8.3 eller senare kan du använda åsidosättningsfältet i din package.json

Lägg till en åsidosättning om du behöver göra specifika ändringar i transitiva beroenden. Du kan till exempel behöva lägga till en åsidosättning för att ersätta versionen av ett beroende med ett känt säkerhetsproblem, ersätta ett befintligt beroende med en förgrening eller se till att samma version av ett paket används överallt.

{
  "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"
        }
    }
   }
}

Åsidosättningsexemplet som visas visar npm:s sätt att säga "åsidosätt endast användningen av acorn i espree paketet i eslint paketet". Den riktar sig specifikt till den sårbara beroendekedjan och är det rekommenderade sättet att åsidosätta paketversioner. Åsidosättningar är en inbyggd funktion i npm. Det ger ett sätt att ersätta ett paket i beroendeträdet med en annan version, eller ett annat paket helt och hållet.

När du har angett åsidosättningar måste du ta bort package-lock.json och node_modules köra npm install igen.

Du kan inte ange en åsidosättning för ett paket som du är direkt beroende av om inte både beroendet och själva åsidosättningen delar exakt samma specifikation. Anta till exempel att axios: "0.18.0" det är sårbart och att vi vill uppgradera till axios: "0.19.2". Ändra beroendeversionen direkt i stället för att använda åsidosättning.

{
  "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",
  }
}

Uppdatera beroendets version utan att ange en åsidosättning:

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

Uppdatera beroenden för Maven

Mekanismen för beroendematchning är inte lika avancerad som den som används i Yarn. Därför kan du bara ha en enda version av ett beroende i ett projekt. För att lösa problemet använder Maven en algoritm för "närmaste vinster". Den använder alltså den version av det närmaste beroendet till projektet i beroendeträdet.

Du har till exempel följande beroendediagram:

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

your-project beror på A:1.0.0, vilket i sin tur beror på B:2.0.0 men projektet har också ett direkt beroende av B:1.0.0. Du har alltså två olika versioner av beroende B i beroendediagrammet, men version 1.0.0 av beroende B vinner eftersom den är "närmast" ditt projekt.

I vissa fall kan det här scenariot fungera om versionerna är kompatibla. Men om A:1.0.0 det är beroende av någon funktion i B som bara är tillgänglig i versionen 2.0.0 så fungerar inte det här beteendet. I värsta fall kan det här projektet fortfarande kompileras men misslyckas vid körning.

Låt oss ta en titt på ett verkligt exempel.

<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>

Anta att versionen av dig är beroende av com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider en version av com.fasterxml.jackson.core:jackson-databind som har en deserialisering av ej betrodda datasårbarhet.

Du kan verifiera det här beroendet med hjälp av plugin-programmet för Maven-beroende. I det här fallet skulle du köra mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind och hämta följande utdata:

> $ 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] ------------------------------------------------------------------------

Kontrollera först om det finns en ny version av som inte är beroende av com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider en sårbar version av com.fasterxml.jackson.core:jackson-databind. I så fall kan du uppgradera com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider och stanna där. Annars åsidosätter du versionen av com.fasterxml.jackson.core:jackson-databind.

Som visas i kodfragmentet, när du använder Maven "närmaste vinner", så lösningen är att lägga till ett direkt beroende till com.fasterxml.jackson.core:jackson-databind som åtgärdar säkerhetsrisken.

<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>

Du kan kontrollera att lösningen fungerar genom att köra mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind igen.

$ 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] ------------------------------------------------------------------------

Vi rekommenderar att du lägger till en kommentar nära beroendelösningen, så att alla som kommer senare vet varför beroendet finns där. Den kan tas bort när rotberoendet använder den nya versionen. Annars ackumulerar du beroenden.

I ett verkligt projekt lägger du till beroendet så högt upp i kedjan som möjligt. Du kan till exempel lägga till upplösningen i den överordnade POM-filen i stället för individuellt i varje pom-projektfil.

Uppdatera beroenden för NuGet

Beroendematchningsalgoritmen som används i NuGet liknar Maven, eftersom endast en enda version av ett beroende kan användas. NuGet fäster dock inte beroendeversioner.

Om du till exempel har ett beroende <PackageReference Include="A" Version="1.2.3" />kan du förvänta dig att det här paketet motsvarar = 1.2.3, men det betyder >= 1.2.3faktiskt . För att fästa en exakt version bör du använda Version="[1.2.3]". Mer information finns i dokumentationen om NuGet-versionsintervall.

Förutom standardintervallbeteendet återställer NuGet den lägsta tillämpliga versionen för att uppfylla ett intervall. Det här beteendet innebär att du i många fall måste definiera ett intervall.

Nu ska vi ta en titt på det här exempelprojektet, som har ett beroende av 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>

Det beror på en version av Microsoft.AspNetCore.Http.Connections som är sårbar för en fjärrkodkörning (RCE).

Först bör du kontrollera om det finns en uppdaterad version av som är beroende av Microsoft.AspNetCore.App en nyare version av Microsoft.AspNetCore.Http.Connections. I så fall kan du uppgradera Microsoft.AspNetCore.App och stoppa här. Annars måste du åsidosätta den version av den som är beroende av Microsoft.AspNetCore.Http.Connections .

NuGet har inte någon motsvarighet till yarn why eller mvn dependency:tree built-in, så det enklaste sättet att se beroendeträdet är ofta att besöka nuget.org. Om du besöker NuGet-sidan för Microsoft.AspNetCore.Appser du att det beror på Microsoft.AspNetCore.Http.Connections version >= 1.0.4 && < 1.1.0. Eller i ett NuGet-versionsintervall är [1.0.4,1.1.0)den representativa syntaxen .

RCE-sårbarheten i Microsoft.AspNetCore.Http.Connections har åtgärdats i version 1.0.15, så du måste åsidosätta versionsintervallet[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>

Vi rekommenderar att du lägger till en kommentar nära beroendelösningen så att alla som kommer senare vet varför beroendet finns där. Det kan tas bort när rotberoendet använder den nya versionen. Annars ackumulerar du beroenden.

Vad händer om det inte finns någon korrigering tillgänglig?

När ingen känd korrigering är tillgänglig är följande alternativ tillgängliga som andra reparationsmetoder tills en uppgraderad komponent är tillgänglig:

Sluta använda komponenten och ta bort den från koden – den här borttagningen identifieras vid nästa version med beroendegenomsökningsuppgiften installerad
Bidra med en korrigering av själva komponenten. Om din organisation har specifika riktlinjer för bidrag med öppen källkod följer du dessa riktlinjer.
Stäng aviseringen. Aviseringar utan känd korrigering kan dock utgöra ett säkerhetshot mot din organisation. Vi rekommenderar att du inte avvisar en avisering bara för att det inte finns någon känd korrigering.

Stäng aviseringar om beroendegenomsökning

Om du vill stänga aviseringar i Avancerad säkerhet behöver du rätt behörigheter. Som standard är det bara projektadministratörer som har möjlighet att stänga av avancerade säkerhetsaviseringar.

Så här stänger du en avisering:

Gå till aviseringen som du vill stänga och välj i aviseringen
Välj listrutan Stäng avisering
Om du inte redan har valt väljer du antingen Risk accepterad eller Falsk positiv som stängningsorsak
Lägg till en valfri kommentar i textrutan Kommentar
Välj Stäng för att skicka och stänga aviseringen
Aviseringstillståndet ändras från Öppna till Stängd och visar orsaken till uppsägningen

Skärmbild som visar hur du stänger en avisering om beroendegenomsökning

Den här åtgärden stänger bara aviseringen för den valda grenen. Andra grenar som kan innehålla samma säkerhetsrisk förblir aktiva tills andra åtgärder har vidtagits. Alla aviseringar som tidigare har stängts kan öppnas manuellt.

Hantera aviseringar om beroendegenomsökning vid pull-begäranden

Om aviseringar skapas för nya kodändringar i en pull-begäran rapporteras aviseringen som en kommentar i kommentarsavsnittet för fliken Översikt i pull-begäran och som en avisering på fliken Advanced Security-lagringsplats. Det finns en ny post för grenväljaren för pull-begärandegrenen.

Du kan se det berörda paketmanifestet, se en sammanfattning av sökningen och lösa kommentaren i avsnittet Översikt.

Om du vill avvisa pull-begärandeaviseringar måste du gå till aviseringsvyn för att stänga både aviseringen och lösa anteckningen. Annars löser bara ändring av kommentarsstatus (1) anteckningen men stänger eller åtgärdar inte den underliggande aviseringen.

Om du vill se hela resultatuppsättningen för din pull-begärandegren går du till Repos>Advanced Security och väljer grenen för pull-begäran. Om du väljer Visa mer information (2) i kommentaren dirigeras du till aviseringsinformationsvyn på fliken Avancerad säkerhet.

Dricks

Anteckningar skapas endast när de berörda kodraderna är helt unika för skillnaden i pull-begäran jämfört med målgrenen för pull-begäran.

Dela via