Dove si accende, a partire dal repository
La certificazione si chiama ancora GitHub Advanced Security, ma il prodotto che stai configurando no: quello che storicamente si chiamava secret scanning oggi è GitHub Secret Protection, una delle suite di sicurezza insieme a GitHub Code Security e a Supply Chain Security. All’esame le domande usano i nomi nuovi, mentre molto materiale di studio in circolazione usa ancora quelli vecchi: abituati a leggere “secret scanning” come il motore di rilevamento dentro il prodotto Secret Protection.
Sul singolo repository il percorso è breve. Da Settings, nella sezione Security della barra laterale, si apre la pagina Advanced Security: accanto alla voce Secret Protection compare Enable, e una schermata riassume l’impatto dell’attivazione prima di confermare. Da quel momento quella pagina diventa il pannello unico del repository: gli altri interruttori vivono dentro la sezione Secret Protection e dipendono da essa. È il caso di Push protection, che si abilita con un secondo Enable e che non ha senso attivare se il rilevamento è spento, ed è il caso di Prevent direct alert dismissals, l’impostazione che introduce la revisione delle richieste di chiusura degli alert.
Questa gerarchia è una delle cose che l’esame verifica più volentieri, perché è banale da ricordare e facile da sbagliare sotto pressione: Secret Protection è l’interruttore generale, push protection e le sue varianti sono interruttori subordinati sulla stessa pagina.
Security configuration contro global settings dell’organizzazione
Abilitare repository per repository non scala, e infatti a livello di organizzazione lo strumento è un altro. Una security configuration è una raccolta di impostazioni di abilitazione che si applica ai repository di un’organizzazione o di un’enterprise: si sceglie quella predisposta da GitHub oppure se ne crea una personalizzata, si decide quali funzionalità accende e la si applica a un insieme di repository. La configurazione crea una relazione gestita con i repository, e quando è applicata in modalità di enforcement l’amministratore del singolo repository non può più modificare localmente quelle impostazioni: è esattamente ciò che accade, per esempio, con Prevent direct alert dismissals imposto dall’alto.
Accanto alle security configuration ci sono i global settings, che si raggiungono da Settings, sezione Security, Advanced Security, Global settings. Qui non si accende nulla sui repository: si modella come le funzionalità analizzano l’organizzazione. È qui che vivono i custom patterns, cioè le espressioni regolari per i segreti proprietari, ed è qui che si trovano le pattern configuration che stabiliscono quali pattern partecipano alla push protection. Sullo stesso pannello convivono impostazioni delle altre suite, come le auto-triage rule di Dependabot e le opzioni di code scanning.
La confusione tipica da evitare è proprio questa: cercare i custom pattern dentro una security configuration. La configurazione risponde alla domanda “su quali repository è acceso”, i global settings rispondono alla domanda “che cosa cerca e come si comporta”. Sono due piani diversi e l’esame li mette spesso nella stessa risposta multipla.
Per la fase di adozione, l’organizzazione dispone anche di una valutazione preliminare: dalla scheda Security dell’organizzazione, alla voce Assessments, il menu Get started permette di stimare l’esposizione ai segreti e offre due strade, abilitare Secret Protection solo sui repository pubblici oppure vedere una stima prima di estenderlo a tutti.
Pubblico contro privato e internal
La differenza di comportamento fra visibilità non riguarda il motore, riguarda la licenza. Sui repository pubblici il rilevamento dei segreti con alert per gli utenti e la push protection sono disponibili gratuitamente: non serve alcuna licenza per averli. Sui repository privati e internal di proprietà di un’organizzazione le stesse funzionalità richiedono invece GitHub Secret Protection su GitHub Team o GitHub Enterprise Cloud.
Sotto la licenza ricadono, oltre agli alert per gli utenti e alla push protection, i secret rilevati tramite AI, il delegated bypass for push protection, i custom pattern e la security overview. Restano invece gratuiti su qualunque tipo di repository gli alert verso i partner, cioè la notifica automatica al fornitore che ha emesso la credenziale, e la push protection impostata dal singolo utente sul proprio account.
Ambito della scansione e le due deleghe da non confondere
Quando Secret Protection è attivo, l’analisi non si limita al commit più recente: copre l’intera cronologia Git su tutte le branch del repository. Oltre al codice vengono esaminati anche i contenuti non di codice, cioè descrizioni e commenti delle issue, titoli, descrizioni e commenti delle pull request, le Discussions, le wiki e i gist segreti. Alcune coppie di pattern, dove servono sia un identificativo sia il segreto, generano un alert solo se entrambi gli elementi finiscono nello stesso file. Sui push molto voluminosi la protezione può essere saltata per timeout, e un push che porta con sé un numero molto alto di segreti già presenti non viene bloccato: sono limiti operativi da conoscere, non da imparare a memoria.
Ultima distinzione, quella che separa le risposte giuste dalle plausibili: il delegated bypass decide chi può completare un push bloccato da push protection, mentre il delegated alert dismissal, l’impostazione Prevent direct alert dismissals, decide chi può chiudere un alert già aperto. Vivono entrambi sotto Secret Protection, ma agiscono in momenti opposti del ciclo di vita di un segreto.