Skanowanie zależności
Skanowanie zależności w usłudze GitHub Advanced Security dla usługi Azure DevOps wykrywa składniki typu open source używane w kodzie źródłowym i wykrywa, czy występują jakiekolwiek skojarzone luki w zabezpieczeniach. Wszelkie znalezione luki w zabezpieczeniach ze składników typu open source są oflagowane jako alert.
Usługa GitHub Advanced Security dla usługi Azure DevOps współpracuje z usługą Azure Repos. Jeśli chcesz używać usługi GitHub Advanced Security z repozytoriami GitHub, zobacz Usługa GitHub Advanced Security.
Informacje o skanowaniu zależności
Skanowanie zależności generuje alert dla dowolnego składnika typu open source, bezpośredniego lub przechodniego, które mogą być narażone na zagrożenia, od których zależy kod. Bezpośrednie luki w zabezpieczeniach to biblioteki używane bezpośrednio przez kod. Zależności przechodnie to biblioteki lub inne oprogramowanie, które bezpośrednio korzystają z zależności.
Informacje o wykrywaniu skanowania zależności
Nowa migawka składników jest przechowywana za każdym razem, gdy graf zależności dla repozytorium ulegnie zmianie, a po potoku, który zawiera zadanie skanowania zależności, tworząc nowy kod (innymi słowy, nowe zatwierdzenie).
Dla każdego składnika podatnego na zagrożenia wykrytego w użyciu składnik i luka w zabezpieczeniach są wyświetlane w dzienniku kompilacji i wyświetlane jako alert na karcie Zabezpieczenia zaawansowane. Tylko doradcy przeglądane przez usługę GitHub i dodane do bazy danych porad usługi GitHub tworzą alert skanowania zależności. Dziennik kompilacji zawiera link do pojedynczego alertu w celu dalszego zbadania. Aby uzyskać więcej informacji na temat szczegółów alertu, zobacz Naprawianie alertów skanowania zależności.
Dziennik kompilacji zawiera również podstawowe informacje na temat każdej wykrytej luki w zabezpieczeniach. Te szczegóły obejmują ważność, składnik, którego dotyczy problem, tytuł luki w zabezpieczeniach i skojarzoną lukę w zabezpieczeniach.
Obsługiwane ekosystemy pakietów
Skanowanie zależności obsługuje zarówno bezpośrednie, jak i przechodnie zależności dla wszystkich obsługiwanych ekosystemów pakietów.
Menedżer pakietów | Języki | Obsługiwane formaty |
---|---|---|
Ładunek | Rust | Cargo.toml , Cargo.lock |
CocoaPods | Swift | Podfile.lock |
Moduły języka Go | Go | go.mod , go.sum |
Gradle | Java | *.lockfile |
Maven | Java | pom.xml |
npm | JavaScript | package-lock.json , , package.json , , npm-shrinkwrap.json lerna.json |
NuGet | C# | *.packages.config , , *.project.assets *.csproj |
Python | setup.py , requirements.txt |
|
pnpm | JavaScript | package.json |
RubyGems | Ruby | Gemfile.lock |
Przędza | JavaScript | package.json |
Informacje o alertach skanowania zależności
Karta Advanced Security w repozytoriach w usłudze Azure DevOps to centrum do wyświetlania alertów zabezpieczeń, które domyślnie wyświetla alerty skanowania zależności. Można filtrować według gałęzi, potoku, pakietu i ważności. Możesz wybrać alert, aby uzyskać więcej informacji, w tym wskazówki dotyczące korygowania. Obecnie centrum alertów nie wyświetla alertów dotyczących skanowania ukończonego w gałęziach żądania ściągnięcia.
Gdy w repozytorium wykryto pakiet podatny na zagrożenia, rozwiązywanie alertów skanowania zależności zwykle wiąże się z uaktualnieniem do wyższej wersji pakietu lub usunięciem obraźliwego pakietu. Ta porada dotyczy zarówno zależności bezpośrednich, jak i przejściowych (lub pośrednich). Widok domyślny na karcie Advanced Security to aktywne alerty dla domyślnej gałęzi repozytorium.
Nie ma wpływu na wyniki, jeśli nazwy potoków lub gałęzi zostaną zmienione — wyświetlenie nowej nazwy może potrwać do 24 godzin.
Stan alertu jest automatycznie aktualizowany, Closed
gdy składnik podatny na zagrożenia nie jest już wykrywany w najnowszej kompilacji dla wszystkich potoków, w których jest zainstalowane zadanie skanowania zależności. Aby wyświetlić rozwiązane alerty, użyj filtru State
na głównym pasku narzędzi i wybierz pozycję Closed
.
Jeśli wyłączysz usługę Advanced Security dla repozytorium, utracisz dostęp do wyników na karcie Zabezpieczenia zaawansowane i zadaniu kompilacji. Zadanie kompilacji nie powiedzie się, ale żadne wyniki z kompilacji są uruchamiane z zadaniem, podczas gdy zabezpieczenia zaawansowane są wyłączone, są ukryte i nie są zachowywane.
Szczegóły alertu
Możesz również przejść do szczegółów alertu, klikając określony alert i wskazówki dotyczące korygowania.
Sekcja | Wyjaśnienie |
---|---|
Zalecenie | Tekst rekomendacji pochodzi bezpośrednio od naszego dostawcy danych luk w zabezpieczeniach, bazy danych doradczych usługi GitHub. Zazwyczaj wskazówki sugerują uaktualnienie zidentyfikowanego składnika do wersji niepodważalnej. |
Lokalizacja | Sekcja Lokalizacje zawiera szczegółowe informacje o ścieżkach , w których zadanie skanowania zależności wykryło używany składnik podatny na zagrożenia. Jeśli plik można rozpoznać z bazowego skanowania kompilacji do zatwierdzonego pliku w źródle, karta Lokalizacje zostanie wyświetlona jako link do kliknięcia. Jeśli plik został utworzony w ramach kompilacji (na przykład artefakt kompilacji), link nie jest klikalny. Przejrzyj dzienniki kompilacji, aby lepiej zrozumieć, jak składnik został wprowadzony do kompilacji. |
opis | Opis jest dostarczany przez opis poradnika w usłudze GitHub. |
Wykrywania
Potoki wymienione na karcie Wykrycia to potoki , w których znaleziono składnik podatny na zagrożenia. Każdy wiersz zawiera szczegóły najnowszej kompilacji objętego potoku oraz daty wprowadzenia pakietu. Jeśli pakiet podatny na zagrożenia został naprawiony w niektórych potokach, ale nie wszystkie, zobaczysz częściowo stałe wiersze.
Po rozwiązaniu alertu alert automatycznie przechodzi do Closed
stanu, a najnowszy potok uruchamiania na karcie Wykrycia wyświetla zielony znacznik wyboru, co oznacza, że kod zawierający zaktualizowany składnik został uruchomiony w tym potoku:
Ważność
Baza danych doradczych usługi GitHub udostępnia ocenę CVSS, która jest następnie tłumaczona na niską, średnią, wysoką lub krytyczną ważność alertu, wykonując następujące wskazówki:
Ocena CVSS | Ważność |
---|---|
1.0 < Wynik < 4.0 | Niski |
4.0 < Wynik < 7.0 | Śred. |
7.0 < Wynik < 9.0 | Wys. |
Wynik >= 9,0 | Krytyczne |
Znajdowanie szczegółów
Dwa sekcje są często spotykane w obszarze Znajdowanie szczegółów: pakiet podatny na zagrożenia i zależność główna. Pakiet podatny na zagrożenia jest potencjalnie narażonym składnikiem. Sekcja zależności głównej zawiera składniki najwyższego poziomu, które są odpowiedzialne za łańcuch zależności, który prowadzi do luki w zabezpieczeniach.
Jeśli pakiet podatny na zagrożenia jest przywołyny tylko jako bezpośrednia zależność, zobaczysz tylko sekcję "pakiet podatny na zagrożenia".
Jeśli pakiet narażony jest przywołyny zarówno jako zależność bezpośrednia, jak i przechodnia, pakiet jest wyświetlany zarówno w sekcji "pakiet podatny na zagrożenia" i "zależność główna".
Jeśli pakiet podatny na zagrożenia jest przywołyny tylko jako zależność przechodnia, pakiet jest wyświetlany w sekcji "pakiet podatny na zagrożenia", a zależności główne odwołujące się do pakietu podatnego są wyświetlane w sekcji "główna zależność".
Zarządzanie alertami skanowania zależności
Wyświetlanie alertów dla repozytorium
Każda osoba z uprawnieniami współautora dla repozytorium może wyświetlić podsumowanie wszystkich alertów dla repozytorium w usłudze Repos>Advanced Security.
Domyślnie na stronie alertów są wyświetlane wyniki skanowania zależności dla domyślnej gałęzi repozytorium.
Stan alertu odzwierciedla stan domyślnej gałęzi i najnowszego potoku uruchamiania, nawet jeśli alert istnieje w innych gałęziach i potokach.
Naprawianie alertów skanowania zależności
Bezpośrednia zależność to składnik, który znajduje się w repozytorium. Zależność przechodnia lub pośrednia to składnik, który jest używany przez zależność bezpośrednią. Projekt jest nadal podatny na zagrożenia niezależnie od tego, czy luka w zabezpieczeniach znajduje się w zależności bezpośredniej, czy przechodniej.
Naprawienie zależności przechodniej podatnej na zagrożenia zwykle przyjmuje formę jawnego zastąpienia wersji składnika podatnego na zagrożenia używanego dla każdej zidentyfikowanej bezpośredniej zależności. Gdy zależności główne uaktualniły ich użycie składnika podatnego na zagrożenia do bezpiecznej wersji, można uaktualnić każdą zależność główną, a nie wiele pojedynczych przesłonięć.
Aktualizowanie zależności dla usługi Yarn/Npm
Hipotetycznie załóżmy, że ten pakiet ma dwie luki w zabezpieczeniach. Jedna z nich dotyczy axios
, bezpośredniej zależności i jest acorn
to zależność przechodnia (znana również jako zależność pośrednia lub zależność zależności).
{
"name": "my-package",
"version": "1.0.0",
"dependencies": {
"axios": "0.18.0",
"eslint": "5.16.0",
}
}
Bieżąca wersja axios
programu ma lukę w zabezpieczeniach typu "odmowa usługi" (DoS) z zaleceniem aktualizacji do wersji 0.18.1 lub nowszej. Ponieważ jest to bezpośrednia zależność, masz kontrolę nad używaną axios
wersją. Wystarczy zaktualizować wersję axios
, którą ściągasz. package.json
Zaktualizowany wygląd wygląda podobnie do następującego:
{
"name": "my-package",
"version": "1.0.0",
"dependencies": {
"axios": "0.19.2",
"eslint": "5.16.0",
}
}
Teraz wersja eslint
w pokazanej package.json
wersji zależy od wersji acorn
, która jest luką w zabezpieczeniach typu "odmowa usługi" wyrażenia regularnego (ReDoS) z zaleceniem aktualizacji do wersji lub nowszej 5.7.4, 6.4.1, 7.1.1
. Jeśli otrzymasz alert z narzędzia do skanowania zależności, powinna zostać wyświetlona główna zależność, która wymaga zależności podatnej na zagrożenia.
Przędza
Jeśli używasz usługi Yarn, możesz użyć przędzy, dlaczego można znaleźć kompletny łańcuch zależności.
> $ 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.
Pełny łańcuch zależności to eslint
acorn
>espree
>. Gdy znasz łańcuch zależności, możesz użyć innej funkcji usługi Yarn, selektywnych rozwiązań zależności, aby zastąpić wersję żołędzi, która zostanie użyta.
Użyj pola rozdzielczości w pliku , package.json
aby zdefiniować przesłonięć wersję. Pokazano trzy różne metody zastąpienia pakietu w kolejności od najgorszych do najlepszych:
{
"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
Użycie wzorca zastępuje wszystkie użycia pakietu acorn we wszystkich zależnościach. Jest to niebezpieczne i przerywane w czasie wykonywania. W rezultacie został on usunięty w wersji Yarn w wersji 2.
eslint/**/acorn
Użycie wzorca zastępuje wszystkie użycia pakietu acorn w ramach pakietu eslint i we wszystkich pakietach, od których zależy. Jest to bezpieczniejsze niż zastępowanie pakietu dla wszystkich zależności, ale nadal ma pewne zagrożenia, jeśli wykres zależności dla pakietu jest duży. Ten wzorzec jest zalecany, gdy istnieje wiele podpakietów korzystających z pakietu podatnego na zagrożenia i zdefiniowanie przesłonięć dla poszczególnych podpakietów byłoby niepraktyczne.
Użycie wzorca eslint/espree/acorn
zastępuje tylko użycie acorn
elementu w espree
pakiecie w pakiecie eslint
. Dotyczy to szczególnie łańcucha zależności podatnych na zagrożenia i jest zalecanym sposobem zastąpienia wersji pakietów.
npm
Jeśli używasz narzędzia npm 8.3 lub nowszego , możesz użyć pola przesłonięć w package.json
Dodaj przesłonięcia, jeśli musisz wprowadzić określone zmiany w zależnościach przechodnich. Na przykład może być konieczne dodanie przesłonięcia, aby zastąpić wersję zależności znanym problemem z zabezpieczeniami, zastąpić istniejącą zależność rozwidleniem lub upewnić się, że ta sama wersja pakietu jest używana wszędzie.
{
"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"
}
}
}
}
Pokazany przykład przesłonięcia pokazuje sposób na powiedzenie npm "przesłonięć tylko użycie acorn
pakietu espree
w eslint
pakiecie". Dotyczy to szczególnie łańcucha zależności podatnych na zagrożenia i jest zalecanym sposobem zastąpienia wersji pakietów. Przesłonięcia są natywną funkcją narzędzia npm. Umożliwia zastąpienie pakietu w drzewie zależności inną wersją lub innym pakietem w całości.
Po ustawieniu przesłonięć należy usunąć element package-lock.json
i node_modules
uruchomić npm install
go ponownie.
Nie można ustawić przesłonięcia dla pakietu, od którego zależy bezpośrednio, chyba że zarówno zależność, jak i sama przesłoń współdzielą dokładnie tę samą specyfikację. Załóżmy na przykład, że jest podatna axios: "0.18.0"
na zagrożenia i chcemy przeprowadzić uaktualnienie do axios: "0.19.2"
klasy . Bezpośrednio zmień wersję zależności zamiast użyć przesłonięcia.
{
"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",
}
}
Zaktualizuj wersję zależności bez ustawiania przesłonięcia:
{
"name": "npm-overrides",
"version": "1.0.0",
"license": "MIT",
"dependencies": {
"axios": "0.19.2"
}
}
Aktualizowanie zależności dla narzędzia Maven
Mechanizm rozwiązywania zależności nie jest tak zaawansowany, jak mechanizm używany w usłudze Yarn. W związku z tym można mieć tylko jedną wersję zależności w projekcie. Aby rozwiązać ten problem, narzędzie Maven używa algorytmu "najbliższych zwycięstw". Oznacza to, że używa wersji najbliższej zależności do projektu w drzewie zależności zależności.
Na przykład masz następujący graf zależności:
your-project --- A:1.0.0 --- B:2.0.0
\
\__ B:1.0.0
your-project
A:1.0.0
zależy od elementu , który z kolei zależy od B:2.0.0
elementu , ale projekt ma również bezpośrednią zależność od B:1.0.0
. Dlatego masz dwie różne wersje zależności B na grafie zależności, ale wersja 1.0.0 zależności B wygrywa, ponieważ jest "najbliżej" projektu.
W niektórych przypadkach ten scenariusz może działać, jeśli wersje są zgodne. Jeśli A:1.0.0
jednak zależy od niektórych funkcji B, która jest dostępna tylko w wersji 2.0.0
, takie zachowanie nie działa. W najgorszym scenariuszu ten projekt może nadal być kompilowany, ale kończy się niepowodzeniem w czasie wykonywania.
Przyjrzyjmy się przykładowi świata rzeczywistego.
<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>
Załóżmy, że wersja com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider
zależy od wersji com.fasterxml.jackson.core:jackson-databind
, która ma deserializacji niezaufanej luki w zabezpieczeniach danych.
Tę zależność można zweryfikować przy użyciu wtyczki zależności maven. W takim przypadku należy uruchomić mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
polecenie i uzyskać następujące dane wyjściowe:
> $ 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] ------------------------------------------------------------------------
Najpierw sprawdź, czy istnieje nowa wersja, która nie zależy od wersji com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider
podatnej na zagrożenia programu com.fasterxml.jackson.core:jackson-databind
. Jeśli tak, możesz uaktualnić com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider
i zatrzymać tam. Jeśli nie, przesłoń wersję elementu com.fasterxml.jackson.core:jackson-databind
.
Jak pokazano w fragmencie kodu, w przypadku używania narzędzia Maven "najbliższe zwycięstwa", więc rozwiązaniem jest dodanie bezpośredniej zależności do com.fasterxml.jackson.core:jackson-databind
tej poprawki luki w zabezpieczeniach.
<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>
Możesz sprawdzić, czy rozwiązanie działa, uruchamiając mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind
ponownie polecenie .
$ 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] ------------------------------------------------------------------------
Zaleca się dodanie komentarza w pobliżu rozwiązania zależności, aby każda osoba przychodząca później wiedziała, dlaczego istnieje zależność. Można go usunąć, gdy zależność główna używa nowej wersji; w przeciwnym razie gromadzisz zależności.
W rzeczywistym projekcie dodaj zależność tak wysoko, jak to możliwe. Można na przykład dodać rozdzielczość w nadrzędnym pliku POM zamiast indywidualnie w każdym pliku POM projektu.
Aktualizowanie zależności dla narzędzia NuGet
Algorytm rozpoznawania zależności używany w narzędziu NuGet jest podobny do narzędzia Maven, w tym, że można użyć tylko jednej wersji zależności. Jednak pakiet NuGet nie przypina wersji zależności.
Jeśli na przykład masz zależność <PackageReference Include="A" Version="1.2.3" />
, możesz oczekiwać, że ten pakiet będzie odpowiednikiem = 1.2.3
elementu , ale w rzeczywistości oznacza to .>= 1.2.3
Aby przypiąć dokładną wersję, należy użyć polecenia Version="[1.2.3]"
. Aby uzyskać więcej informacji, zobacz dokumentację zakresów wersji pakietu NuGet.
Oprócz domyślnego zachowania zakresu Pakiet NuGet przywraca najniższą odpowiednią wersję, aby spełnić zakres. To zachowanie oznacza, że w wielu przypadkach trzeba zdefiniować zakres.
Przyjrzyjmy się temu przykładoweowi projektowi, który ma zależność od Microsoft.AspNetCore.App
elementu :
<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>
Zależy to od wersji Microsoft.AspNetCore.Http.Connections
, która jest podatna na lukę w zabezpieczeniach zdalnego wykonywania kodu (RCE).
Najpierw należy sprawdzić, czy jest zaktualizowana wersja Microsoft.AspNetCore.App
programu , która zależy od nowszej wersji programu Microsoft.AspNetCore.Http.Connections
. Jeśli tak, możesz uaktualnić Microsoft.AspNetCore.App
i zatrzymać się tutaj. Jeśli nie, musisz zastąpić jego wersję Microsoft.AspNetCore.Http.Connections
zależy.
NuGet nie ma odpowiednika instrukcji yarn why lub mvn dependency:tree built-in, więc najprostszym sposobem wyświetlenia drzewa zależności jest często odwiedzanie nuget.org. Jeśli odwiedzisz stronę Narzędzia NuGet dlaMicrosoft.AspNetCore.App
polecenia , zobaczysz, że zależy ona od Microsoft.AspNetCore.Http.Connections
version >= 1.0.4 && < 1.1.0
. Lub w zakresie wersji NuGet składnia reprezentatywna to [1.0.4,1.1.0)
.
Luka W zabezpieczeniach RCE w Microsoft.AspNetCore.Http.Connections
systemie została usunięta w wersji 1.0.15
, więc należy zastąpić zakres[1.0.15, 1.1.0)
wersji.
<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>
Zaleca się dodanie komentarza w pobliżu rozwiązania zależności, aby każda osoba przychodząca później wiedziała, dlaczego istnieje zależność. Można go usunąć, gdy zależność główna używa nowej wersji. W przeciwnym razie kumulujesz zależności.
Co zrobić, jeśli nie ma dostępnej poprawki?
Jeśli nie jest dostępna żadna znana poprawka, dostępne są następujące opcje jako inne metody korygowania do momentu udostępnienia uaktualnionego składnika:
- Przestań używać składnika i usuwać go z kodu — to usunięcie zostanie wykryte podczas następnej kompilacji z zainstalowanym zadaniem skanowania zależności
- Współtworzenie poprawki do samego składnika. Jeśli Twoja organizacja ma określone wytyczne dotyczące współtworzenia oprogramowania open source, postępuj zgodnie z tymi wytycznymi.
- Odrzucanie alertu. Alerty bez znanej poprawki nadal mogą stanowić zagrożenie bezpieczeństwa dla organizacji. Zalecamy, aby nie odrzucać alertu tylko dlatego, że nie ma znanej poprawki.
Odrzucanie alertów skanowania zależności
Aby odrzucić alerty w usłudze Advanced Security, potrzebne są odpowiednie uprawnienia. Domyślnie tylko administratorzy projektów mają możliwość odrzucania alertów usługi Advanced Security.
Aby odrzucić alert:
- Przejdź do alertu, który chcesz zamknąć, i wybierz alert
- Wybierz listę rozwijaną Zamknij alert
- Jeśli jeszcze nie wybrano, wybierz pozycję Ryzyko zaakceptowane lub Fałszywie dodatnie jako przyczynę zamknięcia
- Dodawanie opcjonalnego komentarza do pola tekstowego Komentarz
- Wybierz pozycję Zamknij , aby przesłać i zamknąć alert
- Stan alertu zmienia się z Otwórz na Zamknięty i wyświetla przyczynę odrzucenia
Ta akcja odrzuca tylko alert dla wybranej gałęzi. Inne gałęzie, które mogą zawierać tę samą lukę w zabezpieczeniach, pozostają aktywne, dopóki nie będą działać w inny sposób. Każdy alert, który został wcześniej odrzucony, można ręcznie otworzyć ponownie.
Zarządzanie alertami skanowania zależności dla żądań ściągnięcia
Jeśli alerty są tworzone dla nowych zmian kodu w żądaniu ściągnięcia, alert jest zgłaszany jako adnotacja w sekcji Komentarz karty Przegląd żądania ściągnięcia i jako alert na karcie Repozytorium zabezpieczeń zaawansowanych. Istnieje nowy wpis selektora gałęzi dla gałęzi żądania ściągnięcia.
Możesz wyświetlić manifest pakietu, wyświetlić podsumowanie znajdowania i rozwiązać adnotację w sekcji Przegląd.
Aby odrzucić alerty żądania ściągnięcia, musisz przejść do widoku szczegółów alertu, aby zamknąć alert i rozwiązać adnotację. W przeciwnym razie po prostu zmiana stanu komentarza (1) rozwiązuje adnotację, ale nie zamyka ani nie naprawia bazowego alertu.
Aby wyświetlić cały zestaw wyników dla gałęzi żądania ściągnięcia, przejdź do obszaru Zabezpieczenia>zaawansowane repozytoriów i wybierz gałąź żądania ściągnięcia. Wybranie pozycji Pokaż więcej szczegółów (2) w adnotacji spowoduje przekierowanie do widoku szczegółów alertu na karcie Zabezpieczenia zaawansowane.
Napiwek
Adnotacje zostaną utworzone tylko wtedy, gdy objęte wiersze kodu są całkowicie unikatowe dla różnicy żądania ściągnięcia w porównaniu z gałęzią docelową żądania ściągnięcia.