Un nome storico, tre prodotti distinti

La certificazione si chiama ancora GitHub Advanced Security, e conviene leggerlo come il titolo dell’esame, non come il nome di qualcosa che si compra oggi. La documentazione raccoglie le funzionalità sotto l’ombrello GitHub Security suites e le distribuisce su tre blocchi: GitHub Code Security, GitHub Secret Protection e la Supply Chain Security. I primi due sono prodotti con licenza propria; il terzo è la famiglia di funzionalità su dipendenze e provenienza del software, in gran parte inclusa in tutti i piani.

Se hai studiato su materiale più vecchio, la traduzione mentale è questa: dove leggevi “secret scanning” pensa a Secret Protection, dove leggevi “code scanning con CodeQL” pensa a Code Security, dove leggevi Dependabot pensa a Supply Chain Security. Il nome unico storico sopravvive in due soli punti: il titolo della certificazione e la licenza legacy citata nelle pagine di fatturazione e in certi messaggi di errore.

Che cosa contiene ciascuna suite e dove si comanda

Code Security copre il codice che scrivi tu: il code scanning, con il motore CodeQL oppure con strumenti di terze parti che caricano i risultati in formato SARIF, più Copilot Autofix per le correzioni suggerite, le security campaigns per la remediation coordinata e le AI-powered security detections. Gli alert stanno nel tab Security del repository, l’accensione in Settings > Advanced Security, dove scegli fra default setup e advanced setup, cioè il workflow di Actions che controlli tu.

Secret Protection copre le credenziali: gli alert di secret scanning, la push protection che blocca il push prima che il segreto entri nella storia del repository, i custom pattern scritti come espressioni regolari, le validity checks che verificano se il token trovato è ancora attivo e il delegated bypass.

Supply Chain Security copre ciò che arriva da fuori: il dependency graph, i Dependabot alerts, i Dependabot security updates, i Dependabot version updates, la dependency review sulla pull request, gli alert su malware, le immutable releases e le artifact attestations. Buona parte si governa da file, non da interruttori:

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"

Sopra i repository ci sono due livelli che l’esame ama far confondere. Le security configuration sono raccolte di impostazioni di abilitazione che applichi ai repository di un’organizzazione o di un’enterprise. Le global settings dell’organizzazione, sotto Settings > Advanced Security > Global settings, definiscono invece come le funzionalità analizzano l’organizzazione e vengono ereditate dai repository: lì vivono i custom pattern di secret scanning e le auto-triage rule di Dependabot, non l’accensione repository per repository.

Seconda coppia da non scambiare: il delegated bypass riguarda chi può portare a termine un push bloccato dalla push protection, quindi un segreto che sta per entrare; la delegated alert dismissal riguarda chi può chiudere un alert già aperto, e copre code scanning, secret scanning e Dependabot. Chi ha accesso in scrittura deve richiedere la chiusura a un revisore, tipicamente owner dell’organizzazione o security manager.

Il confine commerciale

Qui l’esame insiste, perché il risultato è controintuitivo.

Disponibile su tutti i piani, repository privati compresi: dependency graph, Dependabot alerts, Dependabot security updates, Dependabot version updates, alert su malware, GitHub Advisory Database, security policy, repository ruleset e artifact attestations.

Gratuito sui repository pubblici ma soggetto a licenza su privati e internal: code scanning, dependency review, gli alert di secret scanning per gli utenti e la push protection. Sul code scanning la documentazione è netta: “If you want to use code scanning on private repositories, you need a GitHub Code Security license.”

Sempre a licenza: dependency review sui repository privati e le custom auto-triage rule di Dependabot appartengono a Code Security — “Custom auto-triage rules for Dependabot alerts are available on public repositories and on any organization-owned repositories in GitHub Team or GitHub Enterprise with GitHub Code Security enabled.” — mentre custom pattern, delegated bypass, validity checks e secret rilevati dall’AI appartengono a Secret Protection.

Il trabocchetto classico è proprio questo: secret scanning e push protection sono gratuiti sui repository pubblici, i custom pattern no, mai. E nel GitHub Advisory Database convivono advisory reviewed, unreviewed e malware: reviewed e malware generano alert, le unreviewed no, perché “Dependabot doesn’t create Dependabot alerts for unreviewed advisories as this type of advisory isn’t checked for validity or completion.”

La Security Overview e le domande a cui risponde

La Security Overview è il tab Security a livello di organizzazione e di enterprise, e ciò che riesce a mostrarti dipende dai prodotti attivi. La vista Overview organizza le metriche in Detection, Remediation e Prevention: Age of alerts e Reopened alerts dicono se il debito invecchia, Mean time to remediate e Net resolve rate se il team chiude più di quanto apre, Introduced versus prevented quanto la push protection sta effettivamente fermando. Coverage risponde a “quanti repository hanno la funzionalità accesa”, Risk a “dove sono i problemi peggiori”, Campaigns a “come coordino la bonifica su più repository”.

Nei filtri tieni separati i due assi: severity ordina per gravità della vulnerabilità, epss_percentage per probabilità che venga davvero sfruttata. Un alert critico con probabilità di sfruttamento bassa e uno medio con probabilità alta non si trattano allo stesso modo, e le domande d’esame sulla prioritizzazione partono quasi sempre da qui.