Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo elenca le raccomandazioni che potrebbero essere visualizzate in Microsoft Defender per il cloud se si connette un ambiente Azure DevOps, GitHub o GitLab usando la pagina Impostazioni ambiente.
Le raccomandazioni visualizzate nell'ambiente sono basate sulle risorse protette e sulla configurazione personalizzata. È possibile visualizzare le raccomandazioni nel portale che si applicano alle risorse.
Per informazioni sulle azioni che è possibile eseguire in risposta a queste raccomandazioni, vedere Correggere le raccomandazioni in Defender per il cloud.
Altre informazioni sui vantaggi e sulle funzionalità di sicurezza di DevOps .
Le raccomandazioni di DevOps non influiscono sul punteggio di sicurezza. Per decidere quali raccomandazioni risolvere prima, esaminare la gravità di ogni raccomandazione e il potenziale impatto sul punteggio di sicurezza.
Azure DevOps raccomandazioni
Azure DevOps repository devono avere GitHub sicurezza avanzata per Azure DevOps (GHAzDO) abilitata
Descrizione: La sicurezza devOps in Defender per il cloud usa una console centrale per consentire ai team di sicurezza di proteggere le applicazioni e le risorse dal codice al cloud in Azure DevOps. Con l'abilitazione di repository GitHub Advanced Security for Azure DevOps (GHAzDO), tra cui GitHub Sicurezza avanzata per Azure DevOps, si ottengono risultati relativi a segreti, dipendenze e vulnerabilità del codice nei repository Azure DevOps rilevati in Microsoft Defender per il cloud.
Gravità: Alta
Azure DevOps repository devono avere i risultati dell'analisi dei segreti risolti
Descrizione: i segreti sono stati trovati nei repository di codice. Correggere immediatamente per evitare una violazione della sicurezza. I segreti trovati nei repository possono trapelare o essere individuati da avversari, causando la compromissione di un'applicazione o di un servizio. Lo strumento di analisi delle credenziali devOps Microsoft Security analizza solo le build su cui è configurato per l'esecuzione. Pertanto, i risultati potrebbero non riflettere lo stato completo dei segreti nei repository.
Gravità: Alta
Azure DevOps repository devono avere i risultati di analisi del codice risolti
Descrizione: le vulnerabilità sono state trovate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: Media
Azure DevOps repository devono avere i risultati di analisi delle vulnerabilità di dipendenza risolti
Descrizione: vulnerabilità delle dipendenze rilevate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: Media
I repository di Azure DevOps dovrebbero avere risolti i problemi rilevati dalla scansione dell'infrastruttura come codice
Descrizione: problemi di configurazione della sicurezza dell'infrastruttura come codice rilevati nei repository. I problemi sono stati rilevati nei file modello. Per migliorare il comportamento di sicurezza delle risorse cloud correlate, è consigliabile risolvere questi problemi.
Gravità: Media
Azure DevOps pipeline non devono avere segreti disponibili per le compilazioni di fork
Descrizione: nei repository pubblici è possibile che gli utenti esterni all'organizzazione creino fork ed eseguano compilazioni nel repository con fork. In questo caso, se questa impostazione è abilitata, gli esterni possono accedere ai segreti della pipeline di compilazione che devono essere interni.
Gravità: Alta
Azure DevOps connessioni al servizio non devono concedere l'accesso a tutte le pipeline
Descrizione: le connessioni al servizio vengono usate per creare connessioni da Azure Pipelines a servizi esterni e remoti per l'esecuzione di attività in un processo. Le autorizzazioni della pipeline controllano quali pipeline sono autorizzate a usare la connessione al servizio. Per supportare la sicurezza delle operazioni della pipeline, alle connessioni del servizio non deve essere concesso l'accesso a tutte le pipeline YAML. Ciò consente di mantenere il principio dei privilegi minimi perché una vulnerabilità nei componenti usati da una pipeline può essere usata da un utente malintenzionato per attaccare altre pipeline con accesso alle risorse critiche.
Gravità: Alta
Azure DevOps file sicuri non devono concedere l'accesso a tutte le pipeline
Descrizione: i file protetti offrono agli sviluppatori un modo per archiviare i file che possono essere condivisi tra le pipeline. Questi file vengono in genere usati per archiviare segreti, ad esempio certificati di firma e chiavi SSH. Se a un file sicuro viene concesso l'accesso a tutte le pipeline YAML, un utente non autorizzato può rubare informazioni dai file protetti creando una pipeline YAML e accedendo al file sicuro.
Gravità: Alta
Azure DevOps gruppi di variabili con variabili segrete non devono concedere l'accesso a tutte le pipeline
Descrizione: i gruppi di variabili archiviano i valori e i segreti che è possibile passare a una pipeline YAML o rendere disponibili in più pipeline. È possibile condividere e usare gruppi di variabili in più pipeline nello stesso progetto. Se un gruppo di variabili contenente segreti è contrassegnato come accessibile a tutte le pipeline YAML, un utente malintenzionato può sfruttare gli asset che coinvolgono le variabili segrete creando una nuova pipeline.
Gravità: Alta
Azure DevOps le connessioni al servizio di Azure classiche non devono essere usate per accedere a una sottoscrizione
Descrizione: usare il tipo Azure Resource Manager (ARM) delle connessioni al servizio anziché Azure connessioni al servizio classico per connettersi alle sottoscrizioni Azure. Il modello arm offre più miglioramenti alla sicurezza, tra cui un controllo di accesso più forte, un controllo migliorato, una distribuzione/governance basata su ARM, l'accesso alle identità gestite e all'insieme di credenziali delle chiavi per i segreti, l'autenticazione basata su Entra Permissions e il supporto per tag e gruppi di risorse per una gestione semplificata.
Gravità: Media
(Anteprima) Azure DevOps repository devono avere i risultati dei test di sicurezza delle API risolti
Descrizione: vulnerabilità di sicurezza api rilevate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: Media
(Anteprima) Azure DevOps repository devono richiedere l'approvazione minima di due revisori per i push di codice
Descrizione: per impedire il commit diretto di modifiche indesiderate o dannose, è importante implementare i criteri di protezione per il ramo predefinito nei repository Azure DevOps. È consigliabile richiedere almeno due revisori del codice per approvare le richieste pull prima che il codice venga unito al ramo predefinito. Richiedendo l'approvazione da un numero minimo di due revisori, è possibile ridurre il rischio di modifiche non autorizzate, che potrebbero causare instabilità del sistema o vulnerabilità di sicurezza.
Questa raccomandazione viene fornita in Defender per il cloud comportamento di sicurezza di base, se si è connessi Azure DevOps a Defender per il cloud.
Gravità: Alta
(Anteprima) Azure DevOps repository non devono consentire ai richiedenti di approvare le proprie richieste pull
Descrizione: per impedire il commit diretto di modifiche indesiderate o dannose, è importante implementare i criteri di protezione per il ramo predefinito nei repository Azure DevOps. È consigliabile impedire agli autori di richieste pull di approvare i propri invii per garantire che ogni modifica subisca una revisione obiettivo da parte di un utente diverso dall'autore. In questo modo, è possibile ridurre il rischio di modifiche non autorizzate, che potrebbero causare instabilità del sistema o vulnerabilità di sicurezza.
Questa raccomandazione viene fornita in Defender per il cloud comportamento di sicurezza di base, se si è connessi Azure DevOps a Defender per il cloud.
Gravità: Alta
(Anteprima) Azure DevOps progetti devono essere disabilitati la creazione di pipeline classiche
Descrizione: la disabilitazione della creazione di pipeline di compilazione e versione classica impedisce un problema di sicurezza che deriva da YAML e pipeline classiche che condividono le stesse risorse, ad esempio le stesse connessioni al servizio. I potenziali utenti malintenzionati possono sfruttare le pipeline classiche per creare processi che evase i meccanismi di difesa tipici configurati per le pipeline YAML moderne.
Gravità: Alta
GitHub raccomandazioni
GitHub organizzazioni non devono rendere accessibili i segreti delle azioni a tutti i repository
Descrizione: per i segreti usati nei flussi di lavoro GitHub Action archiviati a livello di organizzazione GitHub, è possibile usare i criteri di accesso per controllare quali repository possono usare i segreti dell'organizzazione. I segreti a livello di organizzazione consentono di condividere segreti tra più repository. In questo modo si riduce la necessità di creare segreti duplicati. Tuttavia, una volta reso accessibile un segreto a un repository, chiunque abbia accesso in scrittura nel repository può accedere al segreto da qualsiasi ramo in un flusso di lavoro. Per ridurre la superficie di attacco, assicurarsi che il segreto sia accessibile solo dai repository selezionati.
Questa raccomandazione viene fornita in Defender per il cloud comportamento di sicurezza di base, se si è connessi Azure DevOps a Defender per il cloud.
Gravità: Alta
GitHub repository devono avere l'analisi dei segreti abilitata
Description: GitHub analizza i repository per i tipi noti di segreti, per evitare l'uso fraudolento dei segreti di cui è stato accidentalmente eseguito il commit nei repository. L'analisi dei segreti analizzerà l'intera cronologia Git in tutti i rami presenti nel repository GitHub per individuare eventuali segreti. Esempi di segreti sono token e chiavi private che un provider di servizi può emettere per l'autenticazione. Se un segreto viene archiviato in un repository, chiunque abbia accesso in lettura al repository può usare il segreto per accedere al servizio esterno con tali privilegi. I segreti devono essere archiviati in una posizione sicura dedicata all'esterno del repository per il progetto.
Gravità: Alta
GitHub repository devono avere l'analisi del codice abilitata
Description: GitHub usa l'analisi del codice per analizzare il codice per individuare vulnerabilità ed errori di sicurezza nel codice. L'analisi del codice può essere usata per trovare, valutare e classificare in ordine di priorità le correzioni per i problemi esistenti nel codice. L'analisi del codice può anche impedire agli sviluppatori di introdurre nuovi problemi. Le analisi possono essere pianificate per giorni e ore specifiche oppure le analisi possono essere attivate quando si verifica un evento specifico nel repository, ad esempio un push. Se l'analisi del codice rileva una potenziale vulnerabilità o un errore nel codice, GitHub visualizza un avviso nel repository. Una vulnerabilità è un problema nel codice di un progetto che potrebbe essere sfruttato per danneggiare la riservatezza, l'integrità o la disponibilità del progetto.
Gravità: Media
GitHub repository devono avere l'analisi Dependabot abilitata
Description: GitHub invia avvisi Dependabot quando rileva le vulnerabilità nelle dipendenze del codice che interessano i repository. Una vulnerabilità è un problema nel codice di un progetto che potrebbe essere sfruttato per danneggiare la riservatezza, l'integrità o la disponibilità del progetto o di altri progetti che usano il codice. Le vulnerabilità variano in base al tipo, alla gravità e al metodo di attacco. Quando il codice dipende da un pacchetto che presenta una vulnerabilità di sicurezza, questa dipendenza vulnerabile può causare una serie di problemi.
Gravità: Media
GitHub repository devono essere risolti i risultati dell'analisi dei segreti
Descrizione: segreti trovati nei repository di codice. Questa operazione deve essere risolta immediatamente per evitare una violazione della sicurezza. I segreti trovati nei repository possono essere persi o individuati da avversari, causando la compromissione di un'applicazione o di un servizio.
Gravità: Alta
GitHub repository devono avere i risultati di analisi del codice risolti
Descrizione: vulnerabilità trovate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: Media
GitHub repository devono avere i risultati dell'analisi delle vulnerabilità di dipendenza risolti
Descrizione: GitHub repository devono avere i risultati di analisi delle vulnerabilità delle dipendenze risolti.
Gravità: Media
GitHub repository devono avere un'infrastruttura perché i risultati dell'analisi del codice sono stati risolti
Descrizione: sono stati rilevati problemi di configurazione dell'infrastruttura come codice nei repository. I problemi sono stati rilevati nei file modello. Per migliorare il comportamento di sicurezza delle risorse cloud correlate, è consigliabile risolvere questi problemi.
Gravità: Media
GitHub repository devono avere criteri di protezione per il ramo predefinito abilitato
Descrizione: il ramo predefinito del repository deve essere protetto tramite i criteri di protezione dei rami per impedire il commit diretto di modifiche indesiderate/dannose nel repository.
Gravità: Alta
GitHub repository devono avere forzare i push nel ramo predefinito disabilitato
Descrizione: poiché il ramo predefinito viene in genere usato per la distribuzione e altre attività con privilegi, le modifiche apportate devono essere affrontate con cautela. L'abilitazione delle operazioni di forza push può introdurre modifiche indesiderate o dannose al ramo predefinito.
Gravità: Media
GitHub organizzazioni devono avere la protezione push di analisi dei segreti abilitata
Descrizione: Protezione push blocca i commit che contengono segreti impedendo così l'esposizione accidentale dei segreti. Per evitare il rischio di esposizione delle credenziali, protezione push deve essere abilitata automaticamente per ogni repository abilitato per l'analisi dei segreti.
Gravità: Alta
GitHub repository non devono usare strumenti di esecuzione self-hosted
Descrizione: Self-Hosted Runner su GitHub mancanza di garanzie di funzionamento nelle macchine virtuali temporanee e può essere compromesso in modo permanente da codice non attendibile in un flusso di lavoro. Di conseguenza, Self-Hosted Runners non deve essere usato per i flussi di lavoro delle azioni.
Gravità: Alta
GitHub le organizzazioni devono disporre delle autorizzazioni del flusso di lavoro azioni impostate su sola lettura
Descrizione: per impostazione predefinita, ai flussi di lavoro di azione devono essere concesse autorizzazioni di sola lettura per impedire agli utenti malintenzionati di sfruttare flussi di lavoro con autorizzazioni eccessiva per accedere e manomettere le risorse.
Gravità: Alta
GitHub le organizzazioni devono avere più di una persona con autorizzazioni di amministratore
Descrizione: avere almeno due amministratori riduce il rischio di perdere l'accesso amministratore. Ciò è utile in caso di scenari di account break-glass.
Gravità: Alta
GitHub le organizzazioni devono avere autorizzazioni di base impostate su nessuna autorizzazione o lettura
Descrizione: le autorizzazioni di base devono essere impostate su nessuna o leggono affinché un'organizzazione segua il principio dei privilegi minimi e impedisca l'accesso non necessario.
Gravità: Alta
(Anteprima) GitHub repository devono essere risolti i risultati dei test di sicurezza delle API
Descrizione: le vulnerabilità di sicurezza delle API sono state trovate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: Media
(Anteprima) GitHub organizzazioni non devono rendere accessibili i segreti delle azioni a tutti i repository
Descrizione: per i segreti usati nei flussi di lavoro di GitHub Action archiviati a livello di organizzazione GitHub, è possibile usare i criteri di accesso per controllare quali repository possono usare i segreti dell'organizzazione. I segreti a livello di organizzazione consentono di condividere segreti tra più repository, riducendo la necessità di creare segreti duplicati. Tuttavia, quando un segreto viene reso accessibile a un repository, chiunque abbia accesso in scrittura nel repository può accedere al segreto da qualsiasi ramo in un flusso di lavoro. Per ridurre la superficie di attacco, assicurarsi che il segreto sia accessibile solo dai repository selezionati.
Gravità: Alta
(Anteprima) GitHub le organizzazioni devono bloccare Suggerimenti di Copilot che corrispondono al codice pubblico
Descrizione: l'abilitazione del filtro di GitHub Copilot per bloccare i suggerimenti di codice corrispondenti al codice pubblico in GitHub migliora la sicurezza e la conformità legale. Impedisce l'incorporazione involontaria di codice pubblico o open source, riducendo il rischio di problemi legali e garantendo la conformità alle condizioni di licenza. Inoltre, consente di evitare di introdurre potenziali vulnerabilità dal codice pubblico nei progetti dell'organizzazione, mantenendo così una maggiore qualità e sicurezza del codice. Quando il filtro è abilitato, GitHub Copilot controlla i suggerimenti di codice con il codice circostante di circa 150 caratteri rispetto al codice pubblico in GitHub. Se è presente una corrispondenza o una corrispondenza vicina, il suggerimento non verrà visualizzato.
Gravità: Alta
(Anteprima) GitHub organizzazioni devono applicare l'autenticazione a più fattori per i collaboratori esterni
Descrizione: l'applicazione dell'autenticazione a più fattori per i collaboratori esterni in un'organizzazione GitHub è una misura di sicurezza che richiede ai collaboratori di usare una forma aggiuntiva di identificazione oltre alla password per accedere ai repository e alle risorse dell'organizzazione. Ciò migliora la sicurezza proteggendo dall'accesso non autorizzato, anche se una password viene compromessa e contribuisce a garantire la conformità agli standard del settore. Implica l'informazione dei collaboratori sul requisito e il supporto per la transizione, riducendo infine il rischio di violazioni dei dati.
Gravità: Alta
(Anteprima) GitHub repository devono richiedere l'approvazione minima di due revisori per i push di codice
Descrizione: per impedire il commit diretto di modifiche indesiderate o dannose, è importante implementare i criteri di protezione per il ramo predefinito nei repository GitHub. È consigliabile richiedere almeno due revisori del codice per approvare le richieste pull prima che il codice venga unito al ramo predefinito. Richiedendo l'approvazione da un numero minimo di due revisori, è possibile ridurre il rischio di modifiche non autorizzate, che potrebbero causare instabilità del sistema o vulnerabilità di sicurezza.
Gravità: Alta
Raccomandazioni su GitLab
I progetti GitLab devono avere i risultati dell'analisi dei segreti risolti
Descrizione: i segreti sono stati trovati nei repository di codice. Questa operazione deve essere risolta immediatamente per evitare una violazione della sicurezza. I segreti trovati nei repository possono essere persi o individuati da avversari, causando la compromissione di un'applicazione o di un servizio.
Gravità: Alta
I progetti GitLab devono avere i risultati di analisi del codice risolti
Descrizione: le vulnerabilità sono state trovate nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità.
Gravità: Media
I progetti GitLab devono avere i risultati dell'analisi delle vulnerabilità delle dipendenze risolti
Descrizione: GitHub repository devono avere i risultati di analisi delle vulnerabilità delle dipendenze risolti.
Gravità: Media
I progetti GitLab devono avere un'infrastruttura perché i risultati dell'analisi del codice risolti
Descrizione: sono stati rilevati problemi di configurazione dell'infrastruttura come codice nei repository. I problemi mostrati sono stati rilevati nei file modello. Per migliorare il comportamento di sicurezza delle risorse cloud correlate, è consigliabile risolvere questi problemi.
Gravità: Media
Raccomandazioni sulla sicurezza di DevOps deprecate
I repository di codice devono avere i risultati di analisi del codice risolti
Descrizione: la sicurezza devOps in Defender per il cloud ha rilevato vulnerabilità nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità. (Nessun criterio correlato)
Gravità: Media
I repository di codice devono avere i risultati dell'analisi dei segreti risolti
Descrizione: la sicurezza devOps in Defender per il cloud ha trovato un segreto nei repository di codice. Questa operazione deve essere risolta immediatamente per evitare una violazione della sicurezza. I segreti trovati nei repository possono essere persi o individuati da avversari, causando la compromissione di un'applicazione o di un servizio. Per Azure DevOps, lo strumento DevOps CredScan Microsoft Security analizza solo le build su cui è stato configurato per l'esecuzione. Pertanto, i risultati potrebbero non riflettere lo stato completo dei segreti nei repository. (Nessun criterio correlato)
Gravità: Alta
I repository di codice devono avere i risultati di analisi Dependabot risolti
Descrizione: la sicurezza devOps in Defender per il cloud ha rilevato vulnerabilità nei repository di codice. Per migliorare il comportamento di sicurezza dei repository, è consigliabile correggere queste vulnerabilità. (Nessun criterio correlato)
Gravità: Media
I repository di codice devono avere un'infrastruttura perché i risultati dell'analisi del codice sono stati risolti
Descrizione: la sicurezza devOps in Defender per il cloud ha rilevato un'infrastruttura come problemi di configurazione della sicurezza del codice nei repository. I problemi mostrati sono stati rilevati nei file modello. Per migliorare il comportamento di sicurezza delle risorse cloud correlate, è consigliabile risolvere questi problemi. (Nessun criterio correlato)
Gravità: Media
GitHub repository devono avere l'analisi del codice abilitata
Description: GitHub usa l'analisi del codice per analizzare il codice per individuare vulnerabilità ed errori di sicurezza nel codice. L'analisi del codice può essere usata per trovare, valutare e classificare in ordine di priorità le correzioni per i problemi esistenti nel codice. L'analisi del codice può anche impedire agli sviluppatori di introdurre nuovi problemi. Le analisi possono essere pianificate per giorni e ore specifiche oppure le analisi possono essere attivate quando si verifica un evento specifico nel repository, ad esempio un push. Se l'analisi del codice rileva una potenziale vulnerabilità o un errore nel codice, GitHub visualizza un avviso nel repository. Una vulnerabilità è un problema nel codice di un progetto che potrebbe essere sfruttato per danneggiare la riservatezza, l'integrità o la disponibilità del progetto. (Nessun criterio correlato)
Gravità: Media
GitHub repository devono avere l'analisi dei segreti abilitata
Description: GitHub analizza i repository per i tipi noti di segreti, per evitare l'uso fraudolento dei segreti di cui è stato accidentalmente eseguito il commit nei repository. L'analisi dei segreti analizzerà l'intera cronologia Git in tutti i rami presenti nel repository GitHub per individuare eventuali segreti. Esempi di segreti sono token e chiavi private che un provider di servizi può emettere per l'autenticazione. Se un segreto viene archiviato in un repository, chiunque abbia accesso in lettura al repository può usare il segreto per accedere al servizio esterno con tali privilegi. I segreti devono essere archiviati in una posizione sicura dedicata all'esterno del repository per il progetto. (Nessun criterio correlato)
Gravità: Alta
GitHub repository devono avere l'analisi Dependabot abilitata
Description: GitHub invia avvisi Dependabot quando rileva le vulnerabilità nelle dipendenze del codice che interessano i repository. Una vulnerabilità è un problema nel codice di un progetto che potrebbe essere sfruttato per danneggiare la riservatezza, l'integrità o la disponibilità del progetto o di altri progetti che usano il codice. Le vulnerabilità variano in base al tipo, alla gravità e al metodo di attacco. Quando il codice dipende da un pacchetto che presenta una vulnerabilità di sicurezza, questa dipendenza vulnerabile può causare una serie di problemi. (Nessun criterio correlato)
Gravità: Media