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 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.
Zie Ondersteunde pakketecosystemen voor een lijst met ondersteunde onderdeelecosystemen en -versies.
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 eslint
acorn
>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-project
A:1.0.0
hangt af van , wat op zijn beurt afhankelijk is B:2.0.0
van, maar uw project ook een directe afhankelijkheid B:1.0.0
heeft . 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.3
eigenlijk 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.0
is 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 uw 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:
- Ga naar de waarschuwing die u wilt sluiten en selecteer de waarschuwing
- Selecteer de vervolgkeuzelijst Waarschuwing sluiten
- Als dit nog niet is geselecteerd, selecteert u Risico geaccepteerd of Fout-positief als reden voor sluiting
- Een optionele opmerking toevoegen aan het tekstvak Opmerking
- Selecteer Sluiten om de waarschuwing te verzenden en te sluiten
- 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.
Waarschuwingen voor afhankelijkheidsscans voor pull-aanvragen beheren
Als er waarschuwingen worden gemaakt voor nieuwe codewijzigingen in een pull-aanvraag, wordt de waarschuwing gerapporteerd als een aantekening in de opmerkingensectie van het tabblad Overzicht van de pull-aanvraag en als waarschuwing op het tabblad Geavanceerde beveiliging. Er is een nieuwe vertakkingskiezervermelding voor de pull-aanvraagbranch.
U kunt het betrokken pakketmanifest zien, een samenvatting van de bevindingen bekijken en de aantekening oplossen in de sectie Overzicht.
Als u waarschuwingen voor pull-aanvragen wilt verwijderen, moet u naar de detailweergave van de waarschuwing navigeren om zowel de waarschuwing te sluiten als de aantekening op te lossen. Als u anders gewoon de opmerkingsstatus (1) wijzigt, wordt de aantekening omgezet, maar wordt de onderliggende waarschuwing niet gesloten of opgelost.
Als u de volledige set resultaten voor uw pull-aanvraagvertakking wilt zien, gaat u naar Geavanceerde beveiliging van opslagplaatsen>en selecteert u uw pull-aanvraagvertakking. Als u Meer details weergeven (2) selecteert in de aantekening, wordt u naar de detailweergave van de waarschuwing op het tabblad Geavanceerde beveiliging leiden.
Tip
Aantekeningen worden alleen gemaakt wanneer de betrokken coderegels volledig uniek zijn voor het verschil in de pull-aanvraag in vergelijking met de doelbranch van de pull-aanvraag.