Agentic Autofix di GitHub è GA: dall'avviso di sicurezza a una correzione revisionata

Un avviso di sicurezza segnala che qualcosa richiede attenzione. Non spiega necessariamente come modificare l'applicazione senza romperla. Per chi mantiene da poco una piccola app, questa lacuna può bloccare una correzione prima ancora di iniziare; per uno sviluppatore, può lasciare crescere una coda di avvisi ormai familiari.

Il 15 ottobre 2026 GitHub ha annunciato la disponibilità generale di Agentic Autofix per gli avvisi di Code Scanning. Assegna un avviso a Copilot e un agente esamina il codice, propone modifiche, tenta la convalida e apre una pull request in bozza. Il cambiamento utile sta nel punto di partenza: una proposta di correzione da ispezionare, invece di un editor vuoto. Annuncio GA di GitHub, 15 ottobre 2026

Questa guida ti accompagna da un repository idoneo alla prima correzione revisionata, poi mostra come gestire avvisi correlati, scanner personalizzati, costi e tentativi non riusciti. Il nostro consiglio: considera l'agente un autore di patch, non chi approva il rilascio. Prima che la modifica entri nell'applicazione, devi comunque capirla.

Il diagramma iniziale separa la riparazione proposta dall'agente dalla decisione umana di eseguire il merge.

Comincia da un avviso, non dall'intera coda

Il primo successo dovrebbe essere una modifica che puoi spiegare, testare e revisionare. Una pull request propone di integrare modifiche nel ramo principale di un progetto; la dicitura draft indica che la proposta non è ancora pronta. CodeQL è il motore di analisi del codice di GitHub, che genera avvisi su codice potenzialmente vulnerabile.

Segui questi passaggi prima di tentare una pulizia estesa:

1. Scegli un repository che amministri. Prima di avviare una sessione dell'agente, conferma l'idoneità, l'approvazione per l'accesso e chi gestisce la fatturazione.
2. Verifica prima l'analisi CodeQL. Se nel repository esiste già un'analisi funzionante, mantienine la configurazione e controlla l'ultima esecuzione riuscita. Per una nuova configurazione, in Settings > Advanced Security > Code Security del repository, trova CodeQL analysis, scegli Set up > Default, esamina la configurazione e seleziona Enable CodeQL. Attendi che l'analisi termini con successo. Istruzioni di configurazione GitHub, verificate il 18 ottobre 2026
3. Abilita Agentic Autofix tramite le policy applicabili. Un interruttore del repository non può ignorare un divieto dell'organizzazione o dell'azienda.
4. Scegli un avviso esistente sul ramo predefinito. Apri Security and quality > Code scanning, seleziona l'avviso e poi Assign to Copilot sotto Assignees. Procedura GitHub per gli avvisi, verificata il 18 ottobre 2026
5. Esamina la pull request in bozza e il log della sessione. Leggi il diff, esegui i test pertinenti e ripeti la scansione con la configurazione che aveva rilevato il problema.
6. Esegui il merge soltanto dopo la revisione umana e i controlli richiesti. Poi verifica lo stato dell'avviso dopo l'analisi del ramo predefinito aggiornato.

Per vedere l'interfaccia, consulta la dimostrazione UI ufficiale di GitHub nell'annuncio GA. Usala come riferimento insieme al tuo repository, senza presumere che un diagramma riproduca ogni schermata attuale.

Il tuo repository pubblico o privato può usarlo?

L'annuncio di lancio pone l'accento sui clienti Enterprise. La documentazione attuale sull'accesso ha portata più ampia: comprende repository pubblici su GitHub.com e repository appartenenti a organizzazioni con GitHub Code Security o GitHub Advanced Security. Non serve una licenza Copilot. Documentazione GitHub sull'accesso, verificata il 18 ottobre 2026

L'accesso pubblico non significa che le sessioni dell'agente siano gratuite. Verifica separatamente l'idoneità del repository e i costi d'uso prima di invitare collaboratori a provare la funzione.

Abilita l'accesso partendo dalla policy più alta applicabile

Per un'organizzazione appartenente a un'azienda, un enterprise owner o security manager deve prima consentire la funzione in Policies > Advanced Security > Agentic Autofix. Questo permesso da solo non la abilita. Un organization owner o security manager la attiva poi in Settings > Advanced Security > Global settings; i repository idonei ereditano l'attivazione. Gli amministratori dei repository possono disattivarla o riattivarla solo se le policy di livello superiore lo consentono. Le organizzazioni autonome saltano il passaggio aziendale; i repository pubblici personali idonei usano direttamente l'impostazione del repository. Chi usava l'anteprima deve abilitarla di nuovo. Procedura GitHub per le policy, verificata il 18 ottobre 2026

Diagramma di accesso: permesso, attivazione e scelta del repository sono decisioni separate. Fonte: documentazione GitHub sull'accesso, verificata il 18 ottobre 2026.

Prima di un'attivazione per tutta l'organizzazione, indica quali repository devono restare esclusi e concorda chi revisionerà le patch generate. Un progetto pilota ragionevole abbina un responsabile del repository a un revisore di sicurezza. Registra l'avviso, il comportamento atteso, il revisore e il responsabile del budget, così una bozza lasciata senza seguito non diventa una responsabilità inspiegabile per qualcun altro.

Verifica che CodeQL abbia davvero analizzato il codice

La configurazione predefinita richiede GitHub Actions e visibilità pubblica oppure Code Security. Esamina i linguaggi selezionati e la suite di query, non soltanto l'interruttore di attivazione. Se una configurazione avanzata esistente funziona, non cambiarla con leggerezza: la configurazione predefinita la sovrascrive, disabilita il flusso di lavoro esistente e blocca i caricamenti tramite API di CodeQL Analysis. Documentazione GitHub sulla configurazione predefinita, verificata il 18 ottobre 2026

Controlla l'ultimo risultato dell'analisi prima di selezionare un avviso. Verifica se il servizio interessato era incluso e se una build o le dipendenze hanno causato un errore di analisi. Un'impostazione contrassegnata come attiva non dimostra che i file pertinenti siano stati analizzati con successo. Risolvi prima i problemi di configurazione, invece di chiedere a un agente di correggere risultati basati su una situazione di partenza inaffidabile.

Per il primo tentativo, scegli un problema circoscritto con comportamento atteso chiaro, come una query al database o uno specifico percorso di rendering dell'output. Evita di partire da una revisione radicale dell'autorizzazione. Se non esiste un avviso pertinente, non introdurre deliberatamente una vulnerabilità in un repository attivo solo per creare una dimostrazione.

Cosa succede tra l'assegnazione e la pull request in bozza?

GitHub descrive un agente che esplora i file pertinenti, genera una correzione, riesegue CodeQL e itera prima di aprire una pull request in bozza. La proposta include un riepilogo della riparazione e i dettagli della convalida. È il flusso di Agentic Autofix, non un merge automatico nel ramo predefinito. Flusso GitHub GA, 15 ottobre 2026

Dopo aver assegnato l'avviso, segui questa revisione:

1. Rileggi il risultato originale. Individua l'input non attendibile, l'operazione sensibile e la protezione attesa. Annota l'identificativo dell'avviso e la configurazione che lo ha rilevato.
2. Leggi ogni file modificato. Cerca cambiamenti estranei, controlli rimossi, test disattivati, nuove dipendenze e comportamenti d'errore modificati.
3. Esamina le prove della sessione. Distingui una scansione completata da un comando fallito o da una dichiarazione che la convalida non era disponibile. Puoi chiedere un'iterazione tramite la sessione o con una menzione di Copilot in un commento alla pull request. Indicazioni GitHub sulle sessioni, verificate il 18 ottobre 2026
4. Esegui i test dell'applicazione e lo scanner pertinente. Usa i comandi di test documentati dal progetto in un ambiente di sviluppo appropriato. Prima di eseguire codice non familiare, ispeziona gli script di configurazione e le modifiche ai flussi di lavoro.
5. Richiedi l'approvazione umana. Mantieni la bozza bloccata finché comportamento, copertura della scansione o responsabilità non sono chiariti. Contrassegnala come pronta solo quando le prove sono verificabili.

Ciclo di revisione: la bozza prodotta dall'agente è un artefatto intermedio, non una prova che l'applicazione sia sicura. Fonti: annuncio GitHub e documentazione sulla risoluzione degli avvisi.

Le pull request GitHub mostrano il diff in Files changed e i risultati automatici in Checks. Usa entrambi: un riepilogo verde non spiega se un controllo dei permessi modificato continua a far rispettare le regole dell'applicazione. Concetti GitHub sulle pull request, verificati il 18 ottobre 2026

Flusso 1: correggi una piccola query al database senza cambiarne il significato

Immagina un servizio Python fittizio che cerca un articolo di inventario tramite etichetta. L'implementazione attuale inserisce l'etichetta fornita nell'SQL usando la formattazione di stringhe e un avviso di scansione del codice individua la costruzione della query. Una correzione utile separa l'istruzione SQL dal valore, invece di cercare di eliminare singoli caratteri di punteggiatura.

Un'implementazione illustrativa più sicura con l'interfaccia sqlite3 di Python è:

def find_item(connection, label):
    return connection.execute(
        "SELECT id, label FROM inventory WHERE label = ?",
        (label,),
    ).fetchone()

Il segnaposto associa il valore separatamente dal testo SQL, seguendo le indicazioni ufficiali di Python sul binding dei parametri, verificate il 18 ottobre 2026. È un modello di correzione fittizio, non un risultato di Agentic Autofix né una prova riportata. In un servizio reale query, schema e regole di autorizzazione richiedono una revisione propria.

In questo esempio chiedi test per un'etichetta normale, un'etichetta con apostrofo come Maker's Kit e un'etichetta inesistente. Verifica che la funzione mantenga il comportamento previsto di restituzione della riga oppure di None. Poi prova le regole di accesso già presenti nell'endpoint chiamante: una query parametrizzata non stabilisce chi può leggere l'inventario.

Un commento di revisione utile sarebbe: «Mantieni invariato il comportamento della ricerca, associa l'etichetta come dato e aggiungi copertura di regressione per apostrofi e articoli inesistenti». Descrive il contratto, invece di limitarsi a dire all'agente di far sparire l'avviso. Prima di accettarla, riesegui la scansione sulla patch effettiva.

Flusso 2: raggruppa gli avvisi correlati, non quelli scelti a caso

Supponiamo che un servizio web fittizio abbia tre avvisi associati allo stesso helper di rendering delle risposte. Esaminali insieme per capire se sia appropriata un'unica correzione condivisa. GitHub consente di selezionare fino a 25 avvisi arretrati dall'elenco o da una campagna di sicurezza; un'assegnazione genera una sessione e una pull request. Istruzioni GitHub per assegnazioni in blocco, verificate il 18 ottobre 2026

Il limite è una capacità massima, non la dimensione consigliata per un gruppo. Tre problemi correlati con un unico responsabile possono essere più facili da revisionare di venti problemi non correlati che coinvolgono autenticazione, gestione dei file e accesso al database. Prima dell'assegnazione, elenca ogni endpoint coinvolto e il comportamento ordinario da preservare.

In questo flusso illustrativo, esamina l'helper condiviso e prova ogni chiamante. Se la correzione proposta cambia l'escaping dell'output, controlla i contesti d'uscita previsti invece di approvarla solo perché un esempio ora sembra corretto. Dividi il lavoro quando i problemi richiedono revisori o calendari di rilascio diversi. Non lasciare che un avviso irrisolto nasconda quali riparazioni abbiano davvero prove a sostegno.

Flusso 3: uno scanner personalizzato richiede una verifica specifica

Agentic Autofix gestisce solo gli avvisi arretrati sul ramo predefinito. Gli avvisi presenti soltanto in una pull request o in un altro ramo non rientrano nel flusso di assegnazione. Se una nuova pull request introduce un problema, correggilo lì invece di integrare codice vulnerabile solo per poterlo assegnare. Dichiarazione GitHub sull'ambito, 15 ottobre 2026

C'è un altro limite: GitHub afferma che la convalida dell'agente non può confermare correzioni per query CodeQL personalizzate, la suite security-extended di CodeQL o avvisi di scanner di terze parti. La convalida integrata riesegue, secondo disponibilità, la suite di query di scansione del codice. Limiti della convalida GitHub, verificati il 18 ottobre 2026

Immagina un'organizzazione fittizia con una query personalizzata che applica una regola interna sulla gestione dei dati. Anche se l'agente propone una patch plausibile, il revisore deve eseguire quell'analisi specifica e ispezionarne il risultato. Annota versione della query, configurazione, revisione analizzata ed esito. Un'esecuzione riuscita della suite predefinita non sostituisce la query che ha segnalato il problema.

Mantieni attivo lo scanner più rigoroso. Ridurre la copertura per ottenere uno stato verde cambia la misurazione, non la sicurezza dell'applicazione. Se non puoi riprodurre l'analisi richiesta, lascia la proposta in attesa di convalida e indica chi può eseguirla.

Nessuna licenza Copilot non significa nessuna fattura

Agentic Autofix consuma Code Security AI Credits e minuti GitHub Actions. La documentazione di fatturazione GitHub specifica che i crediti AI vengono consumati anche nei repository pubblici che non richiedono licenze per i committer attivi. Gli eventuali crediti AI inclusi, se l'account fatturato ha il diritto applicabile, vengono usati per primi; l'uso ulteriore è a consumo, e gli account senza crediti inclusi pagano a consumo fin dall'inizio. Fatturazione GitHub degli AI credit, verificata il 18 ottobre 2026

Per i repository di un'organizzazione, gli addebiti ricadono sull'account pagante dell'organizzazione o dell'azienda. Prima di un'attivazione estesa, controlla disponibilità e budget Code Security AI Credits di quell'account. L'annuncio richiede anche un metodo di fatturazione Copilot configurato: è cosa diversa dal richiedere una licenza Copilot a ogni utente. Requisiti di fatturazione GitHub al lancio, 15 ottobre 2026

Per il progetto pilota, registra consumo delle sessioni, uso di Actions, tempo dei revisori e accettazione della patch. Non promettere un prezzo fisso per avviso corretto: un gruppo, un'iterazione o una proposta non riuscita richiedono comunque una verifica dei costi. Confronta il costo delle correzioni accettate con il flusso attuale, invece di contare le pull request generate come riparazioni completate.

Il Copilot Autofix classico è diverso: offre una modifica suggerita in un unico passaggio, invece del flusso con indagine e bozza dell'agente, e i suoi suggerimenti non consumano AI credit. Dove supportato, resta un'opzione quando Agentic Autofix non è attivo. Confronto GitHub, verificato il 18 ottobre 2026

Prima del merge, rispondi a queste sette domande

La nostra lista di revisione mira a preservare il comportamento oltre che rimuovere la debolezza segnalata:

• Causa principale: la patch corregge l'operazione non sicura o si limita a sopprimere l'avviso?
• Ambito: refactoring estranei, nuove dipendenze e modifiche di configurazione sono giustificati?
• Comportamento: input validi e non validi, errori e permessi continuano a funzionare correttamente?
• Test: esiste un test di regressione che intercetterebbe il problema originale?
• Analisi: lo scanner che ha segnalato il problema ha analizzato la revisione proposta con la configurazione richiesta?
• Approvazione: una persona responsabile ha revisionato il diff e gli eventuali appunti irrisolti dell'agente?
• Dopo il merge: l'analisi del ramo predefinito ha confermato lo stato atteso dell'avviso senza nuove segnalazioni?

Considera «convalida non disponibile» un'attività incompleta, non un'approvazione. GitHub dice che l'agente può dichiarare nella pull request di non essere riuscito a convalidare o di sospettare un falso positivo. Nessuna delle due affermazioni sostituisce il giudizio del responsabile. Comportamento best effort di GitHub, verificato il 18 ottobre 2026

E se manca il pulsante o il risultato è sbagliato?

Perché vedo l'avviso ma non posso assegnarlo? Controlla che riguardi la coda del ramo predefinito, l'idoneità del repository, l'attivazione della funzione e i tuoi permessi. Per assegnare serve l'accesso in scrittura. Se un'impostazione è bloccata, chiedi all'amministratore competente invece di alternare ripetutamente il controllo del repository. Prerequisiti di assegnazione GitHub, verificati il 18 ottobre 2026

Una scansione pulita dimostra che l'app è sicura? No. Risponde alle domande coperte da quella specifica analisi e configurazione. Regole di business, autorizzazioni, comportamento in esecuzione e risultati non supportati richiedono comunque test e revisione adeguati.

Devo continuare a riprovare una sessione fallita? Prima esamina log e diff proposto. Individua ciò che manca: configurazione dell'analisi, esecuzione dei test, contesto del progetto o correzione proposta. Fornisci un'indicazione precisa oppure sistema la configurazione sottostante prima di un nuovo tentativo; riassegnare senza nuove informazioni non è una strategia di riparazione.

Posso accettare un falso positivo sospetto? Indaga autonomamente il risultato e documenta il ragionamento. Non confondere la chiusura di un avviso con la correzione del codice vulnerabile e non lasciare che la sicurezza dichiarata dall'agente decida un'eccezione al rischio.

In sintesi: una correzione proposta è l'inizio della revisione

Agentic Autofix anticipa una parte utile del lavoro: indagine, patch candidata e convalida disponibile arrivano insieme. Il vantaggio pratico è ridurre la distanza tra il riconoscimento di una vulnerabilità e la revisione di una correzione concreta. Mantieni circoscritto il primo tentativo, conserva gli scanner e fai dipendere l'accettazione dalle prove, non da chi ha scritto la patch.

Fonti

Riferimenti primari verificati il 18 ottobre 2026.

I link di questa guida rimandano all'annuncio GA del 15 ottobre di GitHub, alle policy di accesso aggiornate, ai concetti e limiti di Autofix, alle procedure di risoluzione degli avvisi, alla configurazione CodeQL e alla documentazione di fatturazione. La documentazione è uno snapshot datato dell'accesso, non una garanzia della configurazione di ogni account. I tre flussi sono illustrativi, non resoconti di prove pratiche.

Un posto per le tue note di revisione: conserva insieme link alle fonti, riferimenti agli avvisi, esiti dei test e decisioni in Telli.sh. Può organizzare i tuoi appunti; non esegue scansioni dei repository né approva correzioni. Crea un account Telli.sh.