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 che compila nuovo codice (in altre parole, un nuovo commit).
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.
Ecosistemi di pacchetti supportati
L'analisi delle dipendenze supporta dipendenze dirette e transitive per tutti gli ecosistemi di pacchetti supportati.
| Strumento di gestione pacchetti | Lingue | Formati supportati |
|---|---|---|
| Cargo | Rust | Cargo.toml, Cargo.lock |
| CocoaPods | Swift | Podfile.lock |
| Moduli Go | Go | go.mod, go.sum |
| Gradle | Java | *.lockfile |
| Maven | Java | pom.xml |
| npm | JavaScript | package-lock.json, package.json, npm-shrinkwrap.jsonlerna.json |
| NuGet | C# | *.packages.config, *.project.assets, *.csproj |
| pip | Python | setup.py, requirements.txt |
| pnpm | JavaScript | package.json |
| RubyGems | Ruby | Gemfile.lock |
| Yarn | JavaScript | package.json |
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 verrà 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:
- Passare all'avviso che si vuole chiudere e selezionare l'avviso
- Selezionare l'elenco a discesa Chiudi avviso
- Se non è già selezionata, selezionare Rischio accettato o Falso positivo come motivo di chiusura
- Aggiungere un commento facoltativo nella casella di testo Commento
- Selezionare Chiudi per inviare e chiudere l'avviso
- 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.
Risoluzione dei problemi di analisi delle dipendenze
Analisi delle dipendenze che non identifica alcun componente
Se l'attività di analisi delle dipendenze viene completata senza contrassegnare alcun componente e non generare avvisi per i componenti con vulnerabilità note, assicurarsi di disporre di un passaggio di ripristino del pacchetto prima dell'attività AdvancedSecurity-Dependency-Scanning@1 .
Ad esempio, per un progetto C# (.NET Core), di seguito è riportato un frammento YAML di esempio:
- task: DotNetCoreCLI@2
displayName: 'Restore NuGet packages'
inputs:
command: 'restore'
projects: '**/*.csproj'
# If you are using a private package feed such as Azure Artifacts, you will need additional variables.
# For more information, see https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/dotnet-core-cli-v2?view=azure-pipelines
feedsToUse: 'select'
...
- task: AdvancedSecurity-Dependency-Scanning@1
Per un progetto JavaScript, di seguito è riportato un frammento di codice YAML di esempio:
- task: Npm@1
displayName: 'npm install'
inputs:
command: 'install'
workingDir: '$(System.DefaultWorkingDirectory)'
- task: AdvancedSecurity-Dependency-Scanning@1
Analisi delle dipendenze non rileva nuove vulnerabilità
Se si esegue una nuova compilazione ma non vengono visualizzate nuove vulnerabilità come previsto, assicurarsi che la compilazione venga eseguita con un nuovo commit.
Timeout dell'attività di analisi delle dipendenze
L'ora predefinita di esecuzione dell'attività di analisi delle dipendenze prima del timeout è di 300 secondi o 5 minuti. Se l'attività si verifica un timeout prima del completamento, è possibile impostare una variabile DependencyScanning.Timeoutdella pipeline , che prevede un numero intero che rappresenta i secondi, ad esempio DependencyScanning.Timeout: 600. Qualsiasi elemento con il timeout predefinito di 300 secondi non ha alcun effetto.
Per usare questa variabile, aggiungere DependencyScanning.Timeout come variabile della pipeline:
- task: AdvancedSecurity-Dependency-Scanning@1
- env:
DependencyScanning.Timeout: 600
Scenario break-glass per l'attività di compilazione
Se l'attività di compilazione dell'analisi delle dipendenze blocca un'esecuzione corretta della pipeline ed è necessario ignorare urgentemente l'attività di compilazione, è possibile impostare una variabile DependencyScanning.Skip: truedella pipeline .
Autorizzazioni delle attività di analisi delle dipendenze
L'attività di compilazione analisi delle dipendenze usa l'identità della pipeline per chiamare le API REST di sicurezza avanzata. Per impostazione predefinita, le pipeline nello stesso progetto hanno accesso per recuperare gli avvisi. Se si rimuovono tali autorizzazioni dall'account del servizio di compilazione o se si dispone di un'installazione personalizzata , ad esempio una pipeline ospitata in un progetto diverso dal repository, è necessario concedere queste autorizzazioni manualmente.
Concedere Advanced Security: View Alerts l'autorizzazione all'account del servizio di compilazione usato nella pipeline, che per le pipeline con ambito progetto è [Project Name] Build Service ([Organization Name])e per le pipeline con ambito raccolta è Project Collection Build Service ([Organization Name]).
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per