Dependabot, advisory e piano di risposta
Un amministratore non legge il codice delle dipendenze: governa il meccanismo che le tiene sotto controllo e scrive la procedura che scatta quando il controllo ha già fallito. Questa unità mette in fila le due cose, dal grafo delle dipendenze fino alla revoca di una credenziale esposta. Le pagine di riferimento qui sono quelle di GitHub Enterprise Cloud; su GitHub Enterprise Server la disponibilità delle singole funzionalità dipende dalla versione dell’istanza, quindi va verificata sulla documentazione della propria release prima di promettere una copertura all’audit.
I tre livelli di Dependabot
Il presupposto di tutto è il dependency graph, che ricostruisce i pacchetti da cui il repository dipende. Su quel grafo lavorano i Dependabot alerts, che analizzano il ramo predefinito e si aprono in tre casi: quando una nuova vulnerabilità entra nel GitHub Advisory Database, quando l’enterprise pubblica una innersource advisory che riguarda una dipendenza interna, e quando il grafo stesso cambia perché qualcuno ha modificato un manifest. Attenzione al filtro: generano alert solo le advisory revisionate da GitHub o pubblicate dall’enterprise come innersource, non tutto ciò che compare nel database. La notifica via email raggiunge chi ha permesso write, maintain o admin sul repository e ha attivato le notifiche relative: già qui si capisce che la notifica da sola non è un piano di risposta, perché arriva a chiunque scriva codice e a nessun ruolo responsabile.
Dagli alert discendono i Dependabot security updates, cioè pull request che sostituiscono la versione vulnerabile. Richiedono grafo e alert attivi, e agiscono solo su dipendenze dichiarate in un manifest o in un lock file. Il comportamento da ricordare è che, una volta abilitati, Dependabot prova ad aprire una pull request per ogni alert aperto: se volete selettività, la strada non è lasciarli accesi sperando in poco rumore, ma disattivarli e governare gli alert con le regole di auto-triage.
Cosa diversa sono i Dependabot version updates, che tengono aggiornate le dipendenze anche in assenza di vulnerabilità. Non sono un interruttore: si configurano committando un file dependabot.yml nel repository, dove si dichiarano ecosistema, directory e pianificazione. Le nuove release vengono adottate solo dopo un periodo di cooldown, che gli aggiornamenti di sicurezza invece ignorano. La confusione tipica in esame è esattamente questa: gli alert e i security updates si abilitano centralmente come impostazioni, i version updates vivono nel file di configurazione del singolo repository.
Abilitare e governare su scala
Repository per repository non regge. Lo strumento di governo sono le custom security configurations, raggiungibili da Settings > Advanced Security > Security configurations > New configuration. Una configurazione raccoglie l’abilitazione di dependency graph, Dependabot alerts, Dependabot security updates, private vulnerability reporting, secret scanning e code scanning, ciascuna su tre stati: Enabled, Disabled oppure Not set, che lascia intatta l’impostazione esistente. Con Enforce i proprietari dei repository non possono più cambiare ciò che la configurazione decide, mentre le voci Not set non vengono mai forzate. Il punto che costa punti è l’applicazione: designare una configurazione come predefinita la applica automaticamente ai repository nuovi, quelli già esistenti vanno assegnati esplicitamente.
Sopra gli alert si mettono le Dependabot auto-triage rules. A livello di organizzazione le gestiscono gli owner e i security managers, scegliendo fra Enforced e Enabled (nel secondo caso un admin di repository può disattivarle). I criteri disponibili includono severità, ecosistema, ambito della dipendenza, nome del pacchetto, CVE ID, GHSA ID, CWE, disponibilità della patch e punteggio EPSS; le azioni sono Dismiss alerts oppure aprire una pull request, quest’ultima solo se i security updates sono disattivati. Sulle repository private e interne le regole custom rientrano in GitHub Code Security, che insieme a GitHub Secret Protection ha sostituito il prodotto unico che molti chiamano ancora Advanced Security. Per misurare il risultato si usa Security overview, con le viste Overview, Risk e Coverage.
Advisory di repository e segnalazione privata
Quando la vulnerabilità è nel vostro codice, lo strumento è la repository security advisory, gestibile da chi ha permesso admin. Si crea come bozza privata, si lavora alla correzione in un private temporary fork, si accreditano i collaboratori e solo alla fine si pubblica. GitHub è CVE Numbering Authority: potete indicare un CVE già assegnato o richiederne uno, che resta riservato fino alla pubblicazione. Dopo la pubblicazione l’advisory entra nel GitHub Advisory Database e può generare Dependabot alerts sui repository che vi dipendono, per questo va pubblicata indicando una versione corretta. Il canale in ingresso è invece il private vulnerability reporting, che permette a un ricercatore di segnalare dentro GitHub senza esporre nulla; dove non è attivo, resta il file SECURITY.md, pubblicabile una volta sola come default community health file nel repository .github dell’organizzazione.
Il piano di risposta
Un piano di risposta si valuta su quattro elementi. Chi viene avvisato: non le notifiche automatiche, ma ruoli nominati, tipicamente i security managers, con una catena di escalation nota. Come si revoca: un token esposto va ruotato, non nascosto: riscrivere la storia di Git non revoca nulla, mentre un token valido pubblicato su un repository o gist pubblico viene revocato automaticamente e gli enterprise owner possono revocare autorizzazioni SSO ed eliminare credenziali degli utenti anche in blocco. Un token revocato non è ripristinabile, ed è la proprietà che rende la revoca preferibile a ogni valutazione d’impatto. Quali evidenze si raccolgono: l’audit log dell’enterprise, con ricerca, esportazione, streaming verso il SIEM e identificazione degli eventi compiuti da un access token. Come si verifica che non si ripeta: push protection attiva con delegated bypass, la configurazione di sicurezza in modalità Enforce e la vista Coverage a confermare che la copertura sia davvero totale e non dichiarata.