Scannen op afhankelijkheden

Met afhankelijkheidsscans in GitHub Advanced Security voor Azure DevOps worden de opensource-onderdelen gedetecteerd die in uw broncode worden gebruikt en worden gedetecteerd of er beveiligingsproblemen zijn. Eventuele gevonden beveiligingsproblemen van opensource-onderdelen worden gemarkeerd als een waarschuwing.

GitHub Advanced Security voor Azure DevOps werkt met Azure-opslagplaatsen. Als u GitHub Advanced Security wilt gebruiken met GitHub-opslagplaatsen, raadpleegt u GitHub Advanced Security.

Over het scannen van afhankelijkheden

Met afhankelijkheidsscans wordt een waarschuwing gegenereerd voor elk opensource-onderdeel, direct of transitief, waarvan blijkt dat uw code afhankelijk is. Directe beveiligingsproblemen zijn de bibliotheken die uw code rechtstreeks gebruikt. Transitieve afhankelijkheden zijn de bibliotheken of andere software die afhankelijkheden direct gebruiken.

Detectie van afhankelijkheidsscans

Er wordt een nieuwe momentopname van uw onderdelen opgeslagen wanneer de afhankelijkheidsgrafiek voor een opslagplaats wordt gewijzigd en nadat een pijplijn met de afhankelijkheidsscantaak voor het bouwen van nieuwe code (met andere woorden, een nieuwe doorvoer) is uitgevoerd.

Voor elk kwetsbaar onderdeel dat in gebruik is gedetecteerd, worden het onderdeel en beveiligingsprobleem vermeld in het buildlogboek en weergegeven als een waarschuwing op het tabblad Geavanceerde beveiliging. Alleen adviezen die door GitHub worden gecontroleerd en toegevoegd aan de GitHub Advisory Database , maken een waarschuwing voor het scannen van afhankelijkheden. Het buildlogboek bevat een koppeling naar de afzonderlijke waarschuwing voor verder onderzoek. Zie Waarschuwingen voor het scannen van afhankelijkheden herstellen voor meer informatie over de details van de waarschuwing.

Het buildlogboek bevat ook basisinformatie over elk gedetecteerd beveiligingsprobleem. Deze details omvatten de ernst, het betrokken onderdeel, de titel van het beveiligingsprobleem en de bijbehorende CVE.

Ondersteunde pakketecosystemen

Afhankelijkheidsscans ondersteunen zowel directe als transitieve afhankelijkheden voor alle ondersteunde pakketecosystemen.

Pakketbeheer	Talen	Ondersteunde indelingen
Vracht	Rust	Cargo.toml, Cargo.lock
CocoaPods	Swift	Podfile.lock
Go-modules	Go	go.mod, go.sum
Gradle	Java	*.lockfile
Maven	Java	pom.xml
npm	JavaScript	package-lock.json, , , package.jsonnpm-shrinkwrap.jsonlerna.json
NuGet	C#	*.packages.config, , *.project.assets*.csproj
pit	Python	setup.py, requirements.txt
pnpm	JavaScript	package.json
RubyGems	Ruby	Gemfile.lock
Garen	JavaScript	package.json

Waarschuwingen voor het scannen van afhankelijkheden

Het tabblad Geavanceerde beveiliging in Opslagplaatsen in Azure DevOps is de hub om uw beveiligingswaarschuwingen weer te geven, die standaard waarschuwingen voor het scannen van afhankelijkheden weergeeft. U kunt filteren op vertakking, pijplijn, pakket en ernst. U kunt een waarschuwing selecteren voor meer informatie, inclusief herstelrichtlijnen. Op dit moment worden in de waarschuwingenhub geen waarschuwingen weergegeven voor het scannen op pull-vertakkingen.

Wanneer een kwetsbaar pakket wordt gedetecteerd in uw opslagplaats, moet u afhankelijkheidsscanwaarschuwingen meestal upgraden naar een hogere pakketversie of een offending-pakket verwijderen. Dit advies geldt zowel voor directe als transitieve (of indirecte) afhankelijkheden. De standaardweergave op het tabblad Geavanceerde beveiliging is actieve waarschuwingen voor de standaardbranch voor uw opslagplaats.

Er is geen effect op resultaten als de naam van pijplijnen of vertakkingen is gewijzigd. Het kan tot 24 uur duren voordat de nieuwe naam wordt weergegeven.

De status van een waarschuwing wordt automatisch bijgewerkt Closed wanneer het kwetsbare onderdeel niet meer wordt gedetecteerd in de nieuwste build voor pijplijnen waarop de afhankelijkheidsscantaak is geïnstalleerd. Als u uw opgeloste waarschuwingen wilt weergeven, gebruikt u het State filter op de hoofdwerkbalk en selecteert u Closed.

Als u Geavanceerde beveiliging voor uw opslagplaats uitschakelt, verliest u de toegang tot de resultaten op het tabblad Geavanceerde beveiliging en de build-taak. De build-taak mislukt niet, maar eventuele resultaten van builds worden uitgevoerd met de taak terwijl Advanced Security is uitgeschakeld, worden verborgen en blijven niet behouden.

Meldingsdetails

U kunt ook inzoomen op details over een waarschuwing door te klikken op een specifieke waarschuwing en hulp bij herstel.

Sectie	Uitleg
Aanbeveling	De aanbevelingstekst is rechtstreeks afkomstig van onze provider voor gegevens over beveiligingsproblemen, de GitHub Advisory Database. Normaal gesproken wordt in de richtlijnen voorgesteld om het geïdentificeerde onderdeel te upgraden naar een niet-bevulnerbare versie.
Locatie	In de sectie Locaties worden de paden beschreven waarin de afhankelijkheidsscantaak het kwetsbare onderdeel in gebruik heeft ontdekt. Als het bestand kan worden omgezet vanuit de onderliggende buildscan naar een vastgelegd bestand in de bron, wordt de kaart Locaties weergegeven als een klikbare koppeling. Als een bestand is gemaakt als onderdeel van een build (bijvoorbeeld een buildartefact), kan de koppeling niet worden geklikt. Bekijk de buildlogboeken om beter te begrijpen hoe het onderdeel in de build is gebracht.
Beschrijving	De beschrijving wordt geleverd door de GitHub Advisory-beschrijving.

Detecties

De pijplijnen die worden vermeld op het tabblad Detecties , zijn de pijplijnen waar het kwetsbare onderdeel is gevonden. Elke rij bevat de meest recente build van de betrokken pijplijn en de datum waarop het pakket voor het eerst werd geïntroduceerd. Als het kwetsbare pakket is opgelost in sommige pijplijnen, maar niet alle, ziet u gedeeltelijk vaste rijen.

Zodra een waarschuwing is opgelost, wordt de waarschuwing automatisch verplaatst naar de Closed status en geeft de meest recente uitvoeringspijplijn op het tabblad Detecties een groen vinkje weer, wat betekent dat code met het bijgewerkte onderdeel in die pijplijn is uitgevoerd:

Ernst

De GitHub Advisory Database biedt een CVSS-score, die vervolgens wordt omgezet in een lage, gemiddelde, hoge of kritieke ernst voor een waarschuwing via de volgende richtlijnen:

CVSS-score	Ernst
1.0 < Score < 4.0	Beperkt
4.0 < Score < 7.0	Gemiddeld
7.0 < Score < 9.0	Hoog
Score >= 9,0	Kritiek

Details zoeken

Er zijn twee secties te vinden onder Details zoeken: kwetsbaar pakket en hoofdafhankelijkheid. Het kwetsbare pakket is het potentieel kwetsbare onderdeel. De sectie hoofdafhankelijkheid bevat onderdelen op het hoogste niveau die verantwoordelijk zijn voor de afhankelijkheidsketen die leiden tot een beveiligingsprobleem.

Als het kwetsbare pakket alleen wordt verwezen als een directe afhankelijkheid, ziet u alleen de sectie 'kwetsbaar pakket'.

Als naar het kwetsbare pakket wordt verwezen als een directe en transitieve afhankelijkheid, wordt het pakket weergegeven in zowel de sectie 'kwetsbaar pakket' als 'hoofdafhankelijkheid'.

Als er alleen naar het kwetsbare pakket wordt verwezen als transitieve afhankelijkheid, wordt het pakket weergegeven in de sectie 'kwetsbaar pakket' en worden de hoofdafhankelijkheden die verwijzen naar het kwetsbare pakket weergegeven in de sectie 'hoofdafhankelijkheid'.

Waarschuwingen voor het scannen van afhankelijkheden beheren

Waarschuwingen voor een opslagplaats weergeven

Iedereen met inzendermachtigingen voor een opslagplaats kan een overzicht bekijken van alle waarschuwingen voor een opslagplaats in Opslagplaatsen>Advanced Security.

Op de pagina Waarschuwingen worden standaard resultaten weergegeven voor het scannen van afhankelijkheden voor de standaardbranch van de opslagplaats.

De status van een waarschuwing weerspiegelt de status van de standaardbranch en de meest recente uitvoeringspijplijn, zelfs als de waarschuwing bestaat op andere vertakkingen en pijplijnen.

Waarschuwingen voor het scannen van afhankelijkheden oplossen

Een directe afhankelijkheid is een onderdeel dat u in uw opslagplaats hebt. Een transitieve of indirecte afhankelijkheid is een onderdeel dat wordt gebruikt door een directe afhankelijkheid. Uw project is nog steeds kwetsbaar, ongeacht of het beveiligingsprobleem zich in een directe of transitieve afhankelijkheid bevindt.

Het oplossen van een kwetsbare transitieve afhankelijkheid bestaat meestal uit het expliciet overschrijven van de versie van het kwetsbare onderdeel dat wordt gebruikt voor elke geïdentificeerde directe afhankelijkheid. Zodra de hoofdafhankelijkheden het gebruik van het kwetsbare onderdeel hebben bijgewerkt naar een veilige versie, kunt u elke hoofdafhankelijkheid upgraden in plaats van meerdere afzonderlijke onderdrukkingen.

Afhankelijkheden voor Yarn/Npm bijwerken

Hypothetisch zeggen dat dit pakket twee beveiligingsproblemen heeft. Een is voor axios, een directe afhankelijkheid en een is voor acorn, een transitieve afhankelijkheid (ook wel een indirecte afhankelijkheid of afhankelijkheid van afhankelijkheid genoemd).

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

De huidige versie van axios het bestand heeft een DoS-beveiligingsprobleem (Denial of Service) met een aanbeveling om bij te werken naar v0.18.1 of hoger. Omdat het een directe afhankelijkheid is, hebt u controle over de versie van axios die u gebruikt. U hoeft alleen maar de versie bij axios te werken die u ophaalt. De bijgewerkte package.json ziet er ongeveer als volgt uit:

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

Nu is de versie van eslint de package.json weergegeven versie afhankelijk van een versie van acorn die een redoS-beveiligingsprobleem (Regular Expression Denial of Service) met een aanbeveling om bij te werken naar versie 5.7.4, 6.4.1, 7.1.1 of hoger. Als u een waarschuwing krijgt van het hulpprogramma voor het scannen van afhankelijkheden, moet u de hoofdafhankelijkheid vertellen waarvoor de kwetsbare afhankelijkheid is vereist.

Garen

Als u Yarn gebruikt, kunt u yarn gebruiken om de volledige afhankelijkheidsketen te vinden.

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

De volledige afhankelijkheidsketen is eslintacorn>espree>. Zodra u de afhankelijkheidsketen kent, kunt u een andere functie van Yarn, selectieve afhankelijkheidsresoluties, gebruiken om de versie van acorn te overschrijven die wordt gebruikt.

Gebruik het oplossingsveld om package.json een versieoverschrijven te definiëren. Er worden drie verschillende methoden weergegeven om een pakket te overschrijven, in volgorde van slechtste tot het beste:

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

Als u het**/acorn patroon gebruikt, worden alle gebruiksrechten van het acorn-pakket over alle afhankelijkheden overschreven. Het is gevaarlijk en breken tijdens runtime. Als gevolg hiervan is het verwijderd in Yarn v2.

Als u het eslint/**/acorn patroon gebruikt, worden alle gebruiksrechten van het acorn-pakket onder het eslint-pakket overschreven en in alle pakketten waarvan het afhankelijk is. Het is veiliger dan het pakket te overschrijven voor alle afhankelijkheden, maar het heeft nog steeds enkele risico's als de afhankelijkheidsgrafiek voor een pakket groot is. Dit patroon wordt aanbevolen wanneer er veel subpackages zijn die een kwetsbaar pakket gebruiken en onderdrukkingen definiëren voor afzonderlijke subpakketten onpraktisch zijn.

Als u het patroon eslint/espree/acorn gebruikt, wordt alleen het gebruik van acorn het espree pakket in het eslint pakket overschreven. Het is specifiek gericht op de kwetsbare afhankelijkheidsketen en is de aanbevolen manier om pakketversies te overschrijven.

npm

Als u npm 8.3 of hoger gebruikt, kunt u het veld onderdrukkingen in uw package.json

Voeg een onderdrukking toe als u specifieke wijzigingen wilt aanbrengen in transitieve afhankelijkheden. U moet bijvoorbeeld een onderdrukking toevoegen om de versie van een afhankelijkheid te vervangen door een bekend beveiligingsprobleem, een bestaande afhankelijkheid vervangen door een fork of ervoor zorgen dat dezelfde versie van een pakket overal wordt gebruikt.

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

In het getoonde voorbeeld van onderdrukking ziet u hoe npm 'alleen het gebruik van acorn het pakket in het espree eslint pakket overschrijven'. Het is specifiek gericht op de kwetsbare afhankelijkheidsketen en is de aanbevolen manier om pakketversies te overschrijven. Onderdrukkingen zijn een systeemeigen functie van npm. Het biedt een manier om een pakket in uw afhankelijkheidsstructuur te vervangen door een andere versie of een ander pakket volledig.

Nadat u de onderdrukkingen hebt ingesteld, moet u uw package-lock.json en node_modules opnieuw uitvoeren npm install .

U mag geen onderdrukking instellen voor een pakket waarvoor u rechtstreeks afhankelijk bent, tenzij zowel de afhankelijkheid als de onderdrukking zelf exact dezelfde specificatie delen. Stel dat we axios: "0.18.0" kwetsbaar zijn en we willen upgraden naar axios: "0.19.2". U kunt de versie van de afhankelijkheid rechtstreeks wijzigen in plaats van onderdrukking te gebruiken.

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

Werk de versie van de afhankelijkheid bij zonder een onderdrukking in te stellen:

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

Afhankelijkheden voor Maven bijwerken

Het mechanisme voor afhankelijkheidsoplossing is niet zo geavanceerd als het mechanisme dat in Yarn wordt gebruikt. Als gevolg hiervan kunt u slechts één versie van een afhankelijkheid in een project hebben. Om dit probleem op te lossen, gebruikt Maven een algoritme voor 'dichtstbijzijnde overwinningen'. Dat wil gezegd, wordt de versie van de dichtstbijzijnde afhankelijkheid voor uw project gebruikt in de structuur van afhankelijkheden.

U hebt bijvoorbeeld de volgende afhankelijkheidsgrafiek:

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

your-projectA:1.0.0hangt af van , wat op zijn beurt afhankelijk is B:2.0.0 van, maar uw project ook een directe afhankelijkheid B:1.0.0heeft . U hebt dus twee verschillende versies van afhankelijkheid B in uw afhankelijkheidsgrafiek, maar versie 1.0.0 van afhankelijkheid B wint omdat deze het dichtst bij uw project ligt.

In sommige gevallen kan dit scenario werken als de versies compatibel zijn. A:1.0.0 Als dit echter afhankelijk is van een bepaalde functie van B die alleen beschikbaar is in versie2.0.0, werkt dit gedrag niet. In het slechtste geval kan dit project nog steeds worden gecompileerd, maar mislukt dit tijdens runtime.

Laten we eens kijken naar een praktijkvoorbeeld.

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

Stel dat de versie van u afhankelijk is van com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider een versie met com.fasterxml.jackson.core:jackson-databind een deserialisatie van niet-vertrouwde gegevensproblemen.

U kunt deze afhankelijkheid controleren met behulp van de Maven-invoegtoepassing voor afhankelijkheden. In dit geval voert u de volgende uitvoer uit 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] ------------------------------------------------------------------------

Controleer eerst of er een nieuwe versie van com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider die niet afhankelijk is van een kwetsbare versie van com.fasterxml.jackson.core:jackson-databind. Zo ja, dan kunt u daar upgraden com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider en stoppen. Als dat niet het is, overschrijf dan de versie van com.fasterxml.jackson.core:jackson-databind.

Zoals wordt weergegeven in het codefragment, wordt bij het gebruik van Maven de dichtstbijzijnde wins gebruikt, dus de oplossing is het toevoegen van een directe afhankelijkheid aan com.fasterxml.jackson.core:jackson-databind dat het beveiligingsprobleem oplost.

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

U kunt controleren of de oplossing werkt door opnieuw te worden uitgevoerd 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] ------------------------------------------------------------------------

Het is raadzaam om een opmerking toe te voegen in de buurt van de afhankelijkheidsoplossing, zodat iedereen die later komt weet waarom de afhankelijkheid er is. Deze kan worden verwijderd zodra de hoofdafhankelijkheid gebruikmaakt van de nieuwe versie; anders verzamelt u afhankelijkheden.

Voeg in een echt project de afhankelijkheid zo hoog mogelijk toe aan de keten. U kunt bijvoorbeeld de resolutie toevoegen in het bovenliggende POM-bestand in plaats van afzonderlijk in elk PROJECT POM-bestand.

Afhankelijkheden voor NuGet bijwerken

Het algoritme voor afhankelijkheidsresolutie dat in NuGet wordt gebruikt, is vergelijkbaar met Maven, omdat slechts één versie van een afhankelijkheid kan worden gebruikt. NuGet maakt echter geen afhankelijkheidsversies vast.

Als u bijvoorbeeld een afhankelijkheid <PackageReference Include="A" Version="1.2.3" />hebt, kunt u verwachten dat dit pakket gelijk is aan = 1.2.3, maar dat betekent >= 1.2.3eigenlijk wel . Als u een exacte versie wilt vastmaken, moet u gebruiken Version="[1.2.3]". Zie de documentatie over NuGet-versiebereiken voor meer informatie.

Naast het standaardgedrag van het bereik herstelt NuGet de laagste toepasselijke versie om aan een bereik te voldoen. Dit gedrag betekent dat u in veel gevallen een bereik moet definiëren.

Laten we eens kijken naar dit voorbeeldproject, dat afhankelijk is van 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>

Dit is afhankelijk van een versie die Microsoft.AspNetCore.Http.Connections kwetsbaar is voor een rce-beveiligingsprobleem (Remote Code Execution).

Controleer eerst of er een bijgewerkte versie is van Microsoft.AspNetCore.App die versie afhankelijk is van een nieuwere versie van Microsoft.AspNetCore.Http.Connections. Zo ja, dan kunt u hier upgraden Microsoft.AspNetCore.App en stoppen. Als dat niet het probleem is, moet u de versie ervan Microsoft.AspNetCore.Http.Connections overschrijven.

NuGet heeft geen equivalent van yarn waarom of mvn-afhankelijkheid: structuur ingebouwd, dus de eenvoudigste manier om de afhankelijkheidsstructuur te zien, is vaak om nuget.org te bezoeken. Als u de NuGet-pagina bezoektMicrosoft.AspNetCore.App, ziet u dat deze afhankelijk Microsoft.AspNetCore.Http.Connections version >= 1.0.4 && < 1.1.0is van. Of in een NuGet-versiebereik is [1.0.4,1.1.0)de representatieve syntaxis .

Het RCE-beveiligingsprobleem is Microsoft.AspNetCore.Http.Connections opgelost in versie1.0.15, dus u moet het versiebereik overschrijven.[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>

Het is raadzaam om een opmerking toe te voegen in de buurt van de afhankelijkheidsoplossing, zodat iedereen die later komt weet waarom de afhankelijkheid er is. Deze kan worden verwijderd zodra de hoofdafhankelijkheid gebruikmaakt van de nieuwe versie. Anders verzamelt u afhankelijkheden.

Wat gebeurt er als er geen oplossing beschikbaar is?

Als er geen bekende oplossing beschikbaar is, zijn de volgende opties beschikbaar als andere methoden voor herstel totdat een bijgewerkt onderdeel beschikbaar is:

• Stop met het gebruik van het onderdeel en verwijder het uit uw code. Deze verwijdering wordt gedetecteerd bij de volgende build met de afhankelijkheidsscantaak geïnstalleerd
• Een oplossing bijdragen aan het onderdeel zelf. Als uw organisatie specifieke richtlijnen heeft voor opensource-bijdragen, volgt u deze richtlijnen.
• De waarschuwing sluiten. Waarschuwingen zonder bekende oplossing kunnen echter nog steeds een beveiligingsrisico vormen voor uw organisatie. U wordt aangeraden een waarschuwing niet te sluiten omdat er geen bekende oplossing is.

Waarschuwingen voor het scannen van afhankelijkheden negeren

Als u waarschuwingen in Geavanceerde beveiliging wilt negeren, hebt u de juiste machtigingen nodig. Standaard beschikken alleen projectbeheerders over de mogelijkheid om Geavanceerde beveiligingswaarschuwingen te sluiten.

Een waarschuwing negeren:

1. Ga naar de waarschuwing die u wilt sluiten en selecteer de waarschuwing
2. Selecteer de vervolgkeuzelijst Waarschuwing sluiten
3. Als dit nog niet is geselecteerd, selecteert u Risico geaccepteerd of Fout-positief als reden voor sluiting
4. Een optionele opmerking toevoegen aan het tekstvak Opmerking
5. Selecteer Sluiten om de waarschuwing te verzenden en te sluiten
6. De waarschuwingsstatus verandert van Open naar Gesloten en geeft uw ontslagreden weer

Met deze actie wordt alleen de waarschuwing voor de geselecteerde vertakking gesloten. Andere vertakkingen die hetzelfde beveiligingsprobleem kunnen bevatten, blijven actief totdat anders actie is ondernomen. Elke waarschuwing die eerder is gesloten, kan handmatig opnieuw worden geopend.

Problemen met het scannen van afhankelijkheden oplossen

Afhankelijkheid scannen identificeert geen onderdelen

Als de scantaak voor afhankelijkheden wordt voltooid zonder dat er een vlag wordt toegevoegd aan onderdelen en er geen waarschuwingen voor onderdelen met bekende beveiligingsproblemen worden gegenereerd, moet u ervoor zorgen dat u vóór de AdvancedSecurity-Dependency-Scanning@1 taak een herstelstap voor pakketten hebt.

Voor een C#-project (.NET Core) ziet u hier bijvoorbeeld een YAML-voorbeeldfragment:

- task: DotNetCoreCLI@2
  displayName: 'Restore NuGet packages'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

    # If you are using a private package feed such as Azure Artifacts, you will need additional variables.
    # For more information, see https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/dotnet-core-cli-v2?view=azure-pipelines 
    feedsToUse: 'select'
    ...

- task: AdvancedSecurity-Dependency-Scanning@1

Voor een JavaScript-project ziet u hier een YAML-voorbeeldfragment:

- task: Npm@1
  displayName: 'npm install'
  inputs:
    command: 'install'
    workingDir: '$(System.DefaultWorkingDirectory)'

- task: AdvancedSecurity-Dependency-Scanning@1

Scannen op afhankelijkheden haalt geen nieuwe beveiligingsproblemen op

Als u een nieuwe build uitvoert, maar geen nieuwe beveiligingsproblemen ziet zoals verwacht, moet u ervoor zorgen dat de build wordt uitgevoerd met een nieuwe doorvoering.

Time-out voor het scannen van afhankelijkheidstaken

De standaardtijd die de scantaak voor afhankelijkheden uitvoert voordat er een time-out optreedt, is 300 seconden of 5 minuten. Als er een time-out optreedt voordat de taak is voltooid, kunt u een pijplijnvariabele DependencyScanning.Timeoutinstellen, die een geheel getal verwacht dat seconden vertegenwoordigt, zoals DependencyScanning.Timeout: 600. Alles onder de standaardtime-out van 300 seconden heeft geen effect.

Als u deze variabele wilt gebruiken, voegt u deze toe DependencyScanning.Timeout als een pijplijnvariabele:

- task: AdvancedSecurity-Dependency-Scanning@1
- env:
    DependencyScanning.Timeout: 600

Break-glass-scenario voor build-taak

Als de build-taak voor het scannen van afhankelijkheden een geslaagde uitvoering van uw pijplijn blokkeert en u de buildtaak dringend moet overslaan, kunt u een pijplijnvariabele DependencyScanning.Skip: trueinstellen.

Taakmachtigingen voor het scannen van afhankelijkheden

De build-taak voor het scannen van afhankelijkheden maakt gebruik van de pijplijnidentiteit om de Advanced Security REST API's aan te roepen. Pijplijnen in hetzelfde project hebben standaard toegang tot het ophalen van waarschuwingen. Als u deze machtigingen verwijdert uit het buildserviceaccount of als u een aangepaste installatie hebt (bijvoorbeeld een pijplijn die wordt gehost in een ander project dan de opslagplaats), moet u deze machtigingen handmatig verlenen.

Verdeel Advanced Security: View Alerts toestemming voor het buildserviceaccount dat wordt gebruikt in uw pijplijn, wat voor pijplijnen met projectbereik is [Project Name] Build Service ([Organization Name])en voor pijplijnen Project Collection Build Service ([Organization Name])met een verzamelingsbereik.