Udostępnij za pośrednictwem

Skanowanie zależności

  • Artykuł

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 wykonaniu potoku zawierającego zadanie skanowania zależności.

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.

Zrzut ekranu przedstawiający dane wyjściowe kompilacji skanowania zależności

Aby uzyskać listę obsługiwanych ekosystemów składników i wersji, zobacz Obsługiwane ekosystemy pakietów.

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.

Zrzut ekranu przedstawiający widok alertu skanowania zależności dla repozytorium

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.

Zrzut ekranu przedstawiający wyświetlanie alertów skanowania zamkniętych zależności

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.

Zrzut ekranu przedstawiający szczegóły alertu skanowania zależności

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.

Zrzut ekranu przedstawiający widok wykrywania wykrywania zależności dla alertu bez poprawki

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:

Zrzut ekranu przedstawiający widok wykrywania skanowania zależności dla alertu

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 acornto 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 eslintacorn>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-projectA:1.0.0zależ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.3elementu , 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.Appelementu :

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

  1. Przejdź do alertu, który chcesz zamknąć, i wybierz alert
  2. Wybierz listę rozwijaną Zamknij alert
  3. Jeśli jeszcze nie wybrano, wybierz pozycję Ryzyko zaakceptowane lub Fałszywie dodatnie jako przyczynę zamknięcia
  4. Dodawanie opcjonalnego komentarza do pola tekstowego Komentarz
  5. Wybierz pozycję Zamknij , aby przesłać i zamknąć alert
  6. Stan alertu zmienia się z Otwórz na Zamknięty i wyświetla przyczynę odrzucenia

Zrzut ekranu przedstawiający sposób odrzucania alertu skanowania zależności

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.

Zrzut ekranu przedstawiający adnotację aktywnego żądania ściągnięcia zależności.

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.

Zrzut ekranu przedstawiający adnotację zamkniętego żądania ściągnięcia zależności.

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.