Due prodotti distinti, non più una sigla sola
La prima cosa da aggiornare è il vocabolario. GitHub Advanced Security non è più un blocco monolitico: la documentazione attuale descrive due prodotti separati, GitHub Secret Protection e GitHub Code Security, acquistabili in modo indipendente su piano Team o Enterprise, con la possibilità di una licenza GitHub Advanced Security che li comprende entrambi. Da amministratore questa non è una sottigliezza di marketing: determina che cosa vedi accendersi nelle impostazioni quando abiliti una licenza e su quali repository.
Sotto Secret Protection ricadono secret scanning, push protection, gli AI-detected secrets per le credenziali non strutturate, i custom patterns definiti con espressioni regolari, il delegated bypass for push protection, la delegated alert dismissal, le security campaigns e la security overview. Sotto Code Security ricadono il code scanning con CodeQL o con analizzatori di terze parti, la CodeQL CLI, Copilot Autofix, la dependency review, le custom auto-triage rules per Dependabot, oltre a security campaigns e security overview che compaiono in entrambi.
Per i repository pubblici secret scanning e code scanning sono disponibili senza licenza; per i repository private e internal serve il prodotto corrispondente. L’esame gioca proprio su questa separazione: una domanda che chiede quale prodotto abilitare per introdurre la dependency review o l’analisi CodeQL su un’organizzazione privata ha come risposta Code Security, non Secret Protection, anche se l’istinto porta a rispondere “Advanced Security” come si faceva prima.
Push protection: che cosa succede quando il push viene bloccato
Il secret scanning individua credenziali già presenti nel codice, nella cronologia Git, nelle descrizioni e nei commenti di issue, pull request, discussion, wiki e gist, e genera un alert. La push protection lavora prima: intercetta il push e lo blocca restituendo un messaggio che spiega il motivo del blocco, così la credenziale non entra mai nel repository.
Vanno tenute distinte due cose che si chiamano quasi allo stesso modo. La push protection for users è attiva per impostazione predefinita sugli account su GitHub.com e blocca i push di segreti verso i repository pubblici, senza però generare alert se la protezione non è attiva anche a livello di repository. La push protection for repositories è disattivata per impostazione predefinita, richiede Secret Protection e si abilita dal repository in Settings, sezione Advanced Security, dove si accende prima Secret Protection e poi la voce Push protection; la stessa impostazione è governabile a livello di organizzazione ed enterprise.
Il punto più chiesto riguarda i motivi di bypass, perché ciascuno si riflette in modo diverso sullo stato dell’alert. Chi ha il permesso di forzare il push sceglie fra tre motivazioni: It’s used in tests chiude l’alert risolvendolo come used in tests, It’s a false positive lo chiude come false positive, mentre I’ll fix it later lascia l’alert aperto perché il segreto è reale e va rimediato. Confondere le tre opzioni è l’errore classico: solo la terza mantiene traccia aperta del debito di sicurezza.
Il delegated bypass aggiunge un ciclo di revisione. Si definisce una bypass list con individui, ruoli e team: chi ha i bypass privileges, come gli organization owner, i security manager e chi possiede il permesso fine-grained per gestire le richieste, può forzare subito il push e approvare le richieste altrui; le exemption servono per le automazioni fidate. Tutti gli altri contributor non forzano nulla, aprono una richiesta che deve essere approvata e che scade se nessuno la esamina. Utile ricordare anche le validity checks, che interrogano il servizio emittente per capire se la credenziale trovata è ancora attiva: cambia la priorità della remediation, non lo stato dell’alert.
Code scanning con CodeQL e abilitazione a scala
CodeQL si configura in due modi. Il default setup sceglie in automatico linguaggi, query suite ed eventi che scatenano l’analisi, con la possibilità di rifinire la selezione: è la strada da preferire per l’adozione di massa. L’advanced setup aggiunge al repository un file di workflow basato su github/codeql-action e serve quando occorre controllare passaggi di build, matrici o percorsi esclusi. In alternativa la CodeQL CLI gira su sistemi di CI esterni e carica i risultati su GitHub, così come qualsiasi analizzatore che produca dati in formato SARIF. Attenzione ai linguaggi: CodeQL copre un elenco preciso e non analizza, per esempio, PHP o Scala, dove serve uno strumento di terze parti.
A scala non si accende repository per repository. Lo strumento è la security configuration, un insieme di impostazioni che raccoglie Dependabot, dependency graph, secret scanning con push protection e code scanning default setup. Ogni voce vale Enabled, Disabled oppure Keep the existing settings, che lascia intatta la scelta locale. La configurazione si può designare come predefinita per i repository di nuova creazione, distinguendo fra pubblici, private and internal o tutti, mentre sui repository esistenti va applicata esplicitamente. L’opzione Enforce configuration impedisce ai proprietari dei repository di modificare ciò che la configurazione accende o spegne, mentre le voci lasciate non impostate restano libere. Su GitHub Enterprise Server la disponibilità delle singole funzionalità dipende dalla versione dell’istanza e richiede che la licenza sia attiva sull’appliance: verifica sempre la documentazione fissata alla versione in esecuzione prima di promettere una feature.
Alert di vulnerabilità e chi li vede
Gli alert di Dependabot nascono dall’incrocio fra il dependency graph del repository e il GitHub Advisory Database, a cui si aggiungono gli advisory pubblicati internamente dall’enterprise. Li abilitano gli amministratori del repository e gli owner dell’organizzazione, e alla prima accensione GitHub costruisce il grafo e crea subito gli alert per le dipendenze vulnerabili. Le notifiche raggiungono chi ha permessi di write, maintain o admin e osserva il repository, mentre le auto-triage rules permettono di chiudere in automatico le segnalazioni a basso rischio prima che generino rumore.
La visibilità aggregata passa dalla security overview, con le viste Overview, Risk, Coverage, Enablement e quelle dedicate a Dependabot e al secret scanning. Qui la distinzione da memorizzare è di ruolo: gli organization owner e i security manager vedono i dati di tutti i repository dell’organizzazione, i membri solo quelli su cui hanno permessi sugli alert. Il security manager è un ruolo a livello di organizzazione, assegnabile a un team o a una singola persona, che concede lettura su tutti i repository, scrittura su tutti gli alert di sicurezza e la possibilità di configurare le funzionalità di sicurezza. Gli enterprise owner vedono i dati aggregati delle organizzazioni in cui hanno un ruolo di owner o di security manager, ma non ereditano automaticamente il dettaglio a livello di repository: è la confusione tipica da evitare, perché essere owner dell’enterprise non equivale a vedere ogni singolo alert.