DevOps e sicurezza
GitHub Actions: aggiornamenti a runner e workflow, cosa cambia per CI/CD e sicurezza
Abbiamo ricostruito cosa sta cambiando nei runner GitHub Actions e dentro i workflow. Traduciamo le novità in impatti pratici su tempi build, costi e governance. Tutto è aggiornato al 16 febbraio 2026.
Pubblicato il: Lunedì 16 febbraio 2026 alle ore 17:25. L’articolo riflette le informazioni disponibili alla data di pubblicazione e potrebbe non includere sviluppi successivi che possono incidere sull’inquadramento. Eventuali aggiornamenti saranno riportati nell’Update log. In mancanza di registrazioni nell’Update log, il contenuto deve considerarsi invariato rispetto alla versione pubblicata.
Ultimo aggiornamento: Venerdì 6 marzo 2026 alle ore 09:16. L’aggiornamento può includere interventi non sostanziali (revisione formale, correzioni, impaginazione o ottimizzazioni) e non implica necessariamente modifiche ai fatti riportati. Eventuali aggiornamenti di contenuto relativi agli sviluppi della notizia sono indicati nell’Update log.
Per costruire questa ricostruzione abbiamo incrociato note di rilascio, documentazione e riferimenti di pricing. I dettagli tecnici collidono con quanto pubblicato in GitHub Changelog, GitHub Docs e GitHub Resources.
Oggi il punto non è “c’è un aggiornamento”. Il punto è che un pezzo di Actions sta iniziando a diventare vincolante. Il periodo di brownout sui self-hosted runner è in corso e da qui al 16 marzo 2026 chi resta sotto versione minima si espone a fallimenti intermittenti. In parallelo arrivano nuove immagini per migrare senza traumi, runner arm64 finalmente utilizzabili anche nei repository privati e un runner linux ultra economico per togliere dal budget tutto ciò che non è build pesante. Se gestisci CI in Italia con team piccoli o con piattaforme complesse, questa combinazione sposta davvero il costo totale di ogni rilascio.
Mappa rapida: cosa cambia in quattro mosse
| Passaggio | Cosa accade | Il segnale da notare | Conseguenza |
|---|---|---|---|
| Soglia minima sui self-hosted | Da oggi il runner vecchio inizia a diventare un rischio operativo: parte il brownout e chi è sotto versione minima vede run fallire a finestre. | Workflow che prima “reggevano” iniziano a fallire a intermittenza con errori di versione, senza cambiare una riga di YAML. | Azzeriamo il rumore: aggiornare i self-hosted runner diventa prerequisito, non ottimizzazione. |
| Nuove immagini e nuovi target | Arrivano immagini dedicate per testare Visual Studio 2026 su Windows 2025 e macOS 26 su larger runner, più arm64 anche nei repo privati. | Possiamo fare migrazioni “a lato” con label dedicate e fallback, senza toccare subito i runner di default. | Riduciamo i blocchi da upgrade e anticipiamo incompatibilità su toolchain e dipendenze. |
| Workflow più governabili | Si alzano limiti pratici (workflow riusabili e input di workflow_dispatch) e migliorano debug ed espressività delle condizioni. | Meno workaround: meno JSON compressi in un input, meno catene che si spezzano per limiti artificiali. | Standardizziamo la CI: template riusabili, parametri chiari e log che spiegano davvero perché un job è saltato. |
| Sicurezza e tracciabilità | Arriva allowlist di action per tutti i piani e si rafforza la supply chain con API di metadata sugli artifact e contesto produzione. | La sicurezza smette di essere “best effort”: diventa policy misurabile e applicabile senza Enterprise come prerequisito. | Tagliamo la superficie d’attacco e priorizziamo remediation in base a cosa è davvero in produzione. |
Tip: la tabella è scorrevole. Su mobile scorri con il dito a destra e a sinistra per vedere tutte le colonne.
Il runner self-hosted sotto soglia non è “rischio futuro”: può già interrompere run oggi.
Nuove label Windows e macOS permettono migrazioni parallele con fallback.
ubuntu-slim e arm64 nei repo privati spostano costi e prestazioni senza cambiare prodotto.
Allowlist per tutti i piani e tracciabilità degli artifact: più controllo con meno eccezioni.
Ci sono aggiornamenti che passano come note a piè pagina e altri che cambiano davvero tempi build, costi e governance. Questo è uno di quei momenti.
Trasparenza: metodo e perimetro
Questo pezzo nasce da una ricostruzione tecnica. Abbiamo letto e collegato tra loro i cambiamenti su runner, workflow e sicurezza per capire cosa è operativo oggi e cosa diventa operativo nelle prossime settimane. La scelta editoriale è semplice: prendiamo i dettagli che impattano davvero la pipeline e li traduciamo in decisioni pratiche.
Fonte principale: analisi redazionale su documentazione e note di rilascio ufficiali.
Contesto essenziale: perché questa ondata di update pesa
Di solito gli aggiornamenti di Actions si percepiscono come “miglioramenti”. Questa volta li percepiamo come una stretta che mette ordine. Il punto non è avere più feature. Il punto è ridurre la parte non deterministica della CI, quella che ti fa perdere ore a capire se il problema è nel codice o nell’infrastruttura che lo esegue.
Il pacchetto è coerente: da una parte si alza il livello minimo di runner self-hosted, dall’altra si moltiplicano i percorsi di migrazione controllati su GitHub-hosted. In mezzo ci sono strumenti che rendono più facile standardizzare e più difficile introdurre dipendenze opache. Per chi ha budget stretti o compliance da rispettare, è la combinazione che aspettavamo.
In breve
- Self-hosted runner: oggi parte un brownout per chi è sotto versione minima, enforcement pieno il 16 marzo 2026.
- Runner GitHub-hosted: label nuove per testare Windows 2025 con Visual Studio 2026 e macOS 26 su larger runner, più arm64 anche nei repo privati.
- Costi: ubuntu-slim a 1 vCPU e tariffe ridotte dal 1 gennaio 2026 cambiano il conto finale delle automazioni.
- Governance e sicurezza: allowlist di action e workflow riusabili anche su piani non Enterprise, più strumenti di tracciabilità sugli artifact.
La ricostruzione: runner, workflow e sicurezza
Mettiamola così. Se oggi apri un incident channel per “CI rotta”, la probabilità che dietro ci sia un mismatch di runner sale. E se guardi ai costi, la probabilità che stai pagando minuti su runner grossi per task da 15 minuti sale ancora di più. Questo ciclo di update, messo in fila, spinge esattamente in direzione opposta.
Sommario dei contenuti
- Self-hosted runner: la scadenza che può spezzare la pipeline
- Runner GitHub-hosted: nuove immagini e scelte più fini
- Costi: dove si taglia davvero senza tagliare qualità
- Workflow: limiti più alti e debug più leggibile
- Sicurezza e supply chain: governance e tracciabilità
- Guida pratica: come applicare tutto in modo ordinato
- FAQ
Self-hosted runner: la scadenza che può spezzare la pipeline
Il punto operativo è questo: dal 16 febbraio 2026 parte un periodo di brownout che può rendere inaffidabili le run sui self-hosted runner sotto la versione minima. Il meccanismo è deliberato: finestre di 1 o 2 ore in cui i workflow falliscono, proprio per far emergere i runner non aggiornati. Dal 16 marzo 2026 si passa all’enforcement pieno.
La versione minima richiesta è 2.329.0. Se avete runner “stabili” da mesi e non li toccate perché fanno paura, questo è il momento in cui quella prudenza diventa un rischio. Non serve spaccare la piattaforma. Serve mappare dove gira cosa e alzare la baseline.
Runner GitHub-hosted: nuove immagini e scelte più fini
Sul fronte GitHub-hosted, il lavoro è l’opposto: invece di una migrazione obbligata tutta insieme, arrivano etichette dedicate per test mirati. Su Windows compare una label per Windows Server 2025 con Visual Studio 2026 in public preview. Visual Studio 2026 verrà integrato in windows-2025 quando raggiunge la disponibilità generale il 4 maggio 2026. Tradotto: possiamo scoprire oggi cosa si rompe con la toolchain di domani.
Su macOS, arriva macos-26-large in public preview per i larger runner Intel. È una nicchia, ma è una nicchia che pesa: chi firma app o ha pipeline iOS legacy su Intel adesso ha un percorso chiaro per portare tooling e Xcode avanti senza inventare soluzioni strane.
La terza gamba è arm64. Da fine gennaio 2026 i runner standard Linux e Windows arm64 sono disponibili anche nei repository privati. In privato parliamo di 2 vCPU mentre nel pubblico sono 4 vCPU. Il dettaglio importante non è solo la performance. È che diventa finalmente naturale fare build multi-arch senza emulazione.
Scelta rapida del runner: la matrice che evita discussioni infinite
| Scenario | Label consigliata | Limite | Nota pratica |
|---|---|---|---|
| Lint, formatting, controlli rapidi, task di automazione | ubuntu-slim | 15 minuti, 1 vCPU, esecuzione in container | Costo minimo per minuti e buona densità: ottimo per “pulire” la pipeline e lasciare i runner grandi ai job pesanti. |
| Build e test standard su Linux | ubuntu-24.04 o ubuntu-22.04 | Runner standard, VM dedicata | Se usi ubuntu-latest, oggi equivale a ubuntu-24.04: valuta pinning per ripetibilità quando hai toolchain sensibili. |
| Build multi-arch native e workload arm64 | ubuntu-24.04-arm, ubuntu-22.04-arm, windows-11-arm | Runner standard arm64, 2 vCPU su repo privati | Utile per evitare emulazione e rendere stabile la produzione arm64, con minuti che contano nel piano. |
| Prove di compatibilità .NET e toolchain Windows futura | windows-2025-vs2026 | Public preview | Finestra di test prima che Visual Studio 2026 confluisca in windows-2025 a maggio 2026. |
| Pipeline macOS Intel con tooling recente | macos-26-large | Public preview su larger runner | Scelta mirata per workload che richiedono macOS e Xcode aggiornati su Intel, senza cambiare subito l’immagine standard. |
Costi: dove si taglia davvero senza tagliare qualità
Dal 1 gennaio 2026 le tariffe dei GitHub-hosted runner sono scese fino al 39%. È un dettaglio che sembra “commerciale” ma cambia i conti quando hai carichi prevedibili. Se fai CI su Linux standard il costo per minuto è più basso rispetto al passato e con ubuntu-slim apri una seconda categoria.
Se vi serve un riferimento per fare budget in modo pulito, oggi i prezzi di listino dei runner standard sono questi. Linux 1-core con SKU actions_linux_slim costa $0.002 al minuto. Linux 2-core x64 è a $0.006. Linux 2-core arm64 è a $0.005. Windows 2-core è a $0.010. macOS standard è a $0.062. Il tempo viene arrotondato al minuto intero, quindi una job da 61 secondi vi costa 2 minuti.
Ecco la traduzione pratica. 50.000 minuti di build su Linux 2-core x64 fanno $300. Lo stesso volume su actions_linux_slim fa $100 se quei job stanno dentro il limite di 15 minuti. I larger runner giocano un campionato diverso: lì le minute incluse non entrano e conviene usarli solo dove il parallelismo taglia davvero il tempo di wall clock.
ubuntu-slim è un runner Linux da 1 vCPU e 5 GB RAM che esegue in container, con isolamento hypervisor level 2 e decommission automatico a fine job. Ha un limite duro di 15 minuti. Questo limite è la sua forza: ti obbliga a spostare lì solo ciò che è davvero leggero e così eviti che una pipeline “di servizio” diventi una pipeline che brucia budget.
Qui la logica è semplice. Mettiamo su ubuntu-slim ciò che non produce artifact pesanti e non compila per mezz’ora. Lasciamo su runner standard o larger runner ciò che compila, testa e produce rilascio. Il risultato non è solo risparmio. È anche una coda più corta sui runner grandi.
Workflow: limiti più alti e debug più leggibile
I workflow stanno diventando più modulari senza essere fragili. Oggi possiamo annidare fino a 10 livelli di workflow riusabili e richiamare fino a 50 workflow in totale da una singola run. Questo cambia l’architettura: non devi più scegliere tra riuso e limiti. Puoi costruire una piattaforma interna di CI che non collassa al primo refactor.
In parallelo, workflow_dispatch supporta fino a 25 input. Chi gestisce ambienti e release manuali sa cosa significa. Spariscono una parte delle scorciatoie, tipo l’input unico con JSON dentro. Si torna a parametri separati, leggibili e validabili.
Sulla qualità della vita c’è un altro punto: arriva una nuova funzione case nelle expressions e migliorano i log di valutazione delle condizioni, compresi i casi in cui un job viene saltato. Sembra banale, ma ci fa risparmiare ore. Il tempo perso sulle pipeline spesso è tempo perso a capire un if.
Sicurezza e supply chain: governance e tracciabilità
Due cose qui cambiano davvero la postura. La prima è la allowlist di action e workflow riusabili, ora disponibile su tutti i piani. Per un team che lavora con fornitori o con molte repo, significa poter bloccare la deriva dei “uses” presi a caso. La policy diventa applicabile senza dover cambiare contratto o architettura.
La seconda è più strategica. GitHub introduce API per collegare artifact esterni a GitHub e aggiungere contesto di storage e deployment. In pratica puoi associare un artifact al suo registro, tracciare promozioni nella release pipeline e aggiungere dati su dove è deployato e quale rischio runtime porta. Con questi record puoi filtrare alert di sicurezza in base a ciò che è realmente in produzione. Se usi artifact attestations, l’artifact viene legato crittograficamente a repo e workflow e il livello di garanzia sale.
C’è anche un dettaglio che interessa chi usa OIDC. Nei token OIDC emessi da Actions appare un claim check_run_id. È una cosa piccola ma utile: rende più facile collegare credenziali short lived al check che le ha generate, quindi audit più pulito e meno ambiguità.
Guida pratica: come applicare tutto in modo ordinato
Se dobbiamo farlo bene e senza caos, l’ordine è questo. Prima mettiamo in sicurezza l’esecuzione. Poi separiamo i test di immagine dal default. Dopo di che tocchiamo costi e governance.
1) Verifica runner self-hosted e pianifica l’upgrade
- Inventaria i runner self-hosted per versione e per runner group, perché il problema spesso è “uno solo” che regge pezzi critici.
- Allinea a 2.329.0 o superiore prima del 16 marzo 2026, così esci dalla zona di brownout e riduci sorprese.
2) Aggiungi un canary job per le nuove immagini
Il trucco è non toccare il job che rilascia. Aggiungi un job parallelo che gira sulle nuove label, solo su push in branch controllati o su schedule. Quando fallisce non blocca nulla, ma ti dice dove intervenire.
3) Sposta la “coda leggera” su ubuntu-slim
Qui dobbiamo essere onesti. Se un job supera 15 minuti non lo sposti. Se un job compila e genera artifact pesanti non lo sposti. Tutto il resto è materiale da ubuntu-slim e spesso sono proprio i job ripetitivi che bruciano minuti.
4) Chiudi la porta: allowlist e pinning dove serve
Allowlist significa ridurre l’entropia. Non è bloccare per principio. È fare in modo che ogni uses sia una scelta autorizzata. Per chi ha Enterprise Cloud, il passo successivo è richiedere il pinning delle action a commit SHA pieno. In contesti regolati è il modo più semplice per evitare aggiornamenti impliciti.
Nota operativa: la cache ora ha un limite di 200 upload al minuto per repository per nuove entry. Non impatta i download. Se avete pipeline che generano centinaia di cache in pochi secondi, oggi serve consolidare chiavi e ridurre la frammentazione.
Il commento dell’esperto
Qui c’è un messaggio implicito che vale più della singola feature. GitHub Actions sta riducendo lo spazio in cui la CI è “arte” e sta spingendo verso scelte ripetibili. Versione minima sul runner self-hosted significa baseline. Nuove label e runner specifici significano migrazione controllata. Allowlist ovunque significa policy.
Il rischio che vediamo nei team italiani è sempre lo stesso. La CI viene trattata come un costo tecnico, quindi la si tocca poco. Poi all’improvviso diventa un costo di business, perché blocca un rilascio o perché esplode la fattura dei minuti. Con ubuntu-slim e con arm64 nei repo privati, oggi c’è una strada chiara per separare ciò che costa poco da ciò che costa tanto. Con le nuove immagini Windows e macOS, c’è una strada per migrare senza fermare la linea.
La parte più importante, per noi, è la tracciabilità. Quando inizi a legare artifact, storage e deploy dentro la stessa vista, smetti di discutere di sicurezza in astratto. Inizi a discutere di cosa è esposto, cosa processa dati sensibili e cosa merita di essere corretto subito. È un salto culturale prima ancora che tecnico.
A cura di Junior Cristarella.
Domande frequenti
Qual è la cosa urgente oggi, 16 febbraio 2026?
Se usi self-hosted runner, la priorità è verificare la versione: è iniziato un periodo di brownout e la soglia minima diventa enforcement pieno dal 16 marzo 2026. Un runner sotto soglia può portare a fallimenti intermittenti.
Quando ha senso usare ubuntu-slim a 1 vCPU?
Ha senso per job brevi e ripetibili, non per build pesanti. È un runner Linux che esegue in container con limite di 15 minuti: perfetto per lint, format, automazioni e task “di controllo” della pipeline.
Come gestiamo le nuove immagini Windows e macOS senza bloccare la CI?
La strategia migliore è un canary job: aggiungi una matrice o un job parallelo con label dedicate (Windows con Visual Studio 2026 in preview e macOS 26 su larger runner) mantenendo un fallback. Quando i test sono verdi, sposti il default.
Cosa cambia davvero con arm64 anche nei repository privati?
Diventa pratico fare build multi-arch native anche su repo non pubblici, evitando emulazione. Inoltre questi runner standard contano nei minuti inclusi del piano, quindi non sono una scelta “premium” per definizione.
La governance delle action è solo un tema Enterprise?
No. L’allowlist delle action e dei workflow riusabili è ora disponibile su tutti i piani, quindi possiamo applicare policy di controllo anche su organizzazioni più piccole senza cambiare piattaforma.
Qual è il pezzo più sottovalutato lato sicurezza CI/CD in questo ciclo di update?
La tracciabilità end to end degli artifact. Con record di storage e deployment e vista unificata, la sicurezza può legare vulnerabilità a ciò che è realmente deployato e priorizzare in base al rischio runtime.
I limiti dei workflow riusabili e di workflow_dispatch cambiano il modo di scrivere pipeline?
Sì, perché riducono workaround. Con 10 livelli di nesting e fino a 50 workflow richiamabili in una singola run, l’architettura modulare diventa sostenibile. Con 25 input su workflow_dispatch, i trigger manuali e via API diventano più leggibili.
Timeline operativa: apri le fasi in ordine
La timeline serve a trasformare le novità in una sequenza di lavoro concreta. Apri una fase e usala come guida.
-
Fase 1 Mettere a posto il pavimento: aggiornare i self-hosted runner prima che blocchino i rilasci
- Verifica la versione del runner su ogni pool e soprattutto su quelli “dimenticati” in ambienti legacy.
- Porta tutto almeno alla versione minima richiesta per evitare brownout e enforcement.
- Segna in runbook la procedura di upgrade e la finestra di manutenzione, perché da qui in avanti la soglia si muoverà ancora.
Perché conta: Un runner vecchio non è solo una debolezza di sicurezza, è downtime mascherato: quando fallisce a finestre ti manda fuori pista.
-
Fase 2 Separare test e default: provare le nuove immagini senza riscrivere mezza pipeline
- Aggiungi job “canary” con le nuove label Windows e macOS per scoprire incompatibilità prima della migrazione.
- Pinna i runner critici a label esplicite quando la ripetibilità è più importante della freschezza.
- Prepara un rollback semplice con label alternative già previste nel workflow.
Perché conta: La migrazione migliore è quella che fai in parallelo: separi il rischio dalla produzione e trasformi la sorpresa in un test.
-
Fase 3 Ridurre i costi senza ridurre la qualità: usare ubuntu-slim e arm64 dove ha senso
- Sposta lint, formatting, task di repo maintenance e automazioni brevi su ubuntu-slim.
- Usa arm64 per build multi-arch e container image quando vuoi evitare emulazione e mantenere performance native.
- Ricalcola il budget: dal 1 gennaio 2026 le tariffe GitHub-hosted sono state ridotte fino al 39%.
Perché conta: Il risparmio più pulito è quello che non cambia output: cambi solo dove gira il job, poi misuri tempi e costi in modo comparabile.
-
Fase 4 Governance come codice: allowlist, riuso e limiti più alti per farlo sul serio
- Imposta allowlist di action e reusable workflow per ridurre l’ingresso di codice non controllato.
- Con limiti più alti su nesting e numero di workflow riusabili, diventa realistico centralizzare la CI senza spezzarla.
- Sfrutta l’aumento degli input su workflow_dispatch per rendere run manuali e API-driven più puliti.
Perché conta: Quando la governance arriva prima dei problemi, i team smettono di “inventare” e iniziano a comporre in modo coerente.
-
Fase 5 Supply chain con contesto produzione: legare artifact, storage e deploy alle decisioni di sicurezza
- Aggancia i tuoi artifact a GitHub anche se vivono fuori, così la catena non si rompe tra build e deploy.
- Aggiungi record di storage e deployment per filtrare alert in base a ciò che è esposto o davvero in uso.
- Se usi attestations, ottieni un legame crittografico tra artifact, repo e workflow e alzi il livello di garanzia.
Perché conta: La priorità cambia quando hai contesto: non sistemi “tutto”, sistemi prima ciò che sta girando sotto traffico reale.
Chiusura
Se ci portiamo via una regola sola è questa: la CI deve essere prevedibile. Per esserlo serve un runner aggiornato, scelte di immagine esplicite quando serve e una separazione netta tra job leggeri e job pesanti. Dal lato sicurezza serve ridurre l’ingresso di componenti non controllati e serve legare gli artifact al loro percorso fino alla produzione. Actions sta andando lì. Se lo seguiamo con metodo, il risultato è meno rumore, meno incident e rilasci più tranquilli.
Approfondimenti correlati
Tecnologia: news, guide e analisi
Il nostro hub Tecnologia: trovi le analisi che contano su piattaforme, sicurezza e strumenti per chi sviluppa.
Apri la pagina hubUpdate log
Registro degli aggiornamenti sostanziali: trasparenza su modifiche, correzioni e integrazioni informative.
- Lunedì 16 febbraio 2026 alle ore 19:08: Aggiornata la sezione sui self-hosted runner: brownout in corso dal 16 febbraio e scadenza di enforcement al 16 marzo 2026 per la versione minima del runner.
- Lunedì 16 febbraio 2026 alle ore 19:33: Integrata la guida operativa sulle nuove immagini Windows e macOS e sui runner arm64 e ubuntu-slim, con indicazioni pratiche per test e rollback.
- Lunedì 16 febbraio 2026 alle ore 19:56: Rafforzata la parte su governance e supply chain: allowlist estesa a tutti i piani, limiti aggiornati per workflow riusabili e nuove opzioni di tracciabilità degli artifact.
