Che cos’è una security configuration
Una security configuration è un insieme di impostazioni di abilitazione delle funzionalità di sicurezza che si applica come oggetto unico ai repository di un’organizzazione o di un’enterprise. È il passaggio da una gestione artigianale, in cui si entra nelle impostazioni di ogni repository e si accendono gli interruttori uno per uno, a una gestione dichiarativa: si definisce una volta la linea di sicurezza desiderata e la si attacca a molti repository.
Dentro una configuration si trovano gli interruttori delle tre suite. Per GitHub Secret Protection (storicamente secret scanning) ci sono validity checks, extended metadata, generic patterns, scan for AI-detected secrets, push protection, bypass privileges e prevent direct alert dismissals. Per GitHub Code Security (storicamente code scanning con CodeQL) ci sono default setup, runner type e, di nuovo, prevent direct alert dismissals. Per la Supply Chain Security ci sono dependency graph, automatic dependency submission, Dependabot alerts, security updates e malware alerts. Si aggiunge private vulnerability reporting.
Il dettaglio che l’esame ama è che ogni interruttore ha tre stati, non due: si può abilitare la funzionalità, disabilitarla, oppure lasciare l’impostazione esistente del repository. Il terzo stato non è un “no”: è un’astensione deliberata, e ha conseguenze concrete sull’enforcement di cui parliamo fra poco.
Qui va tenuta ferma una distinzione che i candidati confondono spesso perché entrambe le voci vivono nella stessa schermata. Bypass privileges regola il delegated bypass per la push protection, cioè chi può spingere un commit che contiene un segreto bloccato, eventualmente passando da una richiesta di approvazione. Prevent direct alert dismissals regola il delegated alert dismissal, cioè chi può chiudere un alert già emesso senza chiedere il permesso: attivandolo, chi ha accesso in scrittura deve richiedere la chiusura, e sono gli organization owner e i security manager ad approvare o negare. Uno riguarda il codice che entra, l’altro riguarda l’alert che esce.
Default, applicazione ai repository esistenti ed ereditarietà
Una configuration si può marcare come predefinita tramite l’opzione Use as default for newly created repositories, scegliendo se vale per i repository Public, per quelli Private and internal, oppure per tutti. Attenzione al perimetro esatto: il default di un’organizzazione si applica automaticamente solo ai repository creati nell’organizzazione. Un repository trasferito dentro l’organizzazione non eredita nulla, e la configuration va applicata a mano. È una domanda d’esame classica, perché l’intuizione dice il contrario.
Per i repository che già esistono l’applicazione è un’azione esplicita: si filtra l’elenco nella scheda Repositories, si selezionano i repository e si usa Apply configuration. Due comportamenti vanno memorizzati perché sembrano simmetrici e non lo sono. Primo: per applicare una nuova configuration a un repository che ne ha già un’altra non serve staccare quella precedente, si applica la nuova e basta. Secondo: staccare una configuration non spegne niente. La documentazione è esplicita nel dire che il detach non modifica le impostazioni di abilitazione già presenti sul repository. Il detach rompe il legame di gestione, non ripristina uno stato pulito: il repository resta acceso e torna semplicemente a essere governato individualmente. Chi si aspetta un rollback delle funzionalità sbaglia.
Lo stato del legame è leggibile: attached quando la configuration governa il repository, attaching e updating come stati transitori, enforced quando l’enforcement impedisce agli amministratori del repository di cambiare l’abilitazione, removed quando un amministratore ha modificato un’impostazione in conflitto con una configuration non enforced, failed quando l’attach non è riuscito e detached quando non c’è alcuna configuration. Sull’enforcement vale il dettaglio dei tre stati visto prima: le funzionalità lasciate non impostate non vengono enforced. E chi prova ad aggirare l’enforcement dalla REST API ottiene una chiamata che sembra riuscire mentre in realtà nessuno stato di abilitazione cambia: un fallimento silenzioso, non un errore.
Configuration contro global settings dell’organizzazione
Questa è la separazione concettuale più importante del dominio. Le security configuration contengono interruttori: dicono se una funzionalità è accesa su un certo repository. Le global settings dell’organizzazione, che si raggiungono da Settings, sezione Security, voce Advanced Security e poi Global settings, contengono invece il modo in cui quelle funzionalità analizzano: sono impostazioni di livello organizzazione ereditate dai repository.
Vivono nelle global settings, e non dentro una configuration, i custom pattern per Secret Protection, la personalizzazione dei pattern inclusi nella push protection e il link di risorse mostrato quando un commit viene bloccato; le auto-triage rule di Dependabot, i grouped security updates, il tipo di runner e l’accesso ai registry privati; per il code scanning il suggerimento della query suite estesa e l’estensione dell’analisi CodeQL. Se una domanda chiede dove si definisce un’espressione regolare per un segreto proprietario, la risposta non è “nella security configuration”: è nelle global settings. La configuration deciderà poi su quali repository quel pattern viene effettivamente cercato, accendendo Secret Protection.
Licenze, Enterprise Cloud ed Enterprise Server
Sui repository pubblici buona parte delle funzionalità è gratuita e la configuration si applica senza consumare licenze. Su private e internal serve la licenza del prodotto. Il comportamento quando le licenze non bastano va saputo con precisione: le funzionalità gratuite incluse nella configuration vengono comunque abilitate su tutti i repository privati e internal, mentre le funzionalità a licenza non vengono abilitate su nessuno di essi; poiché solo una parte della configuration risulta applicata, l’attach su quei repository fallisce. Il risultato non è una copertura parziale silenziosa, ma uno stato di errore visibile nell’elenco.
Fra le due piattaforme la logica è la stessa, ma il perimetro no. Su GitHub Enterprise Server esiste un passaggio a monte che nel Cloud non c’è: le suite vanno abilitate dall’appliance, da Site admin, Management Console, sezione Security, dopo aver caricato una licenza che le includa, e la modifica comporta il riavvio dei servizi. Solo dopo le organizzazioni possono usare configuration e global settings. Inoltre, sulla versione della documentazione qui considerata (enterprise-server 3.21) l’elenco degli interruttori disponibili in una configuration è più corto di quello del Cloud: mancano per esempio la ricerca dei segreti rilevati dall’AI, gli extended metadata, l’automatic dependency submission, i malware alert e il private vulnerability reporting. Poiché questo elenco dipende dalla release dell’appliance, in sede d’esame conviene ragionare per principio: la funzionalità nuova compare prima su Enterprise Cloud e arriva su Enterprise Server con una versione successiva. Se una domanda contrappone le due piattaforme, la risposta prudente è quella che riconosce il ritardo di Server, non quella che assume parità.