Què és l'enverinament de dades?

Tots els equips de seguretat estan formats per observar el codi a mesura que s'envia. Gairebé cap està format per observar les dades a mesura que arriben, i aquest punt cec és exactament el que explota la intoxicació de dades. Quan un model enverinat arriba a la producció, la vulnerabilitat mai no era a la revisió del codi. Era en un conjunt de dades que ningú havia auditat mesos abans.

Aquesta entrada del glossari explica què és la intoxicació de dades, com es desenvolupen els atacs d'intoxicació de dades a la pràctica, per què la intoxicació de dades per IA s'ha convertit en una de les els riscos de més ràpid creixement a l'era de la IA SDLC, i quina és la veritable defensa contra això.

Significat de la intoxicació de dades #

La intoxicació per dades és la manipulació deliberada de les dades utilitzades per entrenar, ajustar o fonamentar un model d'IA, de manera que el model aprengui alguna cosa incorrecta, es comporti de la manera que l'atacant vol o filtri informació que mai hauria d'exposar. En lloc d'atacar el model després del desplegament, un atacant ataca la matèria primera amb què es construeix el model.

La idea central darrere de la intoxicació de dades és simple i inquietant: un model d'IA només és tan fiable com les dades de les quals ha après. Si aquestes dades estan corruptes, esbiaixades o són una trampa abans que comenci l'entrenament, cap quantitat de revisió de codi, proves o monitorització en temps d'execució posterior detectarà la falla subjacent, perquè el model funciona exactament com se li va ensenyar (maliciosament).

Enverinament de dades per IA vs. vulnerabilitats de programari tradicional #

La seguretat tradicional de les aplicacions assumeix que el perill rau en el codi: una funció incorrecta, una biblioteca sense pegats, un servidor mal configurat. La intoxicació de dades per IA trenca completament aquesta suposició. No hi ha cap línia de codi vulnerable per trobar, perquè la corrupció es va produir en un conjunt d'entrenament, un conjunt de dades d'ajustament fi o un índex de recuperació molt abans que s'escrivís cap codi o es desplegués cap model.

És per això que la intoxicació de dades per IA és excepcionalment difícil de detectar amb eines antigues. SAST l'escàner llegeix el codi. Un escàner de dependències llegeix els manifestos de paquets. Cap dels dos llegeix un corpus d'entrenament de diversos gigabytes ni una base de dades vectorial plena de documents incrustats, que és precisés on l'enverinament de dades per IA fa mal. Investigadors de seguretat i divulgació responsable. D'altres són trobats i convertits en armes pels atacants primer, que és l'escenari que causa més danys.

Com funcionen realment els atacs d'enverinament de dades? #

Els atacs d'enverinament de dades generalment prenen una de les diverses formes:

• Enverinament de dades d'entrenament: un atacant insereix exemples manipulats, mal etiquetats o maliciosos al conjunt de dades utilitzat per entrenar un model des de zero o ajustar-ne un d'existent, fent que aprengui un biaix ocult o un comportament de porta del darrere.
• Inversió d'etiquetes: una versió més subtil de l'anterior, on un atacant només canvia les etiquetes d'un petit subconjunt d'exemples d'entrenament, distorsionant silenciosament allò que el model aprèn a associar amb què.
• RAG i enverinament de contextEn els sistemes de generació augmentada per recuperació, un atacant introdueix documents enverinats a la base de coneixement o al magatzem vectorial que el model recupera en temps d'execució, de manera que el model repeteix amb confiança informació falsa o manipulada com si fos un fet verificat.
• Desencadenants de la porta del darrere: un atacant incrusta un patró específic a les dades d'entrenament de manera que el model es comporta normalment en gairebé tots els casos, però produeix una sortida escollida per l'atacant en el moment en què apareix una frase o entrada de desencadenant oculta.
• Intoxicació de la cadena de subministrament: un atacant compromet un conjunt de dades públic o compartit, un punt de control del model preentrenat o una incrustació pipeline aigües amunt, de manera que cada equip aigües avall que en tregui profit hereta el verí sense tocar mai l'atac original.

El que uneix tots aquests atacs d'enverinament de dades és el temps. El dany es produeix abans que el model respongui a un usuari real, i és precisament per això que la frase "abans que escrigui una línia de codi" descriu aquesta amenaça tan prèviament.cisely: el model està compromès en la seva base, no en el seu resultat.

Com corrompen els atacants un model d'IA abans que escrigui ni una línia de codi? #

Tots els atacs d'enverinament de dades descrits anteriorment comparteixen el mateix avantatge de temps: el compromís es produeix aigües amunt, molt abans que un model generi una sola sortida que l'usuari vegi mai. No hi ha cap funció vulnerable a pegats ni cap aplicació maliciosa. commit per captar en revisió, perquè el model encara no ha escrit res. Només ha après, i el que ha après ja és incorrecte.

Això és el que fa que l'enverinament de dades per IA sigui fonamentalment diferent de les vulnerabilitats que els equips de seguretat de les aplicacions estan entrenats per caçar. Un model amb porta enrere sembla idèntic a un de net en una diferència de codi. Passa un pull request revisió. Compila, implementa i respon correctament a la majoria de consultes, fins que la condició específica que un atacant ha plantat finalment apareix en producció. Aleshores, la pregunta ja no és "quin codi va introduir això", sinó "quines dades van fer i fins a quin punt recorren el temps".

Per què la intoxicació de dades per IA és una prioritat creixent? #

La intoxicació de dades d'IA ja no és una preocupació teòrica. Es reconeix formalment com a LLM04: Enverinament de dades i models al Top 10 de l'OWASP per a aplicacions LLM, juntament amb la injecció ràpida i el risc de la cadena de subministrament com una de les amenaces que defineixen l'era de la IA generativa. Tres tendències l'estan fent pujar de nivell en el radar de tots els equips de seguretat:

• El dany és invisible fins que s'activa. Un model enverinat pot superar totes les proves funcionals i comportar-se perfectament durant mesos, fins que la condició desencadenant específica que ha plantat un atacant finalment apareix en producció.

• La generació augmentada per recuperació és a tot arreu. Qualsevol sistema que permeti a un model extreure context en directe de documents, wikis, tiquets o una base de dades vectorial té una nova superfície d'entrada no auditada, i aquesta superfície és exactament el que s'adreça als atacs d'enverinament de dades.

• Els conjunts de dades ara són actius de la cadena de subministrament. Els equips extreuen rutinàriament models preentrenats, incrustacions i conjunts de dades públics de fonts externes de la mateixa manera que extreuen paquets de codi obert, i igual que un paquet compromès, un conjunt de dades compromès pot portar l'atac silenciosament a tots els equips que l'utilitzen.

Detecció i defensa contra la intoxicació de dades #

Com que l'enverinament de dades es produeix aigües amunt del propi model, la defensa també ha de començar aigües amunt:

• Vigileu les fonts de dades anòmales, no només el codi anòmal. La detecció d'anomalies i comportament s'ha d'estendre fins a on entren les dades pipeline, no s'atura al límit del repositori.

• Coneix tots els conjunts de dades del pipeline. No es pot auditar un risc d'intoxicació en un conjunt de dades que no se sap que existeix. El descobriment continu de conjunts de dades d'entrenament, avaluació i recuperació és la primera línia de defensa.

• Traça el llinatge des del conjunt de dades fins al model i la sortida. Mapejar el camí que pren un conjunt de dades cap a un model, i des d'un model cap a un agent, un punt final o una eina de codificació, és el que converteix "hem obtingut una sortida incorrecta" en "sabem exactament quin conjunt de dades la va introduir".

• Examineu les fonts de recuperació, no només els conjunts d'entrenament. En els sistemes RAG, el magatzem de vectors i la base de coneixement necessiten les mateixes comprovacions d'integritat que les dades d'entrenament, ja que l'enverinament de context es produeix en el moment de la consulta, no en el moment de l'entrenament.

Com ajuda Xygeni a tancar la bretxa d'enverinament de dades? #

La defensa contra la intoxicació de dades comença amb una visibilitat que la majoria de les organitzacions simplement no tenen. XígeniL'inventari d'IA descobreix contínuament tots els actius d'IA de tot el SDLC, incloent-hi els conjunts de dades que hi ha darrere: dades d'entrenament, conjunts d'avaluació i fonts RAG o de recuperació, i els mapa en un gràfic de relacions en directe que va des del conjunt de dades fins al model i al punt final. a l'agent al servidor MCP a l'eina de codificació. Aquest gràfic és el que converteix una sortida de model sospitosa en una pregunta rastrejable: quin conjunt de dades l'ha alimentat i d'on prové.

A més d'aquest inventari, Xygeni's Seguretat de la IA detecta debilitats vectorials i d'incrustació, inclòs el context enverinat en la recuperació i RAG pipelines, alineat amb el OWASP Top 10 per a sol·licituds de LLM. En lloc de confiar que les fonts d'entrenament i recuperació d'un model siguin netes, Xygeni les tracta com a part de la superfície d'atac, de la mateixa manera que ja tracta el codi, les dependències i pipelines. Si actualment no podeu respondre "quines dades han entrenat aquest model i ho podem demostrar", aquesta és exactament la bretxa que val la pena tancar abans que un incident d'enverinament de dades d'IA obligui a plantejar-se la pregunta.

FAQ #