Se nella tua organizzazione qualcuno ha acceso il secret scanning e vi siete ritrovati con trecento alert aperti e nessuno che li chiuda, GH-500 è l’esame che descrive il tuo lavoro. GitHub Advanced Security è la certificazione di GitHub per chi mette in sicurezza codice, segreti e dipendenze lungo tutto il ciclo di vita del software. Non chiede dove si trovi l’interruttore: chiede quale controllo risolve un problema preciso, chi ha il diritto di aggirarlo, e in che ordine si smaltisce un arretrato di vulnerabilità.
Cosa valida l’esame GH-500
Il profilo del candidato pubblicato nella study guide ufficiale è esplicito: esperienza nell’uso di GitHub Advanced Security per proteggere codice, segreti e dipendenze; capacità di configurare le funzionalità, fare triage e remediation degli alert e di applicare pratiche prevention-first con policy, workflow e automazione; familiarità con i fondamentali di GitHub, con la CI/CD e con i concetti di sviluppo sicuro.
La parola che conta è prevention-first. Un obiettivo d’esame chiede esplicitamente di contrapporre l’approccio preventivo a quello a cancello: bloccare un segreto prima che entri nel repository non è la stessa cosa che scoprirlo dopo e aprire un alert, e non è la stessa cosa che far fallire una pull request su una dipendenza vulnerabile. GH-500 misura se sai quando serve l’uno e quando l’altro, e che conseguenze ha la scelta su chi scrive codice tutti i giorni.
I numeri dell’esame
| Dato | Valore |
|---|---|
| Codice esame | GH-500 |
| Livello | Intermediate |
| Durata | 100 minuti |
| Punteggio minimo | 700 (scala fino a 1000) |
| Numero di domande | non pubblicato |
| Lingue | inglese, spagnolo, portoghese (Brasile), coreano, giapponese |
| Obiettivi aggiornati a | luglio 2026 |
| Erogazione | Pearson VUE, iscrizione da Microsoft Learn |
Tre avvertenze che valgono più della tabella.
L’esame non è disponibile in italiano. Le cinque lingue qui sopra sono quelle pubblicate sulla pagina ufficiale della credenziale: l’italiano non c’è, e non c’è per nessuna delle sei certificazioni GitHub. Se la tua lingua non è fra quelle offerte puoi richiedere 30 minuti aggiuntivi per completare l’esame: lo dice la study guide, ed è una richiesta che si fa prenotando.
Il prezzo non compare su nessuna pagina ufficiale leggibile. La pagina della credenziale si limita a dire che il costo dipende dal paese o dalla regione in cui l’esame viene erogato, e il portale GitHub Learn che ospita il listino è oggi un’applicazione JavaScript che a una richiesta semplice non restituisce alcuna cifra. Il numero su cui puoi contare è quello che ti mostra Pearson VUE al momento della prenotazione, nella tua valuta e con le imposte del tuo paese.
Sulla scadenza, due fonti ufficiali dicono cose diverse. La study guide di GH-500 contiene la tabella standard di Microsoft Learn, secondo cui le certificazioni Microsoft associate, expert e specialty scadono ogni anno e si rinnovano con un assessment online gratuito. La pagina della credenziale precisa però che l’esame è erogato da Microsoft, ma esame e certificazione sono mantenuti da GitHub, e le pagine di GitHub sul proprio programma non sono oggi leggibili a macchina. Non scegliamo per te fra le due: prima di pianificare un rinnovo, verifica lo stato della credenziale nel profilo Microsoft Learn con cui hai sostenuto l’esame.
A chi si rivolge
I ruoli dichiarati sulla pagina ufficiale sono cinque: amministratore, sviluppatore, DevOps engineer, solution architect e studente. Nella pratica GH-500 è l’esame di chi sta in mezzo fra sicurezza e sviluppo — security champion, application security engineer, platform engineer, chi amministra un’organizzazione GitHub grande — e deve far convivere il presidio di sicurezza con la velocità dei team.
Non ci sono prerequisiti formali, ma l’esame presuppone che tu abbia già visto un dependabot.yml vero, una pull request bloccata da una dependency review, un workflow di code scanning che fallisce alle tre di notte. Se quel vissuto ti manca, la scheda della certificazione ti dà il quadro d’insieme e il percorso di preparazione GH-500 ricostruisce i sei domini in unità di lettura brevi.
Tre suite nell’esame, due prodotti nel listino
È il punto in cui quasi tutti inciampano. La certificazione si chiama ancora GitHub Advanced Security: quel nome è sulla pagina della credenziale, oggi. I prodotti al suo interno però sono stati rinominati, e la study guide lo registra nei titoli stessi dei domini: Secret Protection (formerly secret scanning), supply chain security (formerly Dependabot/Dependency Review), Code Security (formerly Code Scanning with CodeQL), tutti sotto l’ombrello GitHub Security suites.
Attenzione a una sfumatura che le due fonti ufficiali non raccontano allo stesso modo: l’esame parla di tre suite, ma la documentazione di prodotto ne vende due. La pagina About GitHub Advanced Security descrive GHAS come l’insieme di GitHub Secret Protection e GitHub Code Security, acquistabili sui piani Team ed Enterprise; le funzionalità di supply chain (dependency graph, Dependabot, dependency review) compaiono nella documentazione come area, non come prodotto a pagamento a sé. E diverse funzionalità — code scanning, secret scanning, push protection — sono abilitate per impostazione predefinita sui repository pubblici. Quando una domanda chiede se una capacità è disponibile, la risposta dipende quasi sempre da repository pubblico o privato e da quale prodotto è stato acquistato.
I sei domini d’esame
Gli obiettivi sono aggiornati a luglio 2026 e il change log usa la formula più forte del catalogo: l’esame è cambiato in modo significativo, con obiettivi aggiunti, rimossi, spostati di gruppo e tutti riformulati. Materiale precedente a quella data va usato con prudenza.
1. Descrivere suite, funzionalità ed ecosistema (15–20%)
Struttura e navigazione delle Security suites, differenze fra Code Security, Secret Protection e supply chain security, disponibilità delle funzionalità fra repository pubblici e ambienti enterprise, e la Security Overview. Poi la parte strategica: SDLC sicuro end-to-end, prevenzione contro approccio a cancello, ruolo delle security campaigns, responsabilità rispettive di sviluppatori, security team e amministratori, e le implicazioni del dismettere un alert.
2. Configurare e usare Secret Protection (15–20%)
Abilitazione a livello di repository e di organizzazione, differenze fra pubblico e privato, push protection, validity check (che etichettano un segreto rilevato come attivo, inattivo o sconosciuto, per dare priorità alle credenziali ancora vive), ciclo di vita dell’alert, custom pattern, destinatari ed esclusioni, policy di delegated bypass. Qui si nasconde una distinzione che l’esame ama: delegated bypass governa il percorso di push, delegated alert dismissal governa la chiusura degli alert. Sono due controlli separati, e uno non copre l’altro.
3. Configurare e usare la supply chain security (15–20%)
Dependency graph e SBOM (formati e opzioni di export), alert e security update con la loro prioritizzazione — fra i criteri la study guide nomina esplicitamente lo scoring EPSS —, remediation tramite campagne e pull request, comportamento di auto-dismiss e regole di auto-triage, dependency review come controllo pre-merge con validazione di licenze, e le regole avanzate di aggiornamento: raggruppamento, strategie, applies-to. Il livello di dettaglio richiesto è questo: in un blocco groups del file dependabot.yml, se ometti applies-to il gruppo vale solo per i version update, non per i security update.
4. Configurare e usare Code Security (10–15%)
Scelta fra CodeQL e strumenti di terze parti, ingestione di file SARIF 2.1.0, e soprattutto la differenza fra default setup — il modo più rapido e a bassa manutenzione di accendere il code scanning — e advanced setup, necessario quando devi definire un tuo workflow GitHub Actions: compilare linguaggi compilati, usare una matrice di build, cambiare la frequenza dell’analisi. Poi triage dei risultati con l’analisi di dataflow, autofix, gestione di severità e categorie, troubleshooting delle analisi che falliscono o durano troppo.
5. Operazioni di sicurezza: pratiche, priorità, remediation (15–20%)
CVE, CWE e GitHub Security Advisory, ruleset che definiscono e impongono soglie di severità e di remediation, campagne e gestione massiva degli alert, personalizzazione delle query suite CodeQL per linguaggio e profilo di rischio, ruoli e deleghe, e lo shift left. Le security campaigns, in particolare, servono a raggruppare alert e condividerli con gli sviluppatori: comprendono gli alert di code scanning sul branch predefinito e, in public preview, quelli di secret scanning, e possono essere assegnate a utenti con accesso in scrittura oppure al Copilot cloud agent, perché generi in automatico le pull request di correzione.
6. Amministrare le Security suites (10–15%)
Attivazione a livello di enterprise, organizzazione e repository, differenze fra GitHub Enterprise Cloud e GitHub Enterprise Server, security configuration predefinite e comportamento di ereditarietà, policy e ruleset, confini di enforcement, permessi di bypass ed eccezioni, ruoli di amministratore e security manager, workflow CodeQL approvati e le API per configurare la sicurezza su larga scala.
Come prepararsi
- Parti dai due learning path ufficiali citati nella study guide, GitHub Advanced Security Part 1 e Part 2 su Microsoft Learn: coprono l’ossatura, ma sono più vecchi del refresh di luglio 2026.
- Leggi la documentazione, non i riassunti. L’area
code-securitydidocs.github.comè stata riorganizzata inconcepts,how-tos,referenceetutorials: molti percorsi che trovi nelle guide di terze parti non esistono più, e i contenuti aggiornati stanno solo lì. - Costruisci le coppie che si confondono. Delegated bypass contro delegated alert dismissal; default setup contro advanced setup; version update contro security update; Secret Protection contro Code Security; repository pubblico contro privato.
- Prova su un’organizzazione vera. Applica una security configuration, imponi una dependency review, fatti bloccare da push protection. Gli scenari d’esame sono narrativi: si riconoscono solo se hai già visto il sintomo.
- Chiudi con le simulazioni, per scoprire quale dominio ti costa punti prima che te lo dica il report ufficiale.
Cosa trovi — e cosa non trovi — nella simulazione CertUp
La simulazione GH-500 è gratuita e attinge a un banco di 80 domande; ogni sessione ne estrae 50 con timer di 100 minuti e soglia a 700/1000. Durata e soglia sono quelle ufficiali; le 50 domande no: GitHub non pubblica il numero di domande dell’esame reale, e 50 è una convenzione nostra per una prova da 100 minuti.
Due differenze, dette chiaramente. Le domande sono in inglese come all’esame vero — che in italiano non esiste — mentre interfaccia e spiegazioni sono in italiano. E i formati: riproduciamo scelta singola, scelta multipla e matrici sì/no, mentre la pagina ufficiale avvisa che l’esame può contenere componenti interattive, che noi non simuliamo. Alla consegna il report mostra la spiegazione di ogni risposta, comprese le ragioni per cui le alternative sono sbagliate.
In sintesi
GH-500 certifica che sai mettere in sicurezza un’organizzazione GitHub, non un singolo repository: prevenire le fughe di segreti, sapere cosa c’è dentro le tue dipendenze, leggere i risultati dell’analisi statica e — la parte che distingue i candidati preparati — decidere in che ordine sistemare le cose e chi ha il diritto di derogare. È un esame da 100 minuti, soglia 700, obiettivi riscritti a luglio 2026 e prodotti che hanno cambiato nome mentre la certificazione no. Se stai pianificando il percorso GitHub, confronta GH-500 con le altre certificazioni nella pagina GitHub di CertUp.