Sicurezza AI

Sicurezza dell'IA: i file che nessuno controlla sono ora la vostra più grande superficie di attacco.

Un file di competenze. Un file di regole. Una configurazione del server MCP. Tre righe di testo semplice, commitSono strutturati come documentazione, revisionati come documentazione, e nessuno di essi sembra codice. Eppure ognuno di essi può silenziosamente riscrivere ciò che il tuo assistente IA è incaricato di fare e a cosa è autorizzato ad accedere. Questa è la scomoda verità che si cela dietro la sicurezza dell'IA. in 2026Per due anni, il settore si è preoccupato del contenuto del codice generato dall'IA. Il problema più complesso si è rivelato essere la catena di fornitura dell'IA stessa: i modelli, gli agenti, i server MCP e i file di configurazione che ora si trovano accanto al codice sorgente e alle dipendenze open source, in gran parte non inventariati e non sottoposti a revisione. È proprio per questo che la sicurezza della catena di fornitura dell'IA è diventata una disciplina a sé stante, ed è per questo che scegliere la giusta azienda di sicurezza per l'IA è importante quanto scegliere lo scanner giusto.

La superficie di attacco per cui nessuno aveva previsto un budget

Il software in passato aveva una manciata di posti in cui un attaccante poteva atterrare: il codice, le dipendenze, il pipeline.L'IA ne ha aggiunti altri due, ed entrambi alimentano direttamente la catena di fornitura dell'IA.

La modella e l'agente. Avvelenamento degli strumenti, iniezione di prompt, autonomia dell'agente che va oltre ogni intenzione. Un'istruzione nascosta nella descrizione di un server MCP può reindirizzare silenziosamente le azioni di un copilota, e lo sviluppatore non se ne accorge mai.

L'ambiente di sviluppo personale. IDE, copiloti AI, server MCP, CLI degli agenti. Invisibili agli scanner AppSec legacy, che non sanno cosa sia un modello, e invisibili agli EDR, che monitorano il sistema operativo e non hanno idea di cosa sia una dipendenza o una chiamata MCP.

Niente di tutto ciò è teorico. Negli ultimi diciotto mesi:

  • Una "backdoor" nascosta nel file delle regole Unicode permetteva agli aggressori di iniettare istruzioni invisibili nei file di configurazione letti da Copilot e Cursor, inserendo silenziosamente una backdoor nel codice generato dall'assistente. GitHub ha aggiunto un avviso a riguardo nel 2025.
  • Una vulnerabilità di command injection in un popolare bridge MCP (CVSS 9.6) ha raggiunto oltre 400,000 download prima di essere corretta, rappresentando il primo caso documentato di esecuzione completa di codice remoto attivata semplicemente connettendosi a un server MCP non attendibile.
  • Un worm npm auto-propagante ha trasformato gli sviluppatori stessi nel meccanismo di distribuzione, e lo schema si è ripetuto su larga scala nei mesi successivi in ​​altri ecosistemi, un classico esempio di fallimento della sicurezza della catena di fornitura dell'IA.
  • I ricercatori hanno scoperto che una parte significativa dei pacchetti consigliati dai modelli LLM non esiste affatto: si tratta di nomi "slopsquatted" che un malintenzionato registra prima ancora che un vero sviluppatore chieda al modello di importarli.

La ricerca condotta da Google sulla sicurezza della catena di fornitura del software di intelligenza artificiale giunge a una conclusione simile, ma da una prospettiva diversa: i modelli che circolavano nel 2023 e nel 2024 sembravano legittimi, pur contenendo codice in grado di esfiltrare dati o installare backdoor una volta scaricato. La soluzione non consisteva tanto in una nuova categoria di strumenti, quanto nell'applicazione di una disciplina rigorosa alla catena di fornitura, come la tracciabilità e la firma digitale, ad artefatti che nessuno aveva mai monitorato prima. Questo, in sintesi, è il problema della sicurezza della catena di fornitura dell'IA: gli artefatti sono nuovi, ma la disciplina necessaria non lo è.

Perché i tuoi strumenti attuali non sono sufficienti

SAST legge il codice. SCA Legge un manifesto delle dipendenze. Nessuno dei due sa cosa sia un modello, cosa esponga un server MCP o cosa un file di skill indichi a un agente di fare. È proprio in questo divario che si annidano gli attacchi dell'era dell'IA, nello spazio tra "il codice che analizziamo" e "l'IA che abbiamo adottato silenziosamente".

Il risultato è una categoria di IA ombra no CISAttualmente non posso rispondere a domande come: quali modelli stiamo eseguendo, quali agenti possono accedere a cosa e a quale server MCP qualcuno si è connesso martedì scorso senza avvisare nessuno. Rispondere bene a queste domande è compito della sicurezza della catena di fornitura dell'IA, ed è il motivo per cui gli strumenti generici di AppSec continuano a risultare inadeguati in questo ambito.

Cosa significa realmente la sicurezza dell'IA

Xygeni è l'azienda di sicurezza AI che tratta questo come tre movimenti collegati attraverso il SDLC: scoprire, individuare e far rispettare.

Scopri: scopri quale intelligenza artificiale possiedi realmente

La scoperta continua e automatica nei tuoi repository mette in evidenza ogni risorsa AI: modelli, framework, set di dati, endpoint di inferenza, agenti, server MCP, competenze, prompt, guardrailse gli strumenti di programmazione AI che i tuoi sviluppatori stanno effettivamente utilizzando. Nessun sondaggio. Nessuna autodenuncia. Se ha lasciato una traccia in un repository, compare nell'inventario, il primo e più basilare requisito di una vera sicurezza della catena di fornitura AI.

Il grafico basato sull'intelligenza artificiale mostra quindi come queste risorse sono connesse: quale modello alimenta un set di dati, quale agente richiama quale strumento, quale server MCP si trova dietro a quale assistente. Una risorsa isolata fornisce poche informazioni. Il grafico mostra dove si concentra il rischio.

Da quella stessa scoperta, Xygeni genera un AI-BOMUn inventario completo e leggibile automaticamente, pronto per la verifica, di tutto ciò che riguarda l'IA nel tuo software. Quando un ente regolatore, un revisore o un cliente ti chiede quale IA stai utilizzando, la risposta diventa un semplice download anziché una corsa contro il tempo di tre settimane.

Individua: i rischi che gli scanner convenzionali non riescono a rilevare

Uno scanner AI dedicato cerca le modalità di errore specifiche dei sistemi AI: iniezione di prompt, iniezione di strumenti e invocazione di strumenti non attendibili, perdita di dati tramite recupero, bypass del prompt di sistema, agenzia eccessiva. Ogni scoperta mappa al OWASP Top 10 per le domande di LLM e indica il file e la riga esatti che causano l'esposizione, non un vago avviso del tipo "rivedi il tuo utilizzo dell'IA".

Lo stesso livello di rilevamento tratta i file delle competenze, i file delle regole e le configurazioni MCP come artefatti di sicurezza quali sono, e non come innocua documentazione. Segnala le competenze dannose o compromesse, ispeziona le configurazioni del server MCP per individuare eventuali compromissioni degli strumenti e mette in evidenza i prompt che effettivamente guidano i carichi di lavoro dell'IA.

Dare priorità: l'imbuto che elimina il rumore, non gli angoli

Ogni vulnerabilità viene filtrata progressivamente: prima quella accessibile nel codice dell'applicazione, poi quella effettivamente sfruttabile e infine quella presente nel codice che il team sta sviluppando attivamente. La lista ristretta di vulnerabilità che giungono alla coda di sviluppo è quella che rappresenta una reale minaccia per l'ambiente di produzione, corredata dal riferimento al framework, dalla finestra di esposizione e dalle linee guida per la mitigazione.

Imponi: fermalo prima che si avvii

Shield porta l'applicazione delle policy all'endpoint dello sviluppatore stesso: blocca installazioni non autorizzate e dannose, modelli non approvati e server MCP non sanzionati prima che qualsiasi cosa venga eseguita. Sotto di esso si trova Xygeni Allerta precoce sul malware (MEW), che intercetta i pacchetti dannosi prima che esista una firma, lo strato di cui gli strumenti basati sulla reputazione si fidano ancora perché nessuno ha ancora segnalato il pacchetto. È la metà di applicazione della sicurezza della catena di approvvigionamento dell'IA: la scoperta e il rilevamento ti dicono cosa c'è che non va, Shield è ciò che effettivamente lo ferma.

La tua esposizione all'IA non si limita al codice della tua IA

Per avere un quadro completo della sicurezza della catena di approvvigionamento dell'IA, non basta un semplice inventario di modelli, e raramente si tratta solo degli aspetti più appariscenti:

  • credenziali del fornitore di IA lasciato nei file di prompt, nelle configurazioni dell'agente o pipeline I registri sono segreti come tutti gli altri, e il sistema di rilevamento dei segreti di Xygeni li intercetta prima che raggiungano un registro pubblico.
  • Dipendenze vulnerabili da IA ​​e apprendimento automatico contengono CVE ordinarie, rilevate dalla stessa analisi della composizione del software che già copre il resto del tuo stack. Ricerche di terze parti sull'adozione dell'IA hanno evidenziato quanto del moderno stack di IA sia costituito da pacchetti di provenienza esterna e componenti nascosti, che è esattamente la superficie che l'analisi della composizione del software è stata progettata per coprire.
  • Pacchetti dannosi pubblicato più velocemente di qualsiasi avviso pipeline è possibile catalogarli se vengono intercettati prima della firma, la stessa funzionalità MEW che protegge il resto della catena di fornitura.

Il livello agentivo: DevAI e CoreAI

La scoperta e il rilevamento riguardano ciò che è già presente nei tuoi repository. DeviAI Funziona dove si crea il rischio: all'interno dell'IDE, come un livello continuo e proattivo che analizza il codice generato da esseri umani e IA durante la scrittura, senza bisogno di interventi manuali. Spiega l'intero percorso di sfruttamento di una vulnerabilità e propone soluzioni validate da MCP che uno sviluppatore può applicare con sicurezza, senza interrompere la build.

CoreAI si posiziona sopra gli scanner individuali come livello di intelligenza: correla codice, dipendenza, pipelinee integra i dati relativi alla postura in un unico modello di rischio, risponde alle domande in linguaggio naturale e produce i report pronti per la dirigenza di cui un responsabile della sicurezza ha bisogno per dimostrare che la governance è effettivamente in atto e non solo dichiarata.

Estendi ciò che hai in materia di sicurezza AI. Non eliminare nulla.

L'obiezione più comune a una nuova categoria di sicurezza è "abbiamo già abbastanza strumenti". In quanto azienda di sicurezza basata sull'IA, Xygeni non ti chiede di sostituire nulla: lo stesso processo di triage, spiegazione e prioritizzazione applicato ai propri risultati funziona allo stesso modo anche per i risultati provenienti dai tuoi strumenti esistenti. SAST, SCAe scanner di terze parti. Il tuo stack attuale diventa un input, non una vittima, e la postura di sicurezza della tua catena di fornitura di IA migliora senza un progetto di sostituzione completa.

Perché questo è importante ora e non dopo.

Gli enti regolatori stanno convergendo sulla stessa aspettativa, pur provenendo da direzioni diverse: l'AI Act dell'UE, il NIS2 e l'ENS spagnolo spingono tutti verso l'inventario e la tracciabilità dei sistemi di intelligenza artificiale, ovvero le stesse prove che una distinta base per l'IA (AI-BOM) è progettata per produrre. La direzione è chiara, anche laddove i meccanismi di conformità esatti sono ancora in fase di definizione: non si può certificare un'IA che non è mai stata inventariata, e non si può affermare la sicurezza della catena di fornitura dell'IA se la catena di fornitura stessa è invisibile.

Scegliere un'azienda di sicurezza basata sull'intelligenza artificiale

Non tutte le aziende di sicurezza per l'IA definiscono i propri limiti allo stesso modo. Alcune si fermano alla scansione del codice generato dall'IA stessa, altre si fermano all'endpoint. La questione della sicurezza della catena di fornitura dell'IA è più ampia di quanto si possa immaginare: coinvolge il modello, l'agente, il server MCP, il file delle skill e le normali dipendenze sottostanti. Questa visione completa del ciclo di vita, dalla scoperta all'applicazione delle misure di sicurezza, disponibile in un'unica console insieme a tutti gli altri risultati della sicurezza delle applicazioni, è ciò che bisogna cercare quando si valuta un'azienda di sicurezza per l'IA, piuttosto che un singolo strumento.

I file che nessuno controlla sono diventati la porta d'accesso. La sicurezza dell'IA è la disciplina che si occupa di esaminarli, e la sicurezza della catena di fornitura basata sull'IA è ciò che garantisce la validità di tale disciplina dall'inizio alla fine, sulla stessa piattaforma in cui si controlla già tutto il resto.

Scopri cosa è effettivamente consentito fare alla tua intelligenza artificiale. Inizia gratis or programma una demo.

FAQ

Il codice di Xygeni esce mai dalla mia infrastruttura?
No. Le scansioni vengono eseguite all'interno del tuo ambiente e il codice sorgente non viene mai caricato sui server di Xygeni. L'inventario AI e la distinta base AI vengono creati a partire da ciò che lo scanner rileva localmente, non da una copia inviata esternamente.

Qual è la differenza tra AI Security, DevAI e CoreAI?
AI Security scopre e rileva: crea l'inventario AI, l'AI-BOM, e individua rischi come l'iniezione di prompt o i file di competenze infetti. DevAI opera all'interno dell'IDE mentre gli sviluppatori scrivono il codice, proponendo soluzioni in tempo reale. CoreAI si posiziona al di sopra di entrambi, correlando i risultati su tutta la piattaforma e rispondendo a domande sulla postura di sicurezza in linguaggio naturale.

A quali framework di sicurezza per l'IA si allinea Xygeni?
I risultati corrispondono alla OWASP Top 10 per le applicazioni LLM, alla OWASP Top 10 per MCP e alla OWASP Top 10 per le competenze agentiche, insieme a NIST SP 800-218A e CISLinee guida A/G7 sulle distinte base per l'IA. Questa mappatura è ciò che rende la distinta base per l'IA utilizzabile come prova di conformità, anziché come semplice inventario.

Questo segnalerà ogni libreria o modello di intelligenza artificiale come a rischio?
No. Il processo di prioritizzazione restringe i risultati a ciò che è accessibile nel codice dell'applicazione, effettivamente sfruttabile e in fase di sviluppo attivo, quindi l'elenco visualizzato dallo sviluppatore è breve e non una semplice raccolta di tutte le risorse di IA rilevate.

sca-tools-software-strumenti-di-analisi-della-composizione
Dai priorità, risolvi e proteggi i rischi del tuo software
Crea il tuo account gratuito.
Nessuna carta di credito richiesta.

Proteggi lo sviluppo e la consegna del tuo software

con la suite di prodotti Xygeni