Ciclo di vita degli alert, deleghe e pattern personalizzati

Dalla scoperta alla revoca: il ciclo di vita di un alert

GitHub Secret Protection — il prodotto che copre quello che la documentazione storica chiamava secret scanning, e che l’esame GitHub Advanced Security continua a interrogare come dominio a sé — apre un alert ogni volta che un pattern di partner, un pattern personalizzato o un rilevamento generico trova una credenziale nel contenuto del repository. Gli alert nascono da due tipi di analisi: la scansione incrementale, che si attiva a ogni push, e la scansione storica, che ripercorre tutto il contenuto già presente nel momento in cui la funzionalità viene abilitata.

Sul piano dello stato un alert è aperto oppure chiuso, ma la vista degli alert espone qualificatori che in sede d’esame vengono scambiati per stati: is:publicly-leaked e is:multi-repository non sono esiti di chiusura, descrivono la portata della fuga. Il filtro validity, con i valori active, inactive e unknown, dipende invece dai validity checks, cioè dalla verifica presso il provider se la credenziale risponda ancora.

La chiusura avviene dal menu Close as, con motivazioni tipizzate: revoked, false-positive, used-in-tests, wont-fix, più le risoluzioni che la piattaforma applica da sola, pattern-deleted, pattern-edited e hidden-by-config. La remediation corretta comincia sempre dalla revoca o rotazione della credenziale presso il servizio che l’ha emessa, non dalla rimozione della stringa dal file. La documentazione consiglia anzi di ruotare il segreto prima ancora di divulgarlo o segnalarlo, e per i token GitHub prevede la possibilità di segnalarli in modo che sia GitHub a revocarli. Solo dopo si ripulisce il codice e si controllano i log del servizio, per capire se la credenziale sia stata usata da terzi.

Due punti che l’esame ama trasformare in distrattori. Primo: la rimozione del segreto dal repository non chiude l’alert, la chiusura resta un’azione manuale. Secondo: cancellare la riga dal file non cancella il commit, quindi un alert chiuso come “risolto” senza revoca lascia in giro una credenziale ancora valida e la toglie dalla coda di chi la sorveglia. Chiudere per comodità è la peggiore delle scorciatoie: wont-fix e used-in-tests andrebbero riservati ai casi in cui la credenziale non esiste davvero o non ha alcun valore.

Bypass e dismissal: due deleghe che non vanno confuse

Il delegated bypass riguarda la push protection, cioè il momento in cui qualcuno prova a spingere un segreto e viene bloccato. Chi non ha il privilegio apre una richiesta di bypass, che finisce ai revisori attraverso la pagina Bypass requests del repository o la security overview dell’organizzazione, con notifica via email; la richiesta viene approvata o negata e scade se nessuno interviene. Possono bypassare gli organization owner, i security manager e gli utenti che appartengono a team, ruoli predefiniti o ruoli personalizzati inseriti nella bypass list; esiste inoltre un permesso granulare dedicato alla revisione e gestione delle richieste di bypass, utile per affidare il compito a chi non è owner. Gli account di automazione si gestiscono con le exemptions, per non bloccare le pipeline.

Il delegated alert dismissal risponde a un’altra domanda: chi può chiudere un alert. Con l’impostazione Prevent direct alert dismissals gli utenti con accesso in scrittura devono richiedere la chiusura, e sono gli organization owner e i security manager ad approvare o negare, oltre a poter chiudere direttamente. Vale anche per gli alert di Code Security e di Supply Chain Security, non solo per i segreti. La regola gerarchica è la stessa nei due casi ed è un classico da esame: se il bypass delegato o il divieto di chiusura diretta sono configurati a livello di organizzazione o di enterprise, le impostazioni corrispondenti a livello di repository vengono disattivate.

Destinatari, esclusioni e rumore

Chi riceve gli alert dipende dal tipo di scansione. Con la scansione incrementale vengono avvisati gli amministratori del repository, i security manager, gli utenti con ruoli personalizzati con accesso in lettura o scrittura, gli owner di organizzazione ed enterprise che siano anche amministratori del repository, e in più l’autore del commit che ha introdotto il segreto, a prescindere dalle sue preferenze. Con la scansione storica gli owner ricevono la notifica di completamento, mentre l’autore del commit non viene avvisato. Per ricevere le email bisogna comunque osservare il repository con All Activity oppure con Custom limitato a Security alerts, e avere l’email abilitata nelle notifiche personali. Assegnare un alert a una persona la notifica in ogni caso.

Le esclusioni si dichiarano in un file di configurazione nel repository, e gli alert nei percorsi elencati vengono chiusi come ignorati dalla configurazione:

# .github/secret_scanning.yml
paths-ignore:
  - "docs/**"
  - "foo/bar/*.js"

È uno strumento per abbassare il rumore su fixture e documentazione, non per nascondere directory in cui girano credenziali reali.

Pattern personalizzati: definirli, provarli, pagarli

I custom patterns insegnano alla piattaforma a riconoscere i token proprietari. Si definiscono a tre livelli: repository, organizzazione ed enterprise. A livello di organizzazione vivono nelle Global settings della sezione Advanced Security, insieme ad altre impostazioni trasversali come le auto-triage rule: distinguile dalle security configuration, che sono invece i pacchetti di interruttori applicati ai repository. Il modulo chiede un nome, il campo Secret format e, sotto More options, il contesto prima e dopo il segreto più eventuali requisiti aggiuntivi di corrispondenza; la sintassi è quella della libreria Hyperscan, un sottoinsieme di PCRE.

Il flusso corretto è Save and dry run prima e Publish pattern poi: la prova a vuoto mostra le corrispondenze senza creare alert, su tutti i repository o su un sottoinsieme selezionato, e serve proprio a misurare i falsi positivi prima di sommergere il team. La push protection per quel pattern si abilita solo dopo la pubblicazione. Ultima trappola d’esame: i pattern personalizzati richiedono una licenza Secret Protection anche dove la scansione di base è gratuita sui repository pubblici, esattamente come il bypass delegato e i rilevamenti basati su AI.