Konfigurera beroendegenomsökning

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. Du behöver antingen GitHub Advanced Security för Azure DevOps eller, om du använder den fristående upplevelsen, GitHub Code Security för Azure DevOps aktiverat.

GitHub Advanced Security för Azure DevOps fungerar med Azure-lagringsplatser. Information om hur du använder GitHub Advanced Security med GitHub-lagringsplatser finns i GitHub Advanced Security.

Förutsättningar

Kategori	Krav
behörigheter	- Så här visar du en sammanfattning av alla aviseringar för en lagringsplats: Deltagare behörigheter för lagringsplatsen. – Så här stänger du aviseringar i Avancerad säkerhet: Projektadministratör behörigheter. – För att hantera behörigheter i Avancerad säkerhet: Medlem i Project Collection-administratörer-gruppen, eller Avancerad säkerhet: hantera inställningar -behörighet inställd på Tillåt.
Pipelineaktiviteter	– I Organisationsinställningar>>> säkerställer du att Inaktivera Marketplace-aktiviteter är avstängt. Kodgenomsökning och beroendegenomsökning förlitar sig på Azure-pipelines uppgifter som distribueras via Visual Studio Marketplace. Om du inaktiverar Marketplace-aktiviteter kan standardkonfiguration inte köra skanningar, och pipelines för avancerad konfiguration kan rapportera att en aktivitet saknas. Mer information finns i Uppgiftshantering.

Kategori

Krav

behörigheter

- Så här visar du en sammanfattning av alla aviseringar för en lagringsplats: Deltagare behörigheter för lagringsplatsen.
– Så här stänger du aviseringar i Avancerad säkerhet: Projektadministratör behörigheter.
– För att hantera behörigheter i Avancerad säkerhet: Medlem i Project Collection-administratörer-gruppen, eller Avancerad säkerhet: hantera inställningar -behörighet inställd på Tillåt.

Pipelineaktiviteter

– I Organisationsinställningar>>> säkerställer du att Inaktivera Marketplace-aktiviteter är avstängt. Kodgenomsökning och beroendegenomsökning förlitar sig på Azure-pipelines uppgifter som distribueras via Visual Studio Marketplace. Om du inaktiverar Marketplace-aktiviteter kan standardkonfiguration inte köra skanningar, och pipelines för avancerad konfiguration kan rapportera att en aktivitet saknas. Mer information finns i Uppgiftshantering.

Mer information om avancerade säkerhetsbehörigheter finns i Hantera avancerade säkerhetsbehörigheter.

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.

Lär dig mer om upptäckning vid 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. För mer information om alertdetaljer, se Fixing beroendeskanningsaviseringar.

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.

Note

Beroendegenomsökning kräver att du kör en pipeline som konfigurerats med AdvancedSecurity-Dependency-Scanning@1 uppgiften eller kör en pipeline på en lagringsplats med standardinställningen för beroendegenomsökning aktiverad. Aktivering av Avancerad säkerhet eller Kodsäkerhet kör inte beroendegenomsökning automatiskt.

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

Lär dig mer 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, allvarlighetsgrad, beroendeomfång och EPSS-percentil (Exploit Prediction Scoring System). Du kan välja en varning för mer information, inklusive åtgärdsvägledning. För närvarande visas inte aviseringar för slutförd genomsökning på PR-avdelningar i varningscentralen.

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.

Prioritera aviseringar efter beroendeomfång

Beroendeomfång anger om ett sårbart beroende används vid körning eller endast under utveckling. På sidan Aviseringar använder du filtret Scope för enkelval för att visa beroendeaviseringar för Runtime eller Development.

Utvecklingsberoenden visas med märket Development i varningslistan. Aviseringsinformation visar även beroendeomfånget när genomsökningsresultatet innehåller dessa metadata. Om omfångsmetadata inte är tillgängliga utelämnar Advanced Security märkes- och omfångsinformationen utan att ändra aviseringens andra beteende.

Omfånget gäller för det specifika beroenderesultatet, inte för paketet globalt. Samma paket kan ha ett annat omfång när det identifieras i en annan beroendesökväg eller ett annat projekt.

Prioritera aviseringar med EPSS

Exploit Prediction Scoring System (EPSS) uppskattar sannolikheten för att en sårbarhet i programvaran kommer att utnyttjas i naturen. EPSS ger ett poängvärde och en percentil; Avancerad säkerhet visar percentilen för varningar om skanning av beroenden. En högre percentil anger att sårbarheten rankas högre för sannolikheten för förutsagt utnyttjande i förhållande till andra säkerhetsrisker.

Använd EPSS-percentil tillsammans med allvarlighetsgrad när du prioriterar reparation. Allvarlighetsgraden återspeglar den potentiella effekten av en säkerhetsrisk, medan EPSS hjälper dig att bedöma hur sannolikt utnyttjandet är. På sidan Aviseringar använder du EPSS-percentilfiltret för att ange ett percentilintervall och fokusera på beroendeaviseringar som uppfyller intervallet. Intervallgränserna är inkluderande och kombineras med andra filter som du tillämpar.

EPSS-percentilfiltret grupperar sårbarheter i följande kategorier:

EPSS-percentilen	Kategori
90-100%	Mycket hög
70-90%	Högt
50-70%	Medel
0–50%	Låg

EPSS-data är inte tillgängliga för varje rådgivning. När en avisering inte har EPSS-metadata visar Advanced Security inte EPSS-percentilen i aviseringsinformationen. Saknade metadata påverkar inte aviseringens allvarlighetsgrad, tillstånd eller reparationsvägledning.

En aviseringsstatus uppdateras automatiskt till Closed när den sårbara komponenten inte längre detekteras i den senaste kompileringen för några pipelines där beroendeskanningsuppgiften är installerad. Om du vill visa dina lösta aviseringar använder du State filtret i huvudverktygsfältet och väljer Closed.

Om du inaktiverar Avancerad säkerhet för lagringsplatsen förlorar du åtkomsten till resultaten på fliken Avancerad säkerhet och byggaktiviteten. Byggaktiviteter misslyckas inte, men resultaten från de byggen som körs med uppgiften medan Avancerad säkerhet är inaktiverad, är dolda och sparas inte.

Aviseringsinformation

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

Avsnitt	Förklaring
Scope	Omfattningen anger om det sårbara beroendet används vid körning eller endast under utveckling. Den här informationen visas bara när metadata för beroendeomfång är tillgängliga för resultatet.
EPSS-percentilen	EPSS-percentilen anger hur sårbarheten rangordnas för förväntad sannolikhet för utnyttjande i förhållande till andra säkerhetsrisker. Den här raden visas bara när EPSS-metadata är tillgängliga för rådgivningen.
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 identifierar den sårbara komponent 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 åtgärdade rader.

När en avisering har lösts flyttas aviseringen automatiskt till Closed-tillståndet, och den senaste pipeline för körning under fliken Identifieringar visar en grön bockmarkering, vilket innebär att kod med den uppdaterade komponenten kördes i den pipelinen.

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

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

Statusen för en varning återspeglar tillståndet för huvudgrenen och den senaste körningen i pipelinen, även om varningen existerar på andra grenar och pipelines.

Automatisk rensning av varningar från inaktuella pipeline-konfigurationer

Automatisk rensning döljer gamla genomsökningsresultat när deras pipelinekonfigurationer slutar köras. Den döljer inte en varning bara för att varningen eller dess gren är mer än 90 dagar gammal. Det här beteendet gäller för aviseringar om kodgenomsökning och beroendegenomsökning.

Vad gör en konfiguration inaktuell?

Rensningen använder den senaste slutförandetiden för pipelinefasen som är associerad med en genomsökningskonfiguration. En fas blir inaktuell när slutförandetidpunkten är mer än 90 dagar sedan, som standard.

Advanced Security markerar pipelinefasposten som inaktiv men behåller sina resultat. Sedan döljer aviseringsvyn endast en avisering när alla senaste resultat som är associerade med aviseringen kommer från inaktuella konfigurationer. Om något av dessa resultat kommer från en aktiv konfiguration kan aviseringen fortfarande visas.

Datum eller aktivitet	Används för den 90 dagar långa rensningen?
När aviseringen först upptäcktes	No
När varningen senast upptäcktes	No
När grenen senast skannades	Inte självständigt. Cleanup spårar den associerade pipelinefasen, som kan delas mellan grenar.
Den associerade pipelinefasens senaste slutförandetid	Yes

Varför kan en gammal grenavkänning förbli synlig eller visas igen?

Olika grenar kan dela samma pipelinefasaktivitetspost. När den fasen körs igen på en annan gren uppdaterar Advanced Security sin slutförandetid och återaktiverar de associerade konfigurationerna. Därför kan äldre identifierade problem på en gren som inte har körts nyligen förbli synliga eller visas igen.

Tänk till exempel på den här sekvensen:

En pipelinefas identifierar en säkerhetsrisk på develop.
Den fasen körs inte på någon gren som är äldre än 90 dagar. När rensningen markerar den som inaktiv döljer Advanced Security aviseringen om den inte har några senaste resultat från andra aktiva konfigurationer.
Samma fas körs på feature/update-build. Advanced Security återaktiverar sina associerade konfigurationer så att den äldre develop identifieringen kan visas igen.

Körningen på feature/update-build genomsöker inte develop. Den ändrar aktivitetsstatusen för den delade pipelinefasen, som styr om Advanced Security visar det äldre resultatet.

Därför kan en avisering visas med ett gammalt datum för första eller senaste förekomst. Dessa datum beskriver detekteringen på grenen, inte pipelinefasens aktivitetsstatus. Att återaktivera konfigurationen gör varken det äldre resultatet till en ny identifiering eller kräver att det ursprungliga datumet då det först upptäcktes ändras.

Vad ska du kontrollera?

När ett gammalt identifierat problem förblir synligt granskar du körningar av samma pipelinefas i olika grenar, inte bara grenen som visas i aviseringen. Om du vill kontrollera om sårbarheten fortfarande finns på den grenen kör du en genomsökning på den grenen.

Important

Automatisk rensning döljer resultat. Den åtgärdar inte säkerhetsrisken eller avfärdar inte aviseringen. Om den associerade konfigurationen blir aktiv igen kan tidigare dolda öppna varningar returneras som öppna varningar.

Å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 uppgraderar 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 visade på en version av acorn som är ett reguljärt uttryck denial of service, "Re-DoS", sårbarhet med en rekommendation att uppdatera till version 5.7.4, 6.4.1, 7.1.1 eller högre. 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>espree>acorn. 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 bryts vid körning, så vi tog bort det 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 overrides-fä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 åsidosä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 dina åsidosättningar måste du ta bort package-lock.json och node_modules och kör npm install igen.

Du kanske inte anger 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 beroendelösning är inte lika sofistikerad 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 com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider som du är beroende av, är beroende av en version av com.fasterxml.jackson.core:jackson-databind som har en sårbarhet för deserialisering av ej betrodd data.

Du kan verifiera det här beroendet med hjälp av Maven beroendeplugin. 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 com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider som inte är beroende av 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ätts versionen av com.fasterxml.jackson.core:jackson-databind.

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

<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 låser 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 Microsoft.AspNetCore.App som är beroende av 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 Microsoft.AspNetCore.Http.Connections som den är beroende av.

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.Connectionsversion >= 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.
Avfärda 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

Gör följande för att stänga en avisering:

Gå till den avisering som du vill stänga och välj 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.

Den här åtgärden avvisar aviseringen för alla filialer. Andra grenar som innehåller samma säkerhetsrisk kommer också att stängas. Alla aviseringar som tidigare avvisats kan öppnas manuellt.

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

Om aviseringar skapas för nya kodändringar i en pull-förfrågan rapporteras aviseringen som en anmärkning i kommentarsavsnittet för fliken Översikt och som en avisering på fliken för Advanced Security i lagringsplatsen. En ny post för grenväljaren är tillgänglig för grenen för pull-förfrågan.

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.

Tips

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

Feedback

Var den här sidan till hjälp?

Uppdaterades senast 2026-10-12