Come gestire un repository GitHub sicuro

Completato

In questa sezione vengono illustrati alcuni degli strumenti e delle tecniche di sicurezza essenziali disponibili per gli amministratori del repository GitHub.

Annotazioni

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

L'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.

Quali sono i problemi 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, dobbiamo garantire che le informazioni vengano modificate o distrutte solo quando è appropriato.

È necessario assicurarsi di autenticare correttamente chi accede ai dati e di disporre delle autorizzazioni corrette per farlo. Tramite dati o log cronologici o di archiviazione, è necessario essere in grado di trovare prove in caso di errore.

Esistono molti aspetti per la creazione e la distribuzione di applicazioni sicure. Ecco tre aspetti da considerare:

• C'è un problema generale di conoscenza: molti sviluppatori e altri membri del personale presuppongono che comprendano la sicurezza, ma non lo fanno. La cybersecurity è una disciplina in continua evoluzione. Un programma di formazione continua è essenziale.

• Il codice deve essere creato correttamente e in modo sicuro: è necessario assicurarsi che il codice venga creato correttamente e implementi in modo sicuro le funzionalità necessarie. È anche necessario assicurarsi che le funzionalità siano state progettate tenendo presente la sicurezza.

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

Sicurezza in ogni passaggio

La sicurezza non è un elemento che è possibile aggiungere in un secondo momento a un'applicazione o a un sistema. Lo sviluppo sicuro deve far parte di ogni fase del ciclo di vita dello sviluppo software. Questo concetto è ancora più importante per le applicazioni critiche e per le applicazioni che elaborano informazioni riservate o estremamente riservate.

In pratica, per tenere i team responsabili di ciò che sviluppano, i processi devono spostarsi a sinistra o essere completati in precedenza nel ciclo di vita dello sviluppo. Spostando i passaggi da un gate finale in fase di distribuzione a un passaggio precedente, vengono effettuati meno errori e gli sviluppatori possono spostarsi più rapidamente.

In passato, i concetti di sicurezza delle applicazioni non erano al centro dell'attenzione degli sviluppatori. Oltre ai problemi di istruzione e formazione, le loro organizzazioni hanno sottolineato lo sviluppo rapido delle funzionalità.

Tuttavia, con l'introduzione delle procedure DevOps, i test di sicurezza sono più facili da integrare nella pipeline. Invece di essere un'attività eseguita dagli specialisti della sicurezza, i test di sicurezza devono far parte solo dei processi di consegna quotidiani.

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 Sicurezza

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

1. Su GitHub.com, vai alla pagina principale del repository.

2. Sotto il nome del repository selezionare Sicurezza.

Dalla scheda Sicurezza è possibile aggiungere funzionalità al flusso di lavoro di GitHub per evitare vulnerabilità nel repository e nella codebase. Queste funzionalità includono:

• Criteri di sicurezza che consentono di specificare come segnalare una vulnerabilità di sicurezza nel progetto aggiungendo un SECURITY.md file al repository.
• Dependabot avvisi che segnalano quando GitHub rileva che il repository usa una dipendenza vulnerabile o un malware.
• 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.

Verranno ora esaminate alcune di queste funzionalità e si apprenderà come distribuire le responsabilità operative e di sicurezza in tutte le fasi del ciclo di vita dello sviluppo 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 correzioni di bug pubblicamente ha alcune responsabilità. L'aspetto più importante è la divulgazione responsabile delle informazioni che potrebbero portare a exploit di sicurezza prima che i bug sottostanti possano essere corretti. Gli sviluppatori che cercano di segnalare o risolvere i problemi di sicurezza cercano un SECURITY.md file nella radice di un repository per divulgare in modo responsabile le proprie preoccupazioni. Fornire indicazioni in questo file accelera infine la risoluzione di questi 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 di repository di discutere privatamente e correggere 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 di repository semplificano alla comunità l'aggiornamento delle dipendenze dei pacchetti e l'analisi delle conseguenze delle vulnerabilità di sicurezza. GitHub archivia gli avvisi pubblicati nell'elenco delle Vulnerabilità ed Esposizioni Comuni (CVE). 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.

Tieni i file sensibili fuori dal tuo repository con .gitignore

È facile per gli sviluppatori ignorare i file inclusi in un commit. A volte questi file trascurati non sono dannosi, ad esempio 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 per evitare questo rischio consiste nel creare e gestire .gitignore i file. Questi file indicano agli strumenti client, ad esempio l'utilità della riga di comando, di ignorare i percorsi e i modelli durante l'aggregazione git dei 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ù .gitignore file. 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 radice .gitignore , anche se l'aggiunta di un .gitignore file in una directory di progetto può essere utile quando tale progetto presenta 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 Ignorare i file. Consulta anche la raccolta dei file .gitignore iniziali offerti per diverse piattaforme nel repository gitignore.

Rimuovere dati sensibili da un repository

Anche se .gitignore i file possono essere utili per aiutare i collaboratori a evitare il commit dei dati sensibili, sono solo un suggerimento forte. Gli sviluppatori possono comunque aggirare un .gitignore file per aggiungere file se sono sufficientemente motivati e talvolta i file potrebbero scivolare perché non soddisfano la configurazione del .gitignore file. I partecipanti al progetto devono sempre essere alla ricerca di commit che contengono dati che non devono essere inclusi nel repository o nella relativa cronologia.

Importante

Si supponga che tutti i dati di cui è stato eseguito il commit in GitHub in qualsiasi momento siano stati compromessi. La semplice sovrascrittura di un commit non è sufficiente per garantire che i dati non saranno 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 l'approvazione di una revisione o il superamento dei controlli di stato per tutte le pull request 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 verificare la presenza di errori di digitazione e la conformità alle convenzioni di codifica interne;
• Eseguire test automatizzati per verificare eventuali modifiche del comportamento 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 sia nella radice del repository che nella cartella docs o .github.