Prevenire o sbarrare: due filosofie, due configurazioni

Ogni organizzazione che adotta le GitHub Security suites sceglie, magari senza dirselo, fra due filosofie.

L’approccio prevention-first sposta il controllo il più a sinistra possibile: il problema non deve proprio entrare. Il caso da manuale è la push protection di GitHub Secret Protection, che blocca un segreto riconosciuto al momento del push, prima che finisca nella cronologia del repository. Il controllo agisce sui push da riga di comando, sui commit fatti dall’interfaccia web, sui caricamenti di file, sulle richieste via REST API e anche sulle interazioni con il GitHub MCP server. Sul fronte del codice la stessa logica prende la forma di Copilot Autofix, che accanto all’alert propone una singola correzione già scritta, che lo sviluppatore rivede e applica: non serve un abbonamento a GitHub Copilot, non consuma AI credits, ed è attivo per i repository che usano CodeQL, con possibilità di disattivarlo a livello di enterprise, organizzazione o repository.

Il costo organizzativo del prevention-first è il falso positivo che ferma una persona a metà lavoro. Senza una valvola, il team si blocca. La valvola è il delegated bypass for push protection: si definisce una bypass list e si distinguono due livelli, chi ha il privilegio di bypass, che chiede e attende un’approvazione, e chi è exempt, cioè salta del tutto il controllo, pensato per bot di migrazione e service account. Owner dell’organizzazione e security manager hanno il privilegio in automatico, e le richieste non evase scadono da sole dopo un periodo prefissato. Quando un push bloccato viene comunque forzato indicando un motivo, GitHub apre un alert e registra l’evento nell’audit log: il bypass non è un buco, è una traccia.

L’approccio gate-based accetta invece che il problema entri nel branch di lavoro e lo ferma prima del merge. La merge protection di code scanning si configura con i rulesets e non ha niente a che vedere con i required status checks: il merge viene bloccato quando un tool richiesto trova alert di una severity definita nel ruleset, quando l’analisi è ancora in corso, oppure quando quel tool non è nemmeno configurato per il repository. Attenzione alla trappola classica: aggiungere la regola al ruleset non abilita da sola il code scanning. La protezione non si applica ai gruppi della merge queue né alle pull request di Dependabot.

Il gate corrispondente sulle dipendenze è la dependency review, che sulla pull request mostra le dipendenze aggiunte, rimosse o aggiornate con i relativi dati di vulnerabilità, e con la dependency review action può far fallire il check secondo una soglia di gravità.

- uses: actions/dependency-review-action@v4
  with:
    fail-on-severity: moderate

Il costo del gate-based è speculare: nessuno viene interrotto mentre scrive, ma la coda si accumula sulla pull request e serve una via d’uscita per gli alert che non si vogliono correggere. Qui entra la delegated alert dismissal, che è cosa diversa dal delegated bypass: chi ha accesso in scrittura non chiude più un alert da solo, deve richiederlo, e owner o security manager approvano o rifiutano. Vale per code scanning, secret scanning e Dependabot alerts. La confusione tipica da evitare è proprio questa: il delegated bypass decide chi può pushare un segreto bloccato, la delegated alert dismissal decide chi può chiudere un alert già aperto.

Secret Protection e Code Security lungo il ciclo di vita

Le due suite non si sovrappongono, si passano il testimone. GitHub Secret Protection sorveglia le credenziali, cioè materiale che non dovrebbe mai stare nel repository e che, una volta pubblicato, va ruotato: il rimedio sta fuori dal codice. GitHub Code Security analizza invece il sorgente con CodeQL o con strumenti di terze parti che caricano risultati SARIF, sui push, sulle pull request o su pianificazione, per trovare vulnerabilità prima che arrivino in produzione. Un segreto è compromesso nell’istante stesso in cui viene pubblicato, mentre una debolezza nel codice diventa sfruttabile più avanti: è la ragione per cui la prima merita un blocco duro e la seconda tollera un cancello al merge. Attorno a entrambe lavora Supply Chain Security, con dependency graph, Dependabot alerts e la dependency review già citata.

Sul versante copertura, ricorda la linea di demarcazione: sui repository pubblici funzionalità come secret scanning alerts for users, AI-detected secrets, push protection, custom patterns, code scanning, CodeQL CLI, Copilot Autofix e dependency review sono disponibili senza licenza; su repository privati e internal servono le licenze GitHub Secret Protection e GitHub Code Security. Vanno tenuti distinti anche i due piani di configurazione: una security configuration è una collezione di interruttori di abilitazione che applichi ai repository, mentre le global settings dell’organizzazione descrivono come le funzionalità analizzano, ed è lì che vivono i custom pattern e le auto-triage rule.

Le security campaign: aggredire l’arretrato

Prevenzione e cancelli governano il flusso nuovo, ma non toccano ciò che è già dentro. Le security campaign servono esattamente a questo: raggruppare alert esistenti e condividerli con gli sviluppatori per rimediare in modo collaborativo.

Si creano dalla scheda Security della organizzazione, sezione Campaigns, con Create campaign, partendo da un template oppure dai filtri di code scanning o di secret scanning; ogni campagna ha un tetto massimo di alert. I campi che la definiscono sono il nome, una Short description, la Campaign due date, i Campaign managers, che devono essere owner o security manager, e un Contact link facoltativo. Si può lasciarla come Draft campaign o pubblicarla, e per le campagne di codice si possono creare issue nei repository coinvolti. Il monitoraggio mostra il Campaign progress con gli alert in stato Open, In progress, Fixed e Dismissed, e per le campagne di codice quanti alert sono correggibili con Copilot Autofix. Le campagne su secret scanning sono in public preview e permettono l’assegnazione degli alert ma non l’Autofix.

L’elemento decisivo non è tecnico: una campagna funziona perché ha un referente con nome e cognome, una scadenza e un perimetro chiuso, invece della speranza che qualcuno guardi la lista.

Che cosa aspettarsi all’esame

Le domande su questo blocco raramente chiedono un clic. Chiedono di scegliere la strategia adatta a uno scenario: un’organizzazione che teme la fuga di credenziali va verso push protection con delegated bypass, una che deve dimostrare di non aver rilasciato codice vulnerabile va verso la merge protection nei ruleset, e chi si ritrova migliaia di alert storici ha bisogno di una security campaign, non di un ulteriore blocco. Tieni fermi i nomi nuovi dei prodotti, ricordando che la certificazione continua a chiamarsi GitHub Advanced Security anche se secret scanning e code scanning oggi vivono sotto GitHub Secret Protection e GitHub Code Security, e non confondere le due deleghe: una riguarda il push, l’altra la chiusura degli alert.