Una linea di sicurezza si applica come oggetto, non repository per repository
Un’enterprise con decine o centinaia di repository non può abilitare la scansione dei segreti aprendo una scheda alla volta: il lavoro non finisce mai e il risultato non è verificabile. La risposta di GitHub è la security configuration, un insieme di impostazioni di abilitazione dei prodotti di sicurezza salvato come oggetto riutilizzabile e poi applicato a molti repository in un colpo solo.
Una configurazione si crea dalle impostazioni dell’organizzazione (o dell’enterprise) nella sezione dedicata a Code security, con New configuration. Dentro raccogli le leve che altrimenti vivrebbero sparse: le funzionalità di Secret Protection — controlli di validità, metadati estesi, pattern generici, rilevamento dei segreti tramite AI, push protection, privilegi di bypass, controllo sulla chiusura degli alert — le funzionalità di Code Security come il default setup e il tipo di runner, poi dependency graph, alert e aggiornamenti di Dependabot, e il private vulnerability reporting. Nella stessa configurazione dichiari anche l’ambito di licenza. Accanto alle tue configurazioni custom trovi quella raccomandata da GitHub, utile come punto di partenza.
Le due leve che contano davvero sono quelle di propagazione, e vanno tenute distinte perché l’esame ci gioca sopra. Apply to existing repositories agisce retroattivamente sul parco esistente, filtrando i repository a cui vuoi estendere la linea. Use as default for newly created repositories agisce invece sul futuro, e ti fa scegliere l’ambito fra Public, Private and internal oppure All repositories: da quel momento ogni repository nuovo nasce già conforme. Attenzione alla trappola: un repository trasferito dentro l’organizzazione non è un repository “appena creato”, quindi il default non lo cattura e va applicato a mano. Infine Enforce configuration impedisce agli amministratori di repository di modificare le funzionalità governate dalla configurazione; ciò che la configurazione non tocca resta invece nelle loro mani.
Secret Protection e Code Security sono due prodotti distinti
Qui la conoscenza vecchia tradisce quasi tutti. GitHub Advanced Security non è più il nome di un unico interruttore: oggi la documentazione descrive due prodotti separati, acquistabili singolarmente, e riserva il nome Advanced Security alla licenza che li comprende entrambi.
GitHub Secret Protection raccoglie ciò che serve a impedire che una credenziale finisca nel codice: secret scanning, push protection, pattern personalizzati, segreti rilevati dall’AI, delegated bypass e la gestione delle chiusure. GitHub Code Security raccoglie ciò che serve a trovare e correggere vulnerabilità: code scanning con CodeQL, Copilot Autofix, dependency review, le regole di auto-triage per gli alert di Dependabot. Alcune funzionalità, come la panoramica di sicurezza e le campagne, compaiono in entrambi.
La confusione tipica da evitare in sede d’esame è duplice: parlare ancora di “abilitare GHAS” come se fosse un’unica voce, e collocare male una funzionalità. Ricorda l’ancoraggio semplice: se protegge segreti, sta in Secret Protection; se analizza codice e dipendenze, sta in Code Security.
Vale la pena conoscere il comportamento della push protection perché è la funzionalità con l’impatto più visibile sugli sviluppatori: blocca i push da riga di comando, i commit fatti dall’interfaccia web, i caricamenti di file e le chiamate all’API REST. Chi ha accesso in scrittura può forzare il blocco dichiarando un motivo — It’s used in tests, It’s a false positive, I’ll fix it later — dove i primi due generano un alert già chiuso e il terzo lascia un alert aperto. Con il delegated bypass togli quel potere alla generalità dei contributor: solo chi sta nella bypass list procede da solo, gli altri aprono una richiesta che un revisore approva o rifiuta, e le richieste non lavorate scadono.
La panoramica di sicurezza dice dove manca la copertura
Applicare una configurazione non basta: devi poter dimostrare la copertura. La security overview vive nella tab Security and quality ed esiste sia a livello di organizzazione sia aggregata a livello di enterprise. Offre una dashboard di Overview con i trend di rilevazione, remediation e prevenzione, una vista Risk che mostra dove si concentrano le vulnerabilità, e soprattutto una vista Coverage che misura quanti e quali repository hanno effettivamente attive le funzionalità. È la vista che chiude il ciclo: individui i buchi in Coverage e li tappi estendendo una security configuration ai repository scoperti. Ci sono poi le Campaigns per organizzare la remediation e l’esportazione dei dati in CSV.
Un vincolo da memorizzare: le viste mostrano informazioni sul branch di default dei soli repository che hai il permesso di vedere. Due amministratori con visibilità diverse leggono numeri diversi sullo stesso schermo, e questo spiega da solo la maggior parte delle discrepanze segnalate dai team.
Le impostazioni di protezione dei dati che governi come amministratore
Sopra le configurazioni stanno le policy enterprise. Quelle di code security and analysis stabiliscono se gli amministratori di repository possono abilitare o gestire le funzionalità di sicurezza — ed è precisamente qui che si annida l’errore ricorrente: la policy vincola loro, mentre gli owner dell’organizzazione e i security manager restano liberi di abilitare comunque. In più, negare una funzionalità a livello enterprise impedisce nuove abilitazioni ma non spegne quelle già attive.
Il perimetro dei dati si governa con leve diverse e complementari: disabilitare il fork dei repository, impedire il cambio di visibilità, obbligare la creazione di repository solo private o internal, disabilitare le deploy key, bloccare cancellazione e trasferimento, imporre una policy sui personal access token e richiedere l’autenticazione a due fattori. A livello di rete c’è la IP allow list dell’enterprise: le organizzazioni possono aggiungere voci proprie ma non modificare quelle ereditate, ed esiste l’opzione per importare gli indirizzi delle GitHub App installate. Non limita però l’accesso anonimo alle risorse pubbliche.
Per il vincolo di localizzazione esiste GitHub Enterprise Cloud with data residency, ospitato su un sottodominio dedicato di GHE.com: richiede Enterprise Managed Users, con autenticazione SAML o OIDC e provisioning SCIM. Non dare per scontato che tutto resti in regione: contenuti dei repository e log delle Actions sì, ma telemetria, dati di fatturazione e ticket di supporto stanno altrove. Su GitHub Enterprise Server alcune di queste viste e opzioni dipendono dalla release installata: verificale sulla documentazione fissata alla versione della tua istanza invece di trasferire le abitudini prese sul cloud.