Cosa fa Agentic Autofix, e dove si ferma
Quando assegni uno o più alert di code scanning a Copilot, Agentic Autofix avvia una sessione, esplora file rilevanti anche oltre quello segnalato, genera una modifica e prova a validarla. Se il flusso arriva in fondo, apre una pull request in bozza con il riepilogo della correzione e dei controlli eseguiti.
La validazione documentata consiste nel rieseguire CodeQL con la query suite di code scanning e verificare che l’alert si chiuda. È una prova importante ma circoscritta: dimostra che quella configurazione non rileva più lo stesso problema. Non dimostra da sola che la causa sia stata rimossa in ogni percorso, che il comportamento legittimo sia rimasto intatto o che non siano comparse altre regressioni.
GitHub definisce la funzione best effort e chiede esplicitamente di revisionare e testare le modifiche prima del merge. La pull request nasce come bozza proprio perché il risultato è un candidato alla review, non una correzione approvata.
Agentic Autofix e Copilot Autofix risolvono compiti diversi
GitHub mantiene due esperienze separate. Copilot Autofix genera una singola proposta per un alert supportato, che puoi leggere e applicare. Agentic Autofix prende in carico uno o più alert, indaga il repository, itera sulla patch, prova a validarla e prepara una pull request.
Anche accesso e costo cambiano. Ogni sessione Agentic Autofix consuma Code Security AI Credits e minuti GitHub Actions; Copilot Autofix non consuma AI Credits. Una licenza GitHub Copilot non è richiesta per usare Agentic Autofix, ma disponibilità, policy e fatturazione dipendono dal proprietario, dalla visibilità del repository e dal piano Code Security o Advanced Security applicabile.
- Copilot Autofix
- Una proposta puntuale per un singolo alert supportato. Sei tu a creare e verificare la pull request.
- Agentic Autofix
- Una sessione agentica che può esplorare più file, correggere uno o più alert, validare best effort e aprire una draft pull request.
Prima di attivarlo, controlla accesso, scope e costo
La documentazione corrente indica Agentic Autofix per repository pubblici su GitHub.com e per repository di organizzazioni con GitHub Code Security o GitHub Advanced Security; esclude i repository personali appartenenti a Enterprise Managed Users. L’annuncio GA del 15 ottobre descrive invece soprattutto l’accesso dei clienti GitHub Code Security e Advanced Security su Enterprise Cloud. Verifica quindi ciò che il tuo account mostra, senza dedurre la disponibilità dal solo annuncio.
Le policy si propagano dall’impresa all’organizzazione e al repository. Consentire la funzione a livello enterprise non la attiva automaticamente; quando l’organizzazione la abilita, i repository idonei risultano attivi per default e i loro amministratori possono fare opt-out. Chi ha usato la public preview deve abilitarla di nuovo.
La funzione lavora sugli alert arretrati della branch predefinita. Gli alert presenti soltanto su pull request o altre branch non possono essere assegnati. Puoi selezionare fino a 25 alert in una sessione e una pull request, ma il primo pilot dovrebbe partire da un solo alert: il diff resta più leggibile e puoi attribuire meglio ogni esito.
- Policy enterprise, organizzazione e repository controllate separatamente.
- Metodo di fatturazione e budget Code Security AI Credits definiti prima del pilot.
- Minuti GitHub Actions monitorati insieme ai crediti AI.
- Istruzioni personalizzate del repository rilette: possono guidare build e test, ma non sostituiscono l’invariante di sicurezza.
- Primo caso sulla branch predefinita, non critico e con un solo alert.
- Repository con dati, segreti o vincoli speciali esclusi finché il workflow non è stato validato.
La riesecuzione CodeQL ha limiti precisi
La documentazione distingue gli alert che Agentic Autofix può provare a confermare. La validazione usa la query suite di code scanning: non può confermare le correzioni per query CodeQL personalizzate, per la suite security-extended o per alert prodotti da strumenti di terze parti.
Anche sugli alert supportati, la scomparsa del finding resta un segnale della stessa famiglia che lo ha prodotto. Per ridurre il rischio di una correzione che aggira soltanto la query, aggiungi una prova indipendente collegata al comportamento: un regression test, un controllo di autorizzazione o un caso sintetico che falliva prima e passa dopo.
Se Copilot non riesce a validare la patch o ritiene che l’alert possa essere un falso positivo, lo segnala nella pull request. Non trasformare quel limite in un’approvazione manuale automatica: torna al triage dell’alert e documenta perché il percorso è raggiungibile, non raggiungibile o ancora incerto.
Pilot: un alert, una pull request, una prova indipendente
Scegli un alert già compreso dal team e una modifica reversibile. Prima di assegnarlo, registra query, branch, configurazione e invariante di sicurezza atteso. Questo evita di giudicare la patch soltanto dal fatto che il pannello diventa verde.
Dopo l’apertura della draft pull request, leggi il log della sessione e il diff completo. Controlla file inattesi, dipendenze, cambi di configurazione, test rimossi o modificati e nuove eccezioni. Poi esegui i controlli ufficiali del repository e una verifica mirata che rappresenti il problema originale senza usare dati o sistemi di produzione.
- Registra ID dell’alert, query, branch, configurazione e commit di partenza.
- Ricostruisci input, sink, precondizioni e invariante che la correzione deve garantire.
- Prepara un test o riproduttore sicuro con dati sintetici e autorizzati.
- Assegna un solo alert a Copilot e attendi la draft pull request.
- Leggi log, riepilogo della validazione e diff completo; marca ogni modifica fuori scope.
- Esegui build, test del repository e prova mirata sul comportamento vulnerabile e su quello legittimo.
- Controlla che le configurazioni CodeQL pertinenti abbiano rieseguito l’analisi.
- Richiedi review umana indipendente prima del merge e registra rischi residui e rollback.
Alert: <ID E QUERY>
Branch e commit iniziale: <VALORI>
Configurazioni che lo rilevano: <ELENCO>
Invariante di sicurezza:
<COSA DEVE ESSERE BLOCCATO O AUTORIZZATO>
Comportamento legittimo da preservare:
<CASO POSITIVO>
Diff atteso: <FILE O AREA>
Diff reale: <FILE MODIFICATI>
Fuori scope: <NESSUNO / ELENCO>
Riesecuzione CodeQL: <PASS / FAIL / NON APPLICABILE>
Regression test: <COMANDO ED ESITO>
Test del repository: <COMANDI ED ESITI>
Review umana: <APPROVA / CORREGGI / BLOCCA>
Rischi residui: <ELENCO>
Rollback: <PROCEDURA>Venticinque alert in una PR è un massimo, non un obiettivo
GitHub permette di selezionare fino a 25 alert dal backlog o da una security campaign. Una sola assegnazione crea una sessione e una pull request per tutti gli alert scelti. È utile per cause radice omogenee, ma può rendere più difficile attribuire regressioni e capire quale modifica chiude quale finding.
Passa al batch soltanto dopo il pilot e raggruppa alert con la stessa causa, lo stesso proprietario e la stessa strategia di test. Se gli alert attraversano servizi, linguaggi o confini di autorizzazione diversi, separali anche quando l’interfaccia permette di unirli.
- Stessa causa radice e stesso team proprietario: batch valutabile.
- Test condiviso e rollback unico: batch più facile da revisionare.
- Autenticazione, pagamenti o dati personali: pull request piccole e review specialistiche.
- Fix indipendenti o in servizi diversi: sessioni e pull request separate.
- Un alert non validabile: non nasconderlo dentro un batch verde.
Misura il pilot prima di estendere il rollout
Non valutare Agentic Autofix dal numero di alert chiusi. Misura quanti fix sono stati confermati dalla review, quante modifiche fuori scope sono comparse, quali regressioni hanno trovato i test e quanto tempo umano è servito per arrivare a una decisione.
Conserva un piccolo registro per tipo di query e repository. Se una categoria produce patch ampie, validazioni non applicabili o molto lavoro di correzione, resta su triage e fix manuale. La funzione è utile quando riduce il lavoro ripetitivo senza indebolire il livello di prova.
- Alert assegnati, draft PR aperte e fix effettivamente accettati.
- CodeQL rieseguito, non applicabile o incapace di validare.
- Regression test aggiunti e regressioni scoperte.
- File fuori scope e iterazioni richieste al bot.
- Crediti AI, minuti Actions e tempo di review umana.
- Categorie escluse dal rollout dopo il pilot.
Fonti primarie e stato della verifica
Disponibilità generale, flusso di esplorazione, riesecuzione CodeQL, draft pull request, limite di 25 alert e fatturazione provengono dal changelog GitHub del 15 ottobre 2026. Differenze tra Agentic Autofix e Copilot Autofix, limiti della validazione e obbligo di review derivano dalla documentazione GitHub corrente.
Accesso, propagazione delle policy e necessità di riattivare la funzione dopo la preview sono verificati nella guida amministrativa. La fotografia è aggiornata al 19 ottobre 2026. Non ho eseguito una sessione Agentic Autofix né misurato qualità, tempi o costi su un repository reale.
- GitHub Changelog: Agentic autofix for code scanning alerts general availability ↗
- GitHub Docs: differenze e limiti dei due tipi di autofix ↗
- GitHub Docs: assegnare alert e revisionare la draft PR ↗
- GitHub Docs: gestire accesso e rollout di Agentic Autofix ↗
- GitHub Docs: istruzioni personalizzate per Copilot ↗
- DottorLone: checklist prima di accettare codice generato dall’AI →
- DottorLone: verificare finding e correzioni di uno scan →
- DottorLone: quando un’approvazione AI può contare per il merge →