Come gestire un repository GitHub sicuro

Completato

In questo articolo vengono illustrati alcuni strumenti e tecniche di sicurezza essenziali disponibili per gli amministratori del repository GitHub.

Nota

Il contenuto seguente non illustra i concetti fondamentali per la scrittura di codice sicuro, ma piuttosto importanti considerazioni, strumenti e funzionalità di sicurezza da usare all'interno di un repository GitHub.

Importanza di una strategia di sviluppo sicura

La sicurezza delle applicazioni è importante. I servizi di notizie spesso riportano storie su alcune violazioni dei sistemi di un'azienda e dei dati privati e dei clienti rubati.

Quindi, quali sono gli aspetti da considerare quando si pianifica una strategia di sviluppo sicura? Chiaramente, dobbiamo proteggere le informazioni dalla divulgazione a persone che non dovrebbero accedervi, ma, più importante ancora, dobbiamo garantire che le informazioni vengano modificate o distrutte solo quando è appropriato.

È necessario assicurarsi di autenticare correttamente gli utenti che accedono ai dati e verificare che abbiano le autorizzazioni corrette per farlo. Tramite dati o log cronologici o di archivio, è necessario essere in grado di rilevare quando qualcosa va storto.

Ci sono diversi aspetti di considerare per lo sviluppo e la distribuzione di applicazioni sicure. Eccone tre:

• In primo luogo, c'è un problema generale di conoscenze: Molti sviluppatori e altri membri del personale presumono di capirne di sicurezza, mentre non è così. La cybersecurity è una disciplina in costante evoluzione. È essenziale seguire un programma continuo di istruzione e formazione.

• Il codice deve essere creato in modo corretto e sicuro: È necessario assicurarsi che il codice venga creato correttamente e che implementi le funzionalità necessarie in tutta sicurezza. È anche necessario assicurarsi che le funzionalità vengano progettate tenendo conto della sicurezza.

• Le applicazioni devono essere conformi a regole e a normative: È necessario assicurarsi che il codice sia conforme alle regole e alle normative richieste. È necessario verificare la conformità durante la compilazione del codice e ripetere periodicamente i test, anche dopo la distribuzione.

Sicurezza a ogni passaggio

La sicurezza non è qualcosa che si può semplicemente aggiungere a un'applicazione o a un sistema in un secondo momento. La sicurezza deve essere integrata in ogni fase del ciclo di vita dello sviluppo di software. Questo concetto è ancora più importante per le applicazioni critiche e per le applicazioni che elaborano informazioni riservate o estremamente riservate.

In pratica, per rendere i team responsabili di ciò che sviluppano, è necessario spostare a sinistra i processi, o averli completati in precedenza, all'inizio del ciclo di vita dello sviluppo. Spostando i passaggi dalla fase finale di distribuzione a un passaggio precedente, si riduce il numero di errori e gli sviluppatori possono procedere più rapidamente.

In passato i concetti relativi alla sicurezza delle applicazioni non sono rientrati negli obiettivi degli sviluppatori. Oltre ai problemi di istruzione e formazione, il motivo è che le organizzazioni ponevano l'accento soprattutto sulla velocità dello sviluppo di funzionalità.

Con l'introduzione delle procedure DevOps, tuttavia, i test di sicurezza sono più facili da integrare nella pipeline. I test di sicurezza dovrebbero far parte dei processi quotidiani di distribuzione, invece di essere una prerogativa degli specialisti della sicurezza.

Nel complesso, quando viene preso in considerazione il tempo necessario per la rielaborazione, l'aggiunta della sicurezza alle procedure DevOps in precedenza nel ciclo di vita di sviluppo consente ai team di sviluppo di rilevare i problemi in precedenza. Rilevare i problemi in precedenza può effettivamente ridurre il tempo complessivo necessario per sviluppare software di qualità.

Lo spostamento a sinistra è una modifica del processo, ma non è un singolo controllo o uno strumento specifico. Si tratta di rendere tutta la sicurezza più incentrata sugli sviluppatori e fornire agli sviluppatori commenti e suggerimenti sulla sicurezza in cui si trovano.

Funzionalità della scheda Security

GitHub offre funzionalità di sicurezza che consentono di proteggere i dati nei repository e nelle organizzazioni. Per individuare la scheda Security:

1. In GitHub.com passare alla pagina principale del repository.

2. Sotto il nome del repository selezionare Security.

Dalla scheda Security è possibile aggiungere funzionalità al flusso di lavoro di GitHub per evitare l'ingresso di vulnerabilità nel repository e nella codebase. Queste funzionalità sono:

• Criteri di sicurezza che consentono di specificare come segnalare una vulnerabilità di sicurezza nel progetto aggiungendo un file SECURITY.md al repository.
• Avvisi Dependabot che segnalano quando GitHub rileva che il repository usa una dipendenza o un malware vulnerabile.
• Avvisi di sicurezza che è possibile usare per discutere privatamente, correggere e pubblicare informazioni sulle vulnerabilità di sicurezza nel repository.
• Analisi del codice che consente di trovare, valutare e correggere vulnerabilità ed errori nel codice.

Per altre informazioni, vedere Funzionalità di sicurezza di GitHub.

Nota

Gli avvisi Dependabot per il malware sono attualmente in versione beta e sono soggetti a modifiche. Solo gli avvisi che sono stati verificati da GitHub attiveranno gli avvisi Dependabot.

Successivamente vengono esaminate alcune di queste funzionalità e vengono illustrati alcuni modi per distribuire le responsabilità operative e relative alla sicurezza in tutte le fasi del ciclo di vita dello sviluppo del software.

Comunicare i criteri di sicurezza con SECURITY.md

I vantaggi della community di GitHub sono sostanziali, ma comportano anche potenziali rischi. Il fatto che chiunque possa proporre pubblicamente correzioni dei bug implica determinate responsabilità. La più importante è la divulgazione responsabile delle informazioni che potrebbero causare exploit per la sicurezza prima che i bug sottostanti possano essere corretti. Gli sviluppatori che vogliono segnalare o affrontare i problemi di sicurezza cercano un file SECURITY.md nella radice di un repository per divulgare responsabilmente le problematiche che hanno rilevato. L'inserimento di linee guida in questo file in definitiva accelera la risoluzione dei problemi critici.

Per altre informazioni su SECURITY.md, vedere Aggiunta di un criterio di sicurezza al repository.

Avvisi di sicurezza di GitHub

Gli avvisi di sicurezza di GitHub consentono ai gestori del repository di discutere e correggere in privato una vulnerabilità di sicurezza in un progetto. Dopo che i gestori del repository collaborano a una correzione, possono pubblicare l'avviso di sicurezza per divulgare pubblicamente la vulnerabilità di sicurezza alla community del progetto. Pubblicando avvisi di sicurezza, i gestori del repository semplificano l'aggiornamento delle dipendenze dei pacchetti e la ricerca delle conseguenze delle vulnerabilità di sicurezza da parte della community. GitHub archivia gli avvisi pubblicati nell'elenco Vulnerabilità ed esposizione comuni (CVE - Common Vulnerabilities and Exposures). Questo elenco viene usato per notificare automaticamente ai repository interessati che usano software con una vulnerabilità elencata. Per altre informazioni, vedere Informazioni sugli avvisi di sicurezza del repository.

Mantenere i file sensibili al di fuori del repository mediante .gitignore

I file inclusi in un commit vengono spesso trascurati dagli sviluppatori. A volte questi file sono benigni, come i file di compilazione intermedi. Tuttavia, esiste sempre il rischio che qualcuno possa eseguire inavvertitamente il commit di dati sensibili. Ad esempio, un utente potrebbe eseguire il commit di una chiave API o di dati di configurazione privati che un attore malintenzionato potrebbe usare. Una tecnica che consente di evitare questi rischi consiste nel creare e mantenere file .gitignore. Questi file indicano agli strumenti client, ad esempio l'utilità da riga di comando git, di ignorare i percorsi e i modelli quando si aggregano i file per un commit.

L'esempio seguente illustra alcuni dei casi d'uso comuni per ignorare i file:

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

Il repository potrebbe includere più file .gitignore. Le impostazioni vengono ereditate dalle directory padre, con campi di override nei nuovi file .gitignore che hanno la precedenza rispetto alle impostazioni delle directory padre per le cartelle e le sottocartelle. È importante mantenere il file .gitignore radice, anche se l'aggiunta di un file .gitignore in una directory del progetto può essere utile quando tale progetto ha requisiti specifici che sono più facili da gestire separatamente dall'elemento padre, ad esempio i file che non devono essere ignorati.

Per altre informazioni su .gitignore, vedere Esclusione di file. Vedere anche la raccolta di file .gitignore iniziali offerti per diverse piattaforme nel repository gitignore.

Rimuovere i dati sensibili da un repository

Anche se il file .gitignore possono risultare utili per aiutare i collaboratori a evitare di eseguire il commit di dati sensibili, si tratta semplicemente di un suggerimento. Gli sviluppatori possono comunque aggirarlo per aggiungere file se sono sufficientemente motivati ed è possibile che talvolta alcuni file sfuggano perché non soddisfano la configurazione del file .gitignore. I partecipanti al progetto dovrebbero essere sempre alla ricerca di commit contenenti dati che non devono essere inclusi nel repository o nella relativa cronologia.

Importante

Si deve presupporre che qualsiasi dato sottoposto a commit in GitHub in qualsiasi momento sia stato compromesso. La semplice sovrascrittura di un commit non è sufficiente per garantire che i dati non siano accessibili in futuro. Per la guida completa alla rimozione di dati sensibili da GitHub, vedere Rimozione di dati sensibili da un repository.

Regole di protezione dei rami

È possibile creare una regola di protezione dei rami per applicare determinati flussi di lavoro per uno o più rami. Ad esempio, è possibile richiedere una revisione di approvazione o il passaggio di controlli di stato per tutte le richieste pull unite nel ramo protetto.

È possibile usare i flussi di lavoro che proteggono il ramo per:

• Eseguire una compilazione per verificare che le modifiche al codice possano essere compilate
• Eseguire un linter per controllare la presenza di errori di digitazione e conformità alle convenzioni di codifica interne
• Eseguire test automatizzati per controllare la presenza di eventuali modifiche funzionali del codice
• E così via

Aggiungere un file CODEOWNERS

Aggiungendo un file CODEOWNERS al repository, è possibile assegnare singoli membri del team o interi team come proprietari del codice ai percorsi nel repository. Questi proprietari di codice sono quindi necessari per le revisioni delle richieste pull su eventuali modifiche ai file in un percorso per il quale sono configurati.

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

È possibile creare il file CODEOWNERS nella radice del repositorydocs o .github nella cartella.