Tre motori di rilevamento, un solo oggetto chiamato alert

Sotto l ombrello GitHub Security suites convivono tre prodotti che rilevano cose diverse e in momenti diversi del ciclo di vita. GitHub Secret Protection — quello che storicamente si chiamava secret scanning — analizza l intera cronologia Git su tutti i branch, e inoltre issue, pull request, discussioni, wiki e gist segreti, cercando partner patterns, pattern generici, custom patterns definiti dall organizzazione e segreti individuati con l AI. GitHub Code Security — l erede di code scanning con CodeQL — analizza il codice con CodeQL o con strumenti di terze parti che caricano risultati in formato SARIF, su push, su pull request o secondo una pianificazione. Supply Chain Security confronta il dependency graph con il GitHub Advisory Database e apre un alert Dependabot quando una nuova vulnerabilità entra nel database, quando l enterprise pubblica un innersource advisory oppure quando cambia il grafo delle dipendenze.

Qui si annida la prima distinzione che l esame ama: nel database convivono advisory reviewed, unreviewed e malware. Solo gli advisory revisionati da GitHub e gli innersource advisory generano alert; gli unreviewed arrivano automaticamente dal feed del National Vulnerability Database e non sono verificati, quindi non fanno scattare nulla. Gli advisory malware invece generano alert quando la funzionalità è attiva, e non hanno una versione sicura verso cui aggiornare: l unica risposta è smettere di usare il pacchetto.

Non tutto costa uguale. Dependency graph, Dependabot alerts, security updates, version updates, malware alerts, gli alert dei partner e la push protection per i singoli utenti sono disponibili su qualsiasi repository. Secret scanning alerts for users, push protection a livello di repository, delegated bypass, custom patterns, code scanning, dependency review e security campaigns sono gratuiti sui repository pubblici, ma su repository privati e internal richiedono una licenza GitHub Secret Protection o GitHub Code Security.

Chi vede l alert, chi lo governa, chi lo corregge

Gli alert vivono nella scheda Security del repository e si aggregano nella Security Overview dell organizzazione. Il modello di responsabilità è a tre livelli. Lo sviluppatore incontra l alert dove sta lavorando — la push protection lo blocca al momento del push, dependency review e code scanning gli parlano dentro la pull request — e tipicamente ha permesso di scrittura, quindi può correggere. Il team di sicurezza, cioè organization owner, security manager e chi ha un custom organization role adeguato, decide priorità e politiche e vede l insieme dei repository. L amministratore decide quali interruttori sono accesi e dove.

Seconda distinzione da tenere ferma: una security configuration è una raccolta di impostazioni di abilitazione che si applica ai repository, mentre le global settings dell organizzazione vivono in Settings > Security > Advanced Security > Global settings e valgono per tutta l organizzazione. Custom pattern per secret scanning, auto-triage rules di Dependabot, Copilot Autofix e AI-powered security detections stanno fra le global settings, non dentro una configuration. Chi cerca i custom pattern dentro una security configuration perde tempo, e in un quesito d esame sceglie la risposta sbagliata.

Delegated bypass e delegated alert dismissal: due liste diverse

Questo è il punto in cui quasi tutti scivolano. Delegated bypass appartiene a Secret Protection e risponde a una sola domanda: chi può pushare un segreto che push protection ha bloccato. Si configura sul repository, sull organizzazione o sull enterprise e si basa su una bypass list che può contenere ruoli, team e singoli membri. Chi non è nella lista può inviare una bypass request, che viene esaminata; chi è esente passa senza attrito, opzione che la documentazione consiglia di concedere con prudenza perché apre la porta a fughe di credenziali. Per esaminare quelle richieste serve un custom organization role con il permesso Review and manage secret scanning bypass requests.

Delegated alert dismissal appartiene invece alla gestione degli alert e risponde a un altra domanda: chi può chiudere un alert che esiste già. Copre alert di code scanning, di secret scanning e di Dependabot. Quando è attiva, chi ha permesso di scrittura non chiude più direttamente: deve richiedere la chiusura. Organization owner, security manager e i custom role abilitati approvano o rifiutano — e possono chiudere direttamente — ricevendo notifica via email, con l esito comunicato a chi ha fatto la richiesta. Al revisore servono sia il permesso a livello di organizzazione sia i permessi Security sul repository per vedere, chiudere e riaprire.

Fissa la conseguenza pratica, perché è esattamente quello che l esame verifica con uno scenario: le due liste sono separate. Stare sulla bypass list non dà alcun diritto di chiudere alert, ed essere revisore delle dismissal request non autorizza a superare un blocco di push protection.

Chiudere un alert è una decisione, non un gesto

Chiudere un alert di code scanning ha effetti larghi: la chiusura vale su tutti i branch, l alert esce dal conteggio del progetto e alla prossima esecuzione quello stesso codice non genererà più un alert. Una ragione scelta a caso, quindi, non nasconde un avviso: spegne un controllo. Conviene esplorare l alert prima e lasciare un commento di dismissal, che finisce nella timeline ed è ciò che si guarda in fase di audit.

Sui segreti vale la regola opposta all istinto: chiudere l alert non revoca nulla. Prima si elimina la credenziale compromessa e se ne crea una nuova, poi si aggiornano i servizi che la usavano, poi si chiude. Su Dependabot le auto-triage rules possono chiudere alert in automatico con risoluzione auto-dismiss; quegli alert restano disponibili per reporting e revisione e possono riaprirsi se cambiano le condizioni, per esempio se una dipendenza passa da development a production.

Ultima confusione da evitare: nel filtrare gli alert Dependabot, severity riflette il CVSS, cioè la gravità intrinseca, mentre EPSS stima la probabilità che la vulnerabilità venga sfruttata nei giorni successivi. Sono assi diversi, e una vulnerabilità critica con EPSS basso non è la stessa cosa di una media con EPSS alto.