(in)sicurezza digitale

2026-05-13 23:20:00

GitLab Act 2: il manifesto dell’AI agentica che promette il futuro e inquieta gli sviluppatori

Quando una piattaforma DevSecOps da miliardi di dollari decide di riscrivere la propria identità attorno agli agenti AI, non sta semplicemente annunciando una nuova roadmap di prodotto. Sta dichiarando che il modello stesso di sviluppo software che abbiamo conosciuto negli ultimi vent’anni è destinato a diventare obsoleto.

È questo il messaggio reale dietro GitLab Act 2, il lungo manifesto pubblicato da GitLab per spiegare la trasformazione interna dell’azienda nell’era dell’AI agentica. Un documento che, più che un post corporate, assomiglia a una dottrina industriale: il software costerà sempre meno produrlo, gli sviluppatori diventeranno supervisori di sistemi autonomi e le organizzazioni dovranno ripensare completamente struttura, processi e ruoli.

Il problema è che, dietro la retorica della “nuova era”, molti sviluppatori vedono qualcosa di molto diverso: una drastica razionalizzazione aziendale mascherata da inevitabile rivoluzione tecnologica.

La tesi di GitLab: il software sarà scritto dalle macchine

Nel manifesto, GitLab sostiene che l’AI generativa stia comprimendo il costo marginale della produzione software in modo paragonabile a quanto avvenuto nell’industria manifatturiera con l’automazione. La conseguenza, secondo l’azienda, non sarà una riduzione della domanda di software ma l’opposto: un’esplosione.

Se creare applicazioni diventa più economico, ogni azienda produrrà più software, più automazione, più integrazioni e più servizi interni. In questo scenario, il valore umano non sarà più nella scrittura manuale del codice ma nella definizione degli obiettivi, nella governance, nella sicurezza e nella supervisione degli agenti AI.

È una narrativa ormai dominante nella Silicon Valley: gli sviluppatori non spariranno, ma evolveranno in orchestratori di sistemi autonomi.

GitLab vuole posizionarsi esattamente al centro di questa transizione con la propria piattaforma “Duo Agent Platform”, immaginata come un layer operativo in cui agenti AI collaborano lungo l’intero ciclo DevSecOps: pianificazione, sviluppo, code review, security scanning, remediation, test e deployment.

Non più copiloti. Non più semplici assistenti. Ma entità autonome capaci di eseguire task complessi all’interno delle pipeline.

La ristrutturazione interna è il vero cuore del manifesto

La parte più interessante del documento non è però tecnologica. È organizzativa.

GitLab annuncia infatti una profonda trasformazione della propria struttura interna. L’azienda parla apertamente di riduzione dei livelli manageriali, team più piccoli e autonomi, maggiore automazione operativa e integrazione massiccia dell’AI nei processi decisionali.

I gruppi R&D verranno suddivisi in circa 60 unità snelle, progettate per muoversi più rapidamente e lavorare in parallelo insieme agli agenti AI. Nel manifesto si percepisce chiaramente un’influenza delle metodologie “founder mode” e delle moderne filosofie ultra-efficientiste adottate da molte aziende AI-first.

Tradotto dal linguaggio corporate: meno coordinamento umano, meno middle management e più automazione decisionale.

Ed è qui che la community ha iniziato a reagire in modo estremamente critico.

La critica principale: “state inseguendo l’hype”

Molti sviluppatori hanno interpretato Act 2 come il segnale definitivo che GitLab stia inseguendo il trend AI sacrificando progressivamente gli elementi che l’avevano resa popolare nella community engineering.

Nel forum ufficiale e su diverse discussioni tecniche, il malcontento è emerso rapidamente. Alcuni utenti accusano GitLab di aver trasformato la piattaforma in un contenitore di feature AI ancora immature mentre problemi storici di UX, performance e stabilità rimangono irrisolti.

Il timore più diffuso è che l’azienda stia vendendo una visione futuristica molto più avanzata della realtà tecnica attuale.

Ed effettivamente esiste un forte scollamento tra la narrativa dell’AI agentica e lo stato reale degli LLM moderni.

Per quanto impressionanti, gli agenti AI soffrono ancora problemi enormi in contesti enterprise:

• perdita di contesto su codebase estese;
• hallucinations in scenari complessi;
• incapacità di ragionamento affidabile multi-step;
• difficoltà nel comprendere architetture legacy;
• fragilità nelle decisioni di sicurezza;
• dipendenza da prompt engineering estremamente fragile.

Nel mondo DevSecOps questi limiti non sono marginali. Sono potenzialmente catastrofici.

Automatizzare una pipeline CI/CD è relativamente semplice. Delegare ad agenti AI remediation di vulnerabilità, code review o decisioni infrastrutturali in ambienti enterprise è un’altra storia.

Soprattutto quando si parla di sicurezza.

Il nodo cybersecurity: chi valida l’agente?

Dal punto di vista della cybersecurity, il manifesto di GitLab apre questioni enormi che nel documento vengono affrontate solo superficialmente.

Se gli agenti AI diventano parte attiva della supply chain software, diventano automaticamente anche una nuova superficie d’attacco.

Un agente che modifica codice, approva merge request o interagisce con pipeline CI/CD introduce rischi completamente nuovi:

• prompt injection nei workflow DevOps;
• poisoning dei contesti RAG;
• manipolazione degli agenti tramite issue o commenti malevoli;
• escalation di privilegi attraverso tool integration;
• generazione di codice vulnerabile apparentemente corretto;
• supply chain compromise mediata da AI.

La community security sta già osservando casi concreti di agenti AI manipolabili tramite input indiretti, specialmente quando connessi a repository, ticketing system o documentazione interna.

In pratica, il problema non è più soltanto “il codice è vulnerabile?”, ma anche:

“l’agente che ha preso la decisione era affidabile?”

È una differenza enorme.

GitLab sembra convinta che governance e supervisione umana saranno sufficienti a mitigare questi rischi. Ma molti esperti ritengono che l’industria stia sottovalutando drasticamente la complessità della sicurezza negli ecosistemi agentici.

Il sottotesto economico: fare di più con meno persone

C’è poi un altro elemento che ha generato parecchio nervosismo: il sospetto che “Act 2” sia soprattutto un piano di efficientamento.

Nel manifesto, GitLab evita accuratamente toni allarmistici sui posti di lavoro, ma il messaggio implicito è difficile da ignorare. Se gli agenti AI aumentano drasticamente la produttività, le aziende avranno bisogno di meno persone per svolgere gli stessi task.

Molti hanno letto il documento come la formalizzazione di una tendenza già evidente nel settore tech: usare l’AI come leva per comprimere organici, ridurre management intermedio e aumentare output per dipendente.

Ed è qui che la narrativa “visionaria” inizia a somigliare a qualcosa di molto più concreto: una ridefinizione radicale del rapporto tra capitale umano e automazione nel software engineering.

Un manifesto che racconta il futuro del settore

Al di là dell’hype e delle critiche, GitLab Act 2 resta un documento importante perché fotografa perfettamente il momento storico dell’industria software.

Per la prima volta una grande piattaforma DevSecOps non presenta l’AI come una feature aggiuntiva, ma come il fondamento operativo attorno a cui ridisegnare un’intera azienda.

La vera domanda non è se GitLab riuscirà o meno nella trasformazione.

La domanda è quante altre aziende seguiranno lo stesso modello nei prossimi 24 mesi.

Perché se Act 2 dovesse diventare il template organizzativo dell’era agentica, il cambiamento non riguarderà soltanto il modo in cui scriviamo codice.

Riguarderà il modo in cui verranno costruite le aziende tecnologiche stesse.

GitLab Act 2

A letter to our customers and our investors.

^{Bill Staples (about.gitlab.com)}

slowforward

2026-05-13 22:53:35

sospese le sanzioni contro francesca albanese

e aggiungo io: come sempre, non si deve certo allo scandaloso governo ytalyano, servetto dell’amerika e dello stato genocida, se giustizia finalmente arriva per la relatrice ONU, che ha l’unico torto di documentare una verità sotto gli occhi di tutti.
#Cisgiordania #dirittiUmani #FrancescaAlbanese #Gaza #genocidio #humanRights #Israele #Onu #Palestina #sanzioni #sospensioneDelleSanzioni #sospeseLeSanzioniControFrancescaAlbanese #USCourt #USA

(in)sicurezza digitale

2026-05-13 16:06:32

Nitrogen ransomware colpisce Foxconn: 8TB di dati con segreti industriali di Apple, Nvidia e Intel

Il 12 maggio 2026 Foxconn ha confermato un cyberattacco ai danni delle sue fabbriche nordamericane, rivendicato dal gruppo ransomware Nitrogen. Gli aggressori affermano di aver sottratto 8 TB di dati — oltre 11 milioni di file — contenenti documentazione riservata, schemi tecnici e istruzioni di assemblaggio relative a progetti di Apple, Intel, Google, Nvidia e Dell. L’attacco ha bloccato la produzione per giorni in uno dei nodi più critici della supply chain tecnologica globale.

La timeline dell’attacco

Secondo le ricostruzioni, il 1° maggio 2026 i lavoratori del turno di notte dello stabilimento Foxconn di Mount Pleasant, Wisconsin, hanno interrotto la produzione a causa di un’interruzione di rete. Al mattino, i lavoratori del primo turno sono arrivati senza Wi-Fi e sono stati rimandati a casa entro le 11. La produzione è rimasta ferma fino al 4 maggio. Undici giorni dopo, il 11 maggio, il gruppo Nitrogen ha aggiunto Foxconn al proprio data leak site sul dark web, rivendicando il furto di 8 TB di dati e pubblicando campioni come prova.

Foxconn ha confermato l’incidente con una dichiarazione sobria: “Alcune fabbriche di Foxconn in Nord America hanno subito un cyberattacco. Il team di cybersecurity ha immediatamente attivato il meccanismo di risposta e implementato misure operative multiple per garantire la continuità di produzione e consegna. Le fabbriche interessate stanno riprendendo la normale produzione.” L’azienda si è rifiutata di confermare quali dati clienti fossero stati effettivamente esfiltrati.

Chi è Nitrogen: genealogia di un gruppo ransomware

Nitrogen è attivo dal 2023 ed è considerato uno dei numerosi discendenti del codice trapelato del builder Conti 2. Il gruppo è operativamente collegato a threat actor dell’Europa dell’Est e alcuni suoi operatori sarebbero associati al cartello BlackHat/ALPHV. Una caratteristica critica emersa a febbraio 2026 rende il gruppo particolarmente pericoloso per le sue stesse vittime: un bug di programmazione nel modulo di cifratura per VMware ESXi rende il decryptor incapace di recuperare i file cifrati. Secondo i ricercatori di Coveware, pagare il riscatto — in questo specifico scenario — è inutile, poiché nemmeno gli stessi operatori di Nitrogen riescono a decifrare i file. Foxconn avrà quasi certamente verificato questa criticità prima di prendere qualsiasi decisione sui negoziati.

Il bottino: schemi tecnici di Apple, Nvidia, Intel, Google e Dell

I campioni pubblicati da Nitrogen sul data leak site comprendono, secondo le ricostruzioni di più fonti, istruzioni di assemblaggio, diagrammi di data center e schemi hardware relativi a progetti di Apple, Intel, Google, Nvidia e Dell. La natura della documentazione è coerente con l’operatività dello stabilimento di Mount Pleasant, che Foxconn gestisce come Fii USA (Foxconn Industrial Internet) e che produce principalmente server, workstation e componenti per data center — non dispositivi consumer Apple, il che spiega perché Apple abbia dichiarato di non essere direttamente a rischio per quanto riguarda i propri prodotti al consumo.

La vera preoccupazione non è nella divulgazione di schemi per smartphone già in commercio, ma nella potenziale esposizione di roadmap future, specifiche ingegneristiche riservate di infrastrutture cloud e configurazioni di data center enterprise. Per aziende come Nvidia, i cui chip AI sono al centro di una corsa tecnologica globale con implicazioni geopolitiche, la divulgazione di topologie di sistemi e specifiche tecniche costituisce un rischio di intelligence industriale non trascurabile.

Foxconn nel mirino: una vittima seriale

Non si tratta del primo incidente ransomware per il colosso taiwanese. Nel 2022 un gruppo criminale aveva colpito una filiale messicana di Foxconn. Nel 2024 LockBit aveva attaccato Foxsemicon Integrated Technology, società del gruppo nel settore equipment per semiconduttori. La recidività di questi attacchi suggerisce che la superficie di attacco di Foxconn — distribuita tra decine di stabilimenti, migliaia di sistemi IT e una rete supply chain planetaria — sia strutturalmente difficile da proteggere nella sua totalità.

Implicazioni per la supply chain tecnologica

L’attacco a Foxconn rappresenta un caso emblematico di come le grandi aziende di contract manufacturing costituiscano un vettore di rischio sistemico per l’intera industria tecnologica. Un singolo incidente a un fornitore terzo può esporre simultaneamente la proprietà intellettuale di decine di brand globali — anche quando questi brand mantengono standard di sicurezza interni elevatissimi. La documentazione tecnica che fluisce verso i produttori include spesso specifiche pre-commerciali, che diventano bersagli appetibili per attori mossi da interessi sia economici (concorrenza sleale, contraffazione) che geopolitici (intelligence industriale statale).

Vale la pena notare che Nitrogen stessa ha un track record di affidabilità tecnica discutibile: la presenza del bug nel decryptor ESXi lascia aperta la domanda su quanto effettivamente il gruppo sia in grado di “consegnare” quanto promesso in sede di negoziazione. Per Foxconn, questo potrebbe significare che, nel caso in cui parte dei sistemi produttivi fosse stata cifrata con la variante ESXi, i dati potrebbero essere irrecuperabili indipendentemente da qualsiasi trattativa.

Due righe per i difensori: lezioni dall’incidente Foxconn

• Segmentazione di rete per gli ambienti OT/IT: negli stabilimenti manifatturieri, la convergenza tra reti IT e sistemi operativi (OT/ICS) amplifica l’impatto di un’intrusione. Una corretta segmentazione può contenere il blast radius e prevenire interruzioni produttive.
• Hardening degli hypervisor VMware ESXi: Nitrogen e molti altri gruppi ransomware prendono specificamente di mira ESXi. L’applicazione tempestiva delle patch, la disabilitazione di servizi non necessari (SLP, OpenSLP) e il monitoraggio delle API di hypervisor sono controlli prioritari.
• Protezione della documentazione tecnica con DRM o controlli di accesso granulari: schemi, BOM e specifiche ingegneristiche riservate dovrebbero essere soggetti a policy di accesso basate sul principio del minimo privilegio e tracciabilità degli accessi.
• Verifica dei fornitori critici: le aziende che condividono IP con contract manufacturer dovrebbero condurre audit periodici della postura di sicurezza dei propri fornitori e includere clausole di notifica di incidenti nei contratti.
• Valutare la recuperabilità prima del pagamento: in caso di attacco Nitrogen su ambienti ESXi, ricercatori indipendenti hanno confermato che il pagamento non garantisce il recupero. Prioritizzare i backup offline e testare regolarmente i piani di disaster recovery.

Fonti: The Register (12 maggio 2026); CyberNews; The CyberSec Guru

Foxconn Breach: Nitrogen Claims 8TB Theft from Wisconsin AI Plant | The CyberSec Guru

8TB breach hits Foxconn Wisconsin! Nitrogen ransomware group claims 11 million files stolen, including Apple & Google specs

^{The CyberSec Guru}

stefania maurizi

2026-05-13 15:41:38

Io non vorrei parlare male dell'Italia nei media stranieri,ma ho dovuto raccontare la verità: contrariamente alle autorità inglesi ed europee, il ministero dell'interno di Piantedosi si è rifiutato di rispondere su cosa sta negoziando Italia con USA

computerweekly.com/news/366643…

Europe and US negotiate deal to share citizens’ biometric data, UK also approached | Computer Weekly

The UK has received a request from the US to share biometric data of citizens, as Europe negotiates a similar deal with US Department of Homeland Security.

^{Stefania Maurizi (ComputerWeekly.com)}

stefania maurizi

2026-05-13 15:44:56

Una bozza della proposta segreta della #CommissioneEuropea per dare accesso a #ICE ai nostri dati biometrici e genetici è stata ottenuta da @statewatch

A noi negata qualsiasi documentazione nel nome della "protezione delle relazioni internazionali"

computerweekly.com/news/366643…

Europe and US negotiate deal to share citizens’ biometric data, UK also approached | Computer Weekly

The UK has received a request from the US to share biometric data of citizens, as Europe negotiates a similar deal with US Department of Homeland Security.

^{Stefania Maurizi (ComputerWeekly.com)}

(in)sicurezza digitale

2026-05-13 12:56:19

Mythos contro curl: quando l’AI “troppo pericolosa” incontra la realtà del codice

Si parla di:
Toggle

Per settimane il nome “Mythos” è stato costruito come un oggetto quasi mitologico. Anthropic lo ha presentato come un modello AI capace di trovare vulnerabilità zero-day a un livello tale da risultare “troppo pericoloso” per una release pubblica. Una narrativa perfetta per il ciclo mediatico dell’AI security nel 2026: modello segreto, capacità offensive avanzate, accesso ristretto, migliaia di vulnerabilità individuate. Il genere di storytelling che nel mondo cyber si propaga in poche ore tra LinkedIn, Twitter/X, keynote e blog enterprise.

Poi però Mythos è stato testato contro uno dei progetti open source più scrutinati del pianeta: curl. E lì il racconto ha iniziato a incrinarsi.

Un software scritto come si deve

A raccontarlo è stato direttamente Daniel Stenberg, storico maintainer di curl e figura ormai centrale nel dibattito sulla collisione tra AI e vulnerability research. Nel suo lungo post pubblicato sul blog personale, Stenberg descrive il risultato dell’analisi effettuata con Mythos sul repository di curl: cinque vulnerabilità segnalate come “confirmed security vulnerabilities”. Dopo il triage umano del team sicurezza di curl, il bilancio finale si è ridotto a una sola vulnerabilità reale, classificata a bassa severità, tre falsi positivi e un semplice bug non-security. (daniel.haxx.se)

Ed è qui che il tema diventa interessante, perché il punto non è tanto “Mythos non funziona”. Anzi. Stenberg stesso riconosce che il report contiene analisi tecniche solide e bug descritti bene, con un numero relativamente basso di falsi positivi rispetto alla media degli scanner AI attuali. Il problema è un altro: il gap enorme tra la narrativa costruita attorno al modello e i risultati concreti osservabili sul campo.

La frase più pesante dell’intero post è probabilmente questa:

“the big hype around this model so far was primarily marketing”

Un software largamente usato

Una dichiarazione che arriva non da un opinionista qualsiasi, ma da uno dei maintainer open source più esposti al fenomeno AI-assisted vulnerability hunting. Negli ultimi mesi Stenberg ha documentato pubblicamente l’esplosione di report generati da AI, il collasso qualitativo di molti bug bounty submission e il nuovo scenario che lui stesso definisce “high-quality chaos”.

Il contesto infatti è fondamentale. curl non è un target qualunque. È software vecchio di decenni, onnipresente, analizzato continuamente da ricercatori, aziende, fuzzing infrastructure, static analyzer, LLM e offensive security team. Il progetto ha già attraversato una vera ondata di AI-powered auditing nel 2025 e 2026, con centinaia di issue segnalate e decine di CVE pubblicate.

In altre parole: Mythos non stava entrando in un territorio inesplorato. Stava arrivando su un codice già passato attraverso un livello di scrutiny estremo.

Ed è qui che la promessa implicita di Anthropic sembra perdere consistenza. Se un modello viene presentato quasi come una svolta paradigmatica nella vulnerability discovery offensiva, ci si aspetta almeno un salto qualitativo evidente rispetto agli strumenti precedenti. Non necessariamente centinaia di 0-day critici, ma almeno pattern nuovi, classi di bug differenti, chaining più sofisticati o insight architetturali difficili da intercettare con gli attuali sistemi AI-assisted SAST.

Secondo Stenberg, questo salto non si è visto.

Anzi, il maintainer di curl arriva a sostenere che altri strumenti AI usati in precedenza avevano già prodotto quantità maggiori di bugfix. Mythos forse è “leggermente migliore”, scrive, ma non abbastanza da cambiare realmente il paradigma della code analysis.

Questa distinzione è cruciale perché separa due fenomeni che oggi vengono continuamente confusi nel marketing AI security.

Il primo fenomeno è reale: i moderni LLM stanno diventando estremamente efficaci nell’analisi del codice. Stenberg lo dice chiaramente. Gli strumenti AI contemporanei trovano vulnerabilità meglio dei tradizionali static analyzer. La differenza rispetto a cinque anni fa è concreta e misurabile.

Il secondo fenomeno invece è narrativo: trasformare questo miglioramento incrementale in una retorica quasi apocalittica, dove ogni nuovo modello viene descritto come un cyber-weapon rivoluzionario capace di destabilizzare l’intero ecosistema software.

Ed è proprio questa seconda parte che il caso Mythos sembra mettere in discussione.

L’hype dell’AI ormai incontrollabile

Perché il rischio, nel settore cybersecurity, è che l’hype finisca per sostituire il metodo. La comunicazione attorno a Mythos ha funzionato perfettamente: accesso ristretto, dichiarazioni sulla pericolosità del modello, riferimenti a migliaia di zero-day trovati internamente, programma limitato a poche organizzazioni strategiche. Tutti elementi che costruiscono scarsità, percezione di superiorità tecnologica e senso di urgenza.

Ma quando il modello viene finalmente osservato in un caso reale e pubblico, il risultato appare molto più ordinario: un buon AI-assisted code analyzer che trova un low severity issue in un progetto maturissimo e già massacrato da anni di auditing.

Non è poco. Ma non è nemmeno la rivoluzione promessa.

La parte forse più interessante dell’intera vicenda è che Stenberg non assume una posizione anti-AI. Al contrario. La sua analisi è molto più sofisticata della solita polarizzazione “AI sì / AI no”. Lui riconosce apertamente che gli LLM stanno cambiando il vulnerability research landscape. Il problema, semmai, è che il settore sta sovrastimando la distanza tra i nuovi modelli “frontier” e ciò che gli strumenti AI moderni già fanno oggi.

Ed è una riflessione che nel mondo offensive security merita attenzione.

Perché se Mythos — il modello presentato come troppo pericoloso per essere rilasciato — produce risultati sostanzialmente comparabili agli strumenti già esistenti, allora forse la vera trasformazione non è l’arrivo di un singolo modello “superiore”, ma la democratizzazione progressiva dell’AI-assisted vulnerability discovery.

Una differenza enorme.

Nel primo scenario, il vantaggio resta concentrato nelle mani di pochi laboratori frontier AI. Nel secondo, invece, la capacità offensiva si distribuisce rapidamente: più ricercatori, più scanner, più auditing, più rumore, più CVE, più triage umano necessario.

Ed è esattamente il futuro che Stenberg sembra vedere arrivare: non una singola AI onnipotente, ma un ecosistema saturo di agenti capaci di produrre contemporaneamente valore tecnico reale e quantità industriali di “security slop”.

Un mondo dove il problema non è più trovare vulnerabilità. È distinguere quelle importanti dal resto.

Day: May 11, 2026

curl, open source and networking

^{daniel.haxx.se}