Analisi delle dipendenze

L'analisi delle dipendenze in GitHub Advanced Security per Azure DevOps rileva i componenti open source usati nel codice sorgente e rileva se sono presenti vulnerabilità associate. Eventuali vulnerabilità rilevate dai componenti open source vengono contrassegnate come avvisi.

GitHub Advanced Security per Azure DevOps funziona con Azure Repos. Per usare GitHub Advanced Security con i repository GitHub, vedere GitHub Advanced Security.

Informazioni sull'analisi delle dipendenze

L'analisi delle dipendenze genera un avviso per qualsiasi componente open source, diretto o transitivo, che risulta essere vulnerabile da cui dipende il codice. Le vulnerabilità dirette sono le librerie usate direttamente dal codice. Le dipendenze transitive sono le librerie o altri software che usano dipendenze dirette.

Informazioni sul rilevamento dell'analisi delle dipendenze

Un nuovo snapshot dei componenti viene archiviato ogni volta che viene modificato il grafico delle dipendenze per un repository e dopo l'esecuzione di una pipeline che contiene l'attività di analisi delle dipendenze.

Per ogni componente vulnerabile rilevato in uso, il componente e la vulnerabilità sono elencati nel log di compilazione e visualizzati come avviso nella scheda Sicurezza avanzata. Solo gli avvisi esaminati da GitHub e aggiunti al database consultivo GitHub creano un avviso di analisi delle dipendenze. Il log di compilazione include un collegamento al singolo avviso per ulteriori indagini. Per altre informazioni sui dettagli dell'avviso, vedere Correzione degli avvisi di analisi delle dipendenze.

Il log di compilazione contiene anche informazioni di base su ogni vulnerabilità rilevata. Questi dettagli includono la gravità, il componente interessato, il titolo della vulnerabilità e il CVE associato.

Per un elenco degli ecosistemi e delle versioni dei componenti supportati, vedere Ecosistemi di pacchetti supportati.

Informazioni sugli avvisi di analisi delle dipendenze

La scheda Sicurezza avanzata in Repos in Azure DevOps è l'hub per visualizzare gli avvisi di sicurezza, che per impostazione predefinita mostra gli avvisi di analisi delle dipendenze. È possibile filtrare per ramo, pipeline, pacchetto e gravità. È possibile selezionare un avviso per altri dettagli, incluse le indicazioni sulla correzione. Al momento, l'hub degli avvisi non visualizza gli avvisi per l'analisi completata nei rami delle richieste pull.

Quando viene rilevato un pacchetto vulnerabile nel repository, la correzione degli avvisi di analisi delle dipendenze comporta in genere l'aggiornamento a una versione del pacchetto superiore o la rimozione di un pacchetto che causa un errore. Questo consiglio vale sia per le dipendenze dirette che transitive (o indirette). La visualizzazione predefinita nella scheda Sicurezza avanzata è avvisi attivi per il ramo predefinito per il repository.

Non esiste alcun effetto sui risultati se le pipeline o i rami vengono rinominati. Potrebbero essere necessarie fino a 24 ore prima che venga visualizzato il nuovo nome.

Lo stato di un avviso viene aggiornato automaticamente a Closed quando il componente vulnerabile non viene più rilevato nella build più recente per le pipeline in cui è installata l'attività di analisi delle dipendenze. Per visualizzare gli avvisi risolti, usare il State filtro nella barra degli strumenti principale e selezionare Closed.

Se si disattiva Sicurezza avanzata per il repository, si perderà l'accesso ai risultati nella scheda Sicurezza avanzata e nell'attività di compilazione. L'attività di compilazione non avrà esito negativo, ma i risultati delle compilazioni vengono eseguiti con l'attività mentre la sicurezza avanzata è disabilitata sono nascoste e non mantenute.

Dettagli dell'avviso

È anche possibile esaminare i dettagli relativi a un avviso facendo clic su un avviso specifico e indicazioni sulla correzione.

Sezione	Spiegazione
Elemento consigliato	Il testo della raccomandazione proviene direttamente dal provider di dati della vulnerabilità, il database di consulenza GitHub. In genere, il materiale sussidiario suggerisce di aggiornare il componente identificato a una versione nonvulnerabile.
Ufficio	La sezione Percorsi descrive in dettaglio i percorsi in cui l'attività di analisi delle dipendenze ha individuato il componente vulnerabile in uso. Se il file può essere risolto dall'analisi di compilazione sottostante in un file di cui è stato eseguito il commit nell'origine, la scheda Percorsi viene visualizzata come collegamento selezionabile. Se un file è stato prodotto come parte di una compilazione (ad esempio, un artefatto di compilazione), il collegamento non è selezionabile. Esaminare i log di compilazione per comprendere meglio come è stato inserito il componente nella compilazione.
Descrizione	La descrizione viene fornita dalla descrizione dell'avviso GitHub.

Rilevamenti

Le pipeline elencate nella scheda Rilevamenti sono le pipeline in cui è stato trovato il componente vulnerabile. Ogni riga illustra in dettaglio la build più recente della pipeline interessata e la data di introduzione del pacchetto. Se il pacchetto vulnerabile è stato risolto in alcune pipeline, ma non tutti, vengono visualizzate righe parzialmente fisse.

Dopo aver risolto un avviso, l'avviso passa automaticamente allo Closed stato e la pipeline di esecuzione più recente nella scheda Rilevamenti visualizza un segno di spunta verde, ovvero il codice contenente il componente aggiornato è stato eseguito nella pipeline:

Gravità

Il database di consulenza GitHub fornisce un punteggio CVSS, che viene quindi convertito in una gravità bassa, media, alta o critica per un avviso seguendo le linee guida seguenti:

Punteggio CVSS	Gravità
1.0 < Punteggio < 4.0	Basso
4.0 < Punteggio < 7.0	Medio
7.0 < Punteggio < 9.0	Alto
Punteggio >= 9,0	Critico

Ricerca dei dettagli

Due sezioni sono comunemente disponibili in Ricerca dei dettagli: pacchetto vulnerabile e dipendenza radice. Il pacchetto vulnerabile è il componente potenzialmente vulnerabile. La sezione delle dipendenze radice contiene componenti di primo livello responsabili della catena di dipendenze che causano una vulnerabilità.

Se il pacchetto vulnerabile viene fatto riferimento solo come dipendenza diretta, viene visualizzata solo la sezione "pacchetto vulnerabile".

Se il pacchetto vulnerabile viene fatto riferimento sia come dipendenza diretta che transitiva, il pacchetto viene visualizzato sia nella sezione "pacchetto vulnerabile" che nella sezione "dipendenza radice".

Se il pacchetto vulnerabile viene fatto riferimento solo come dipendenza transitiva, il pacchetto viene visualizzato nella sezione "pacchetto vulnerabile" e le dipendenze radice che fanno riferimento al pacchetto vulnerabile vengono visualizzate nella sezione "dipendenza radice".

Gestire gli avvisi di analisi delle dipendenze

Visualizzazione degli avvisi per un repository

Chiunque disponga delle autorizzazioni di collaboratore per un repository può visualizzare un riepilogo di tutti gli avvisi per un repository in Sicurezza avanzata Repos>.

Per impostazione predefinita, nella pagina degli avvisi vengono visualizzati i risultati dell'analisi delle dipendenze per il ramo predefinito del repository.

Lo stato di un avviso riflette lo stato per il ramo predefinito e la pipeline di esecuzione più recente, anche se l'avviso esiste in altri rami e pipeline.

Correzione degli avvisi di analisi delle dipendenze

Una dipendenza diretta è un componente presente nel repository. Una dipendenza transitiva o indiretta è un componente che viene usato da una dipendenza diretta. Il progetto è ancora vulnerabile indipendentemente dal fatto che la vulnerabilità venga rilevata in una dipendenza diretta o transitiva.

La correzione di una dipendenza transitiva vulnerabile in genere assume la forma di override esplicito della versione del componente vulnerabile usata per ogni dipendenza diretta identificata. Dopo che le dipendenze radice hanno aggiornato l'uso del componente vulnerabile a una versione sicura, è possibile aggiornare ogni dipendenza radice anziché più sostituzioni singole.

Aggiornamento delle dipendenze per Yarn/Npm

Ipoteticamente, dire che questo pacchetto presenta due vulnerabilità. Uno è per axios, una dipendenza diretta e una è per acorn, una dipendenza transitiva (nota anche come dipendenza indiretta o dipendenza della dipendenza).

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

La versione corrente di axios presenta una vulnerabilità Denial of Service (DoS) con una raccomandazione per eseguire l'aggiornamento alla versione 0.18.1 o successiva. Poiché si tratta di una dipendenza diretta, si ha il controllo sulla versione di axios che si usa. È sufficiente aggiornare la versione di axios cui si esegue il pull. L'aggiornamento package.json è simile al seguente:

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

La versione di eslint nell'oggetto package.json illustrato dipende ora da una versione di acorn che è una vulnerabilità Regular Expression Denial of Service (ReDoS) con una raccomandazione di eseguire l'aggiornamento alla versione 5.7.4, 6.4.1, 7.1.1 o versione successiva. Se si riceve un avviso dallo strumento di analisi delle dipendenze, è necessario indicare la dipendenza radice che richiede la dipendenza vulnerabile.

Yarn

Se si usa Yarn, è possibile usare yarn perché trovare la catena di dipendenze completa.

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

La catena di dipendenze completa è eslintacorn>espree>. Dopo aver appreso la catena di dipendenze, è possibile usare un'altra funzionalità di Yarn, risoluzioni delle dipendenze selettive, per eseguire l'override della versione dicorn che viene usata.

Usare il campo risoluzioni in package.json per definire un override della versione. Vengono visualizzati tre diversi metodi per eseguire l'override di un pacchetto, in ordine di peggiore delle prestazioni:

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

L'uso del criterio esegue l'override**/acorn di tutti gli utilizzi del pacchetto acorn in tutte le dipendenze. È pericoloso e si interrompe in fase di esecuzione. Di conseguenza, è stato rimosso in Yarn v2.

L'uso del modello esegue l'override eslint/**/acorn di tutti gli utilizzi del pacchetto acorn nel pacchetto eslint e in tutti i pacchetti da cui dipende. È più sicuro che eseguire l'override del pacchetto per tutte le dipendenze, ma presenta comunque alcuni rischi se il grafico delle dipendenze per un pacchetto è di grandi dimensioni. Questo modello è consigliato quando sono presenti molti sottopacchetto che usano un pacchetto vulnerabile e la definizione di sostituzioni per singoli sottopacchetto sarebbe poco pratico.

L'uso del modello eslint/espree/acorn esegue l'override solo dell'utilizzo di acorn nel espree pacchetto nel eslint pacchetto. È destinato specificamente alla catena di dipendenze vulnerabile ed è il modo consigliato per eseguire l'override delle versioni dei pacchetti.

npm

Se si usa npm 8.3 o versione successiva, è possibile usare il campo delle sostituzioni nel package.json

Aggiungere un override se è necessario apportare modifiche specifiche alle dipendenze transitive. Ad esempio, potrebbe essere necessario aggiungere un override per sostituire la versione di una dipendenza con un problema di sicurezza noto, sostituire una dipendenza esistente con un fork o assicurarsi che la stessa versione di un pacchetto venga usata ovunque.

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

L'esempio di override illustrato illustra il modo di npm di dire "eseguire l'override solo dell'utilizzo di acorn nel espree pacchetto nel eslint pacchetto". È destinato specificamente alla catena di dipendenze vulnerabile ed è il modo consigliato per eseguire l'override delle versioni dei pacchetti. Le sostituzioni sono una funzionalità nativa di npm. Consente di sostituire un pacchetto nell'albero delle dipendenze con un'altra versione o un altro pacchetto completamente.

Dopo aver impostato le sostituzioni, è necessario eliminare package-lock.json ed node_modules eseguire npm install di nuovo.

Non è possibile impostare un override per un pacchetto da cui dipende direttamente, a meno che la dipendenza e l'override stesso non condivida esattamente la stessa specifica. Si supponga axios: "0.18.0" , ad esempio, che sia vulnerabile e che si sta cercando di eseguire l'aggiornamento a axios: "0.19.2". Modificare direttamente la versione della dipendenza anziché usare l'override.

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

Aggiornare la versione della dipendenza senza impostare un override:

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

Aggiornamento delle dipendenze per Maven

Il meccanismo di risoluzione delle dipendenze non è sofisticato come quello usato in Yarn. Di conseguenza, è possibile avere una sola versione di una dipendenza in un progetto. Per risolvere questo problema, Maven usa un algoritmo "wins più vicino". Ovvero, usa la versione della dipendenza più vicina al progetto nell'albero delle dipendenze.

Ad esempio, si dispone del grafico delle dipendenze seguente:

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

your-projectA:1.0.0dipende da , che a sua volta dipende, B:2.0.0 ma il progetto ha anche una dipendenza diretta da B:1.0.0. Sono quindi disponibili due versioni diverse della dipendenza B nel grafico delle dipendenze, ma la versione 1.0.0 della dipendenza B prevale perché è "più vicina" al progetto.

In alcuni casi, questo scenario potrebbe funzionare se le versioni sono compatibili. Tuttavia, se A:1.0.0 dipende da una funzionalità di B disponibile solo nella versione 2.0.0 , questo comportamento non funziona. In uno scenario peggiore, questo progetto può comunque essere compilato ma non riesce in fase di esecuzione.

Diamo un'occhiata a un esempio reale.

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

Si supponga che la versione di com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider dipende da una versione di com.fasterxml.jackson.core:jackson-databind con una deserializzazione di dati non attendibili.

È possibile verificare questa dipendenza usando il plug-in di dipendenza Maven. In questo caso si eseguirà mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind e si otterrà l'output seguente:

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

Prima di tutto, verificare se è presente una nuova versione di com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider che non dipende da una versione vulnerabile di com.fasterxml.jackson.core:jackson-databind. In tal caso, è possibile eseguire l'aggiornamento com.fasterxml.jackson.jaxrs:jackson-jaxrs-json-provider e arrestarlo. In caso contrario, eseguire l'override della versione di com.fasterxml.jackson.core:jackson-databind.

Come illustrato nel frammento di codice, quando si usa Maven "wins" più vicino, quindi la risoluzione consiste nell'aggiungere una dipendenza diretta a com.fasterxml.jackson.core:jackson-databind che corregge la vulnerabilità.

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

È possibile verificare che la risoluzione funzioni di nuovo eseguendo mvn dependency:tree -Dincludes=com.fasterxml.jackson.core:jackson-databind di nuovo.

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

È consigliabile aggiungere un commento vicino alla risoluzione delle dipendenze, in modo che chiunque venga in un secondo momento sappia perché la dipendenza è presente. Può essere rimosso dopo che la dipendenza radice usa la nuova versione; in caso contrario, si accumulano dipendenze.

In un progetto reale aggiungere la dipendenza il più alto possibile per la catena. Ad esempio, è possibile aggiungere la risoluzione nel file POM padre, anziché singolarmente in ogni file POM del progetto.

Aggiornamento delle dipendenze per NuGet

L'algoritmo di risoluzione delle dipendenze usato in NuGet è simile a Maven, in quanto è possibile usare solo una singola versione di una dipendenza. NuGet, tuttavia, non aggiunge le versioni delle dipendenze.

Ad esempio, se si ha una dipendenza <PackageReference Include="A" Version="1.2.3" />, è possibile che questo pacchetto sia equivalente a = 1.2.3, ma in realtà significa >= 1.2.3. Per aggiungere una versione esatta, è necessario usare Version="[1.2.3]". Per altre informazioni, vedere la documentazione relativa agli intervalli di versioni di NuGet.

Oltre al comportamento di intervallo predefinito, NuGet ripristina la versione più bassa applicabile per soddisfare un intervallo. Questo comportamento significa che in molti casi è necessario definire un intervallo.

Di seguito viene esaminato questo progetto di esempio, che ha una dipendenza da 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>

Dipende da una versione di Microsoft.AspNetCore.Http.Connections vulnerabile a una vulnerabilità di esecuzione remota del codice (RCE).

Prima di tutto, è necessario verificare se è presente una versione aggiornata di Microsoft.AspNetCore.App che dipende da una versione più recente di Microsoft.AspNetCore.Http.Connections. In tal caso, è possibile eseguire l'aggiornamento Microsoft.AspNetCore.App e arrestarlo qui. In caso contrario, è necessario eseguire l'override della versione di Microsoft.AspNetCore.Http.Connections esso dipende.

NuGet non ha un equivalente di yarn perché o mvn dependency:tree built-in, quindi il modo più semplice per vedere l'albero delle dipendenze è spesso visitare nuget.org. Se si visita la pagina NuGet per Microsoft.AspNetCore.App, si noterà che dipende da Microsoft.AspNetCore.Http.Connections version >= 1.0.4 && < 1.1.0. In alternativa, in un intervallo di versioni NuGet, la sintassi rappresentativa è [1.0.4,1.1.0).

La vulnerabilità RCE in Microsoft.AspNetCore.Http.Connections è stata corretta nella versione 1.0.15, quindi è necessario eseguire l'override dell'intervallo di versioni.[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>

È consigliabile aggiungere un commento vicino alla risoluzione delle dipendenze in modo che chiunque venga successivamente sappia perché la dipendenza è presente. Può essere rimosso dopo che la dipendenza radice usa la nuova versione. In caso contrario, si accumulano dipendenze.

Cosa succede se non è disponibile alcuna correzione?

Quando non è disponibile alcuna correzione nota, le opzioni seguenti sono disponibili come altri metodi di correzione fino a quando non è disponibile un componente aggiornato:

• Interrompere l'uso del componente e rimuoverlo dal codice. Questa rimozione viene rilevata alla compilazione successiva con l'attività di analisi delle dipendenze installata
• Contribuire a una correzione al componente stesso. Se l'organizzazione ha linee guida specifiche per i contributi open source, seguire queste linee guida.
• Ignorare l'avviso. Tuttavia, gli avvisi senza correzioni note possono comunque rappresentare una minaccia per la sicurezza per l'organizzazione. È consigliabile non ignorare un avviso solo perché non esiste alcuna correzione nota.

Ignorare gli avvisi di analisi delle dipendenze

Per ignorare gli avvisi in Sicurezza avanzata, sono necessarie le autorizzazioni appropriate. Per impostazione predefinita, solo gli amministratori del progetto hanno la possibilità di ignorare gli avvisi di sicurezza avanzata.

Per ignorare un avviso:

1. Passare all'avviso che si vuole chiudere e selezionare l'avviso
2. Selezionare l'elenco a discesa Chiudi avviso
3. Se non è già selezionata, selezionare Rischio accettato o Falso positivo come motivo di chiusura
4. Aggiungere un commento facoltativo nella casella di testo Commento
5. Selezionare Chiudi per inviare e chiudere l'avviso
6. Lo stato dell'avviso passa da Apri a Chiuso e visualizza il motivo di chiusura

Questa azione ignora solo l'avviso per il ramo selezionato. Altri rami che possono contenere la stessa vulnerabilità rimangono attivi fino a quando non diversamente agiscono. Qualsiasi avviso che è stato ignorato in precedenza può essere riaperto manualmente.

Gestione degli avvisi di analisi delle dipendenze nelle richieste pull

Se vengono creati avvisi per le nuove modifiche al codice in una richiesta pull, l'avviso viene segnalato come annotazione nella sezione commento della scheda Panoramica della richiesta pull e come avviso nella scheda Repository sicurezza avanzata. È disponibile una nuova voce di selezione ramo per il ramo di richiesta pull.

È possibile visualizzare il manifesto del pacchetto interessato, vedere un riepilogo della ricerca e risolvere l'annotazione nella sezione Panoramica.

Per ignorare gli avvisi delle richieste pull, è necessario passare alla visualizzazione dettagli avviso per chiudere l'avviso e risolvere l'annotazione. In caso contrario, la semplice modifica dello stato del commento (1) risolve l'annotazione, ma non chiude o corregge l'avviso sottostante.

Per visualizzare l'intero set di risultati per il ramo di richiesta pull, passare a Sicurezza avanzata Repos>e selezionare il ramo di richiesta pull. Selezionando Mostra altri dettagli (2) nell'annotazione viene visualizzata la visualizzazione dettagli avviso nella scheda Sicurezza avanzata.

Suggerimento

Le annotazioni verranno create solo quando le righe di codice interessate sono interamente univoche rispetto al ramo di destinazione della richiesta pull della richiesta pull.