Negli ultimi anni, la sicurezza delle applicazioni ha avuto un confine chiaro: il repository e il pipelineLì si trovavano i controlli, dove venivano eseguite le scansioni, dove i team decidevano se un elemento dovesse essere rilasciato in produzione. Tutto si basava su un presupposto: lo sviluppatore sceglieva esplicitamente quale codice e quali dipendenze entrassero nel sistema.
Questa ipotesi non è più valida. Una quota crescente di codice oggi viene scritta, suggerita o installata da un agente di intelligenza artificiale, spesso senza che nessuno guardi il nome di ciò che viene scaricato. Quando il decisMan mano che il codice entra in gioco, si sposta anche l'attacco. Si sposta all'inizio del processo: nel momento in cui il codice viene creato, all'interno dell'assistente stesso e nei file che lo configurano.
Questa è la superficie di attacco della tua IA: ogni modello, agente, server MCP, skill e dipendenza suggerita dall'IA che ora può introdurre un rischio prima ancora che un essere umano lo esamini. La stessa IA di cui si fidano i tuoi sviluppatori ora ne fa parte. Non si tratta di un rischio futuro. È un cambiamento che è già avvenuto, ed ecco come si manifesta nella pratica.
Un'ondata di attacchi, non un episodio isolato.
Nessuno dei seguenti è un esperimento di laboratoriocise o un'ipotesi. Si tratta di incidenti pubblici e documentati, quasi tutti risalenti all'ultimo anno, e ognuno di essi ci avvicina un po' di più all'agente di intelligenza artificiale stesso:
- Agosto 2025, s1ngularity: Gli hacker hanno rubato un token di pubblicazione da Nx, uno dei sistemi di build più diffusi, e hanno pubblicato versioni dannose su npm, utilizzando strumenti di intelligenza artificiale per individuare informazioni riservate sui computer degli sviluppatori.
- Settembre 2025, chalk/debug: Uno dei più grandi casi di violazione della sicurezza di npm in termini di portata: 18 pacchetti con oltre due miliardi di download settimanali, compromessi tramite il dirottamento dell'account di un singolo manutentore.
- Settembre 2025, Shai-Hulud: Uno dei primi worm documentati in grado di auto-propagarsi tramite npm. La sua seconda ondata, a novembre, è stata più aggressiva e legata a segreti esposti in oltre 25,000 repository.
- Ottobre 2025, importazioni non utilizzate: Parte della campagna PhantomRaven, in cui un'allucinazione basata sull'IA ha introdotto malware reale in npm tramite una tecnica di slopsquatting.
- Quest'anno, ClawHub: un registro di competenze di intelligenza artificiale contaminato, in cui cinque delle sette competenze più scaricate erano malware.
Il settore sta formalizzando la stessa conclusione. La OWASP Top 10 per le applicazioni LLM colloca l'iniezione immediata al primo posto. La OWASP MCP Top 10 (attualmente in versione beta) prende di mira il protocollo utilizzato dagli agenti per comunicare con gli strumenti. La OWASP Agentic Skills Top 10, un nuovo progetto in fase di incubazione, identifica le competenze dannose come il rischio principale. OWASP di solito procede con cautela; aprire tre fronti contemporaneamente, uno dei quali con urgenza, la dice lunga sulla rapidità con cui si sta evolvendo la situazione.
Tutti e tre convergono sulla stessa idea: le istruzioni, gli strumenti e le configurazioni relativi a un modello fanno ora parte della superficie di attacco dell'IA e di solito risiedono all'interno del vostro repository. Il che solleva la prima domanda da porre ai vostri team: chi esamina i file delle regole, le skill e le configurazioni MCP che si trovano nel vostro repository?
Vettore 1: l'abilità avvelenata
Una skill è un file di istruzioni e capacità che insegna a un agente IA come eseguire un compito. Non è l'unico modo per modellare il comportamento di un agente (file di regole, hooks(e le configurazioni MCP fanno lo stesso), ma tutte condividono una proprietà: viaggiano all'interno del repository, insieme al codice.
La ricerca di quest'anno ha esaminato 4,000 di queste competenze:
- Il 36% presentava almeno una falla di sicurezza.
- Il 13.4% ha espresso pareri critici.
- Quasi 100 contenevano payload dannosi fin dall'inizio.
Il cambiamento fondamentale: l'attaccante non prende più di mira il tuo codice. Prende di mira l'agente che scrive il tuo codice, inserendo istruzioni nascoste (a volte usando caratteri invisibili) che il modello legge e tratta come operative. Un revisore umano approva il pull request in buona fede perché, ai loro occhi, il file sembra pulito. Il modello interpreta istruzioni che il revisore non ha mai visto.
Non si tratta di una questione teorica. La vulnerabilità CVE-2025-59536 (CVSS 8.7) consentiva l'avvio di Claude Code da un repository non attendibile, dove una configurazione dannosa poteva eseguire comandi prima che l'utente accettasse la richiesta di autorizzazione. Una seconda vulnerabilità, CVE-2026-21852, permetteva l'esfiltrazione di una chiave API tramite una configurazione controllata dal progetto, senza l'approvazione dell'utente.
H2: Vettore 2: slopsquatting
Il nome fonde "slop" (la spazzatura che a volte un'IA genera) con il classico attacco di typosquatting. Il typosquatting si basa sull'errore umano: un attaccante registra un nome di pacchetto simile a uno comune e aspetta un errore di battitura. È casuale.
Slopsquatting non aspetta un errore. Nello studio citato durante questa sessione, Il 19.7% dei riferimenti ai pacchetti generati dai modelli di intelligenza artificiale puntava a pacchetti inesistenti. I modelli tendono a generare ripetutamente gli stessi nomi, quindi un attaccante osserva quali nomi inventa l'IA, li registra con codice dannoso e attende la successiva installazione suggerita dall'IA per integrarla nella tua applicazione.
La portata non è trascurabile: Nel 2025 sono stati identificati oltre 450,000 nuovi pacchetti dannosi. Due esempi lo rendono concreto:
- Un ricercatore ha installato un pacchetto di test innocuo chiamato abbracciandoface-cli per dimostrare il punto. Ha registrato Oltre 30,000 download in tre mesi.
- importazioni inutilizzateCome si evince dalla cronologia sopra riportata, si trattava di un malware confermato, attivo in un registro pubblico, che utilizzava esattamente questa tecnica. Non si trattava di un test.
La questione non è se questo possa accadere al tuo team, ma quanti pacchetti suggeriti dall'IA entrano oggi nel tuo codice senza che nessuno li esamini.
La risposta: standardstanno recuperando
Due forze corrono in parallelo. Mentre gli attacchi accelerano, standardI corpi stanno reagendo:
- NISTSP800-218A Estende il framework di sviluppo software sicuro con pratiche specifiche per i modelli di intelligenza artificiale, tra cui la verifica dell'integrità e della provenienza.
- In Può 2026, CISA e i suoi partner internazionali del G7 ha pubblicato delle linee guida su una distinta base software per l'IA, definendo cosa deve essere incluso in tale inventario: modelli, set di dati, componenti, fornitori e dipendenze.
La direzione è chiara: il SBOM si sta espandendo in una distinta base basata sull'intelligenza artificiale (AI-BOM). Non si può certificare o attestare ciò che non si può inventariare. E oggi, la maggior parte delle organizzazioni non può farlo:
- 43% Non è possibile verificare o inventariare gli strumenti di intelligenza artificiale che stanno già utilizzando.
- 79% Non hanno visibilità sugli agenti di intelligenza artificiale e sui sistemi MCP in esecuzione nel loro ambiente.
Negli ambienti regolamentati, questo inventario sta passando da buona prassi a requisito contrattuale o obbligo di conformità. Ma un inventario indica solo ciò che si possiede. Di per sé, non impedisce un attacco.
Il divario: un EDR per la sicurezza delle applicazioni
SAST and SCA Gli strumenti sono progettati per analizzare il codice e le dipendenze, non il comportamento di un agente o la sua configurazione. EDR Questo strumento rileva processi e connessioni di rete, ma in genere non possiede il contesto di sicurezza applicativa necessario per interpretare una dipendenza o la configurazione di un agente. Tra queste due categorie di strumenti si trova un divario, proprio dove viene attualmente creato il codice e dove risiede la superficie di attacco dell'IA.
Questa lacuna presenta tre punti ciechi:
- Risorse di intelligenza artificiale. Modelli, agenti e server MCP non vengono visualizzati sul tuo SASTo SCAIl radar. Non puoi inventariare ciò che non puoi vedere.
- File di configurazione. Abilità, regole e configurazioni MCP modellano il comportamento dell'agente, ma in genere vengono esaminate come se fossero semplici testi innocui.
- Installazione del pacchetto. A Una dipendenza dannosa può essere eseguita prima che se ne riconosca la natura dannosa., quindi esfiltrare segreti e token senza l'approvazione di nessuno.
Come Xygeni lo chiude
Cosa fa un EDR per gli endpoint, Xygeni Shield è pensato per il ciclo di vita dello sviluppo assistito dall'IA: protegge l'ambiente in cui viene creato il codice, comprendendo al contempo il contesto di sicurezza dell'applicazione.
- Visibilità dove SAST and SCA non raggiungere. Xygeni segnala competenze e file di regole dannosi, analizza le configurazioni MCP e crea un file pronto per l'audit AI-BOM, mappati sulle Top 10 delle competenze OWASP LLM, MCP e Agentic.
- Intelligenza, non solo firme. MEW (Malware Early Warning) analizza il comportamento e il rischio di un pacchetto per bloccarlo prima che venga rilasciato un CVE, un avviso o una firma pubblica. L'intelligence di rete aggiornata interrompe le connessioni a infrastrutture notoriamente dannose.
- Un unico punto di controllo, dal codice al risultato finale. Un singolo agente, implementato senza riprogettare l'ambiente, con sovranità dei dati europea e prove di conformità integrate.
In una dimostrazione dal vivo, questa policy di applicazione ha bloccato il tentativo di un agente AI di installare un pacchetto dannoso attraverso tre diversi percorsi di installazione (ambiente virtuale, gestore di pacchetti e download diretto) prima del completamento dell'installazione, il tutto registrato in tempo reale ed esportabile a un SOC. L'implementazione di un primo progetto richiede in genere circa un'ora; estendere la copertura a un'intera organizzazione richiede solitamente da una a due settimane, a seconda della struttura.
FAQ
Qual è la superficie di attacco dell'IA in un paragrafo?
La superficie di attacco dell'IA è l'insieme di modelli, agenti, server MCP, competenze, file di regole e dipendenze suggerite dall'IA attraverso i quali il rischio può entrare in un'applicazione, spesso prima che venga esaminata da un essere umano. Si estende oltre il codice e le dipendenze tradizionali per includere i file di configurazione e le istruzioni che definiscono il comportamento di un agente di IA.
Come posso capire se il nome di un pacchetto suggerito dal mio assistente IA è un'allucinazione o semplicemente un nome legittimo ma sconosciuto?
Convalida prima dell'installazione: controlla il registro di sistema e analizza il contenuto e lo scopo effettivi del pacchetto, anziché fidarti solo del nome. Xygeni automatizza questa convalida in tempo reale durante la generazione del codice, in modo che l'installazione venga approvata o bloccata prima dell'esecuzione, indipendentemente dal fatto che il pacchetto sia riconosciuto o meno.
L'occupazione abusiva di terreni influisce allo stesso modo su tutti i modelli di intelligenza artificiale?
La ricerca alla base della cifra del 19.7% ha analizzato diversi modelli e ha riscontrato che il problema è ampiamente diffuso, con solo piccole variazioni tra di essi. Si tratta di uno schema ricorrente nello sviluppo assistito dall'IA, non di un difetto specifico di un singolo assistente.
Possiamo verificare a posteriori se abbiamo già installato un pacchetto inesistente o dannoso?
Sì. La piattaforma di Xygeni offre ai clienti l'accesso a un database aggiornato di pacchetti dannosi rilevati, ricercabile in base all'inventario dei componenti esistenti, in modo da poter verificare in pochi clic se un elemento già installato rappresenta una minaccia nota.
Quanto tempo richiede l'implementazione per un'organizzazione di medie dimensioni con più team?
L'avvio di un primo progetto richiede in genere circa un'ora. L'estensione a un'intera organizzazione richiede solitamente da una a due settimane, a seconda della struttura del team e delle modalità di lavoro.
Mappa la tua superficie di attacco all'IA, gratuitamente.
Mappa gratuitamente l'impronta di IA della tua applicazione: crea un account e avvia la prima scansione in pochi minutiInizia con una singola applicazione, analizza quale intelligenza artificiale è presente al suo interno e individua quale parte della superficie di attacco dell'IA risulta vulnerabile.
*Alcune funzionalità menzionate sopra sono applicate tramite Xygeni Shield e il ASPMModuli di sicurezza AI; la disponibilità può variare a seconda del piano. Vedi xygeni.io per i dettagli aggiornati del prodotto.
