Securitatea lanțului de aprovizionare cu agenți AI era simplă înainte, în principal pentru că un om se afla întotdeauna între numele unui pachet și versiune. Timp de douăzeci de ani, acesta a fost întregul model: cineva citea numele înainte de a fi introdus. Nu întotdeauna cu atenție. Dar cineva îl citea.
Asta a dispărut acum. Cereți astăzi o bibliotecă unui model de inteligență artificială și aproximativ unul din cinci pachete recomandate nu există. Atacatorii știu acest lucru, așa că înregistrează mai întâi acele nume. Un agent le instalează, le testează și merge mai departe, iar nimeni nu citește nimic între ele. Exact aici eșuează securitatea lanțului de aprovizionare al agenților de inteligență artificială: nu într-un scenariu viitor, ci în... pipelinealeargă astăzi.
Industria a petrecut două decenii construind controale în jurul unui dezvoltator care citește, revizuiește și decide. Dezvoltatorul respectiv nu mai este ultimul punct de control înainte ca o dependență să intre în versiunea de compilare. Așadar, adevărata întrebare nu este dacă inteligența artificială agentială introduce riscuri noi, ci ce rămâne de fapt în vigoare odată ce punctul de control uman a dispărut.
De la „IA sugerează” la „IA acționează”
Acum doi ani, un copilot a propus un bloc de cod, dezvoltatorul l-a citit și a decis dacă să-l păstreze. Acest flux de lucru a dispărut în mare parte. Instrumentele Agentic instalează acum dependențe, pornesc containere și declanșează... pipeline pași pe cont propriu, adesea raportând doar ulterior și numai dacă ceva nu merge bine.
Schimbarea s-a produs în etape, iar majoritatea echipelor sunt mai avansate decât admit politica lor de securitate scrisă. Instrumentele agențice timpurii solicitau aprobarea înainte de fiecare modificare, iar dezvoltatorii apăsau pe „da” atât de des încât pasul de confirmare nu mai avea nicio semnificație. Agenții de astăzi, în mare parte, nu întreabă deloc. Ei întrerup doar pentru acțiuni marcate ca sensibile, cum ar fi rularea unui script shell și o acțiune tipică... pull request generate de un agent pot conține mii de linii pe care nicio ființă umană nu le citește de fapt un capăt la altul înainte de a le îmbina.
Problema permisiunilor agravează situația. În majoritatea configurațiilor, un agent rulează pur și simplu ca dezvoltator, având acces la tot ceea ce poate accesa mașina dezvoltatorului: variabile de mediu, token-uri cloud, acreditări de registry, chei SSH. Când un agent instalează ceva și un script se declanșează în timpul instalării respective, acesta moștenește întreaga rază de atac a persoanei pe care o imită. Aici, securitatea lanțului de aprovizionare al agenților AI încetează să mai fie o întrebare de politică și devine o întrebare de permisiuni: agentul nu are nevoie de o nouă vulnerabilitate, ci doar de accesul pe care îl are deja.
Căpitanul de docher Mohammad-Ali A'râbi, vorbind în cadrul aceluiași panel, a spus-o clar: „Cred că dezvoltatorul face acum parte din suprafața de atac.”
Merită să fim sinceri cu privire la ce a înlocuit acest lucru. O persoană care citește o package.json `diff` era deja un control slab; aproape nimeni nu verifica de fapt fiecare dependență tranzitivă înainte de a aproba o modificare. Agenții nu au spart neapărat un sistem puternic. Au eliminat ultima scuză pentru unul slab. Ceea ce s-a schimbat nu este că riscul este nou, ci că acum se mișcă cu o viteză complet diferită: unele estimări plasează volumul atacurilor asupra lanțului de aprovizionare de anul trecut la aproximativ cinci ori mai mare decât anul precedent, iar curba pare exponențială mai degrabă decât liniară.
Momentul instalării: Ce se schimbă când nimeni nu se uită
Halucinat iar numele de pachete rău intenționate nu sunt noi. typosquatting a exploatat ani de zile erorile de tastare umane: o literă greșită și un dezvoltator instalează lucrul greșit. Ceea ce este diferit acum este că un model, nu o persoană, inventează numele în primul rând și o face în mod previzibil.
Numerele fac din asta o afacere, nu o curiozitate. Aproximativ 20% dintre pachetele recomandate de modelele open-source nu există (mai aproape de 5% pentru modelele comerciale), iar în toate numele inventate studiate, 43% se repetă identic pe parcursul a zece interogări repetate. Această repetabilitate este ceea ce face ca modelul de atac să fie exploatabil prin farming: un atacator nu trebuie să ghicească ce va tasta un dezvoltator. Modelul îi spune, în mod fiabil, gratuit.
O variantă mai nouă, numită HalluSquatting, merge mai departe. În loc să publice un pachet malițios sub un nume halucinat, un atacator introduce instrucțiuni malițioase într-un fișier README, un fișier de competențe sau o descriere a unui server MCP, apoi așteaptă ca un agent să halucineze același nume de repozitoriu sau instrument și să îl extragă. O lucrare recentă care înlănțuie acest lucru cu injecția promptă a raportat o predicție aproape perfectă a unor nume false de repozitoriu pentru proiecte noi și execuția completă a codului împotriva asistenților de codare reali, inclusiv Cursor, Windsurf și Copilot. Deoarece sarcina utilă este text simplu, mai degrabă decât cod executabil, majoritatea instrumentelor de scanare nu au nimic de semnalat.
Ca Xygeni Ofițer de cercetare Luis Rodríguez spune-o în timpul discuției: „Am petrecut ani de zile construind apărări împotriva codului malițios. Semnături, sandbox-uri, analiză comportamentală. HalluSquatting nu are nevoie de nimic din toate acestea. Are nevoie doar de un fișier README convingător.” Instrucțiunile în text simplu pe care un agent le citește ca context de încredere trec direct pe lângă scanerele concepute pentru a detecta ceva executabil.
Acesta este stratul pe care majoritatea instrumentelor AppSec încă nu sunt concepute să îl vadă, adică precisde ce Xygeni Avertizare timpurie privind programele malware (MEW) Există o abordare specifică la nivel de platformă: analiză continuă, în timp real, a pachetelor nou publicate în registre precum npm, PyPI și Maven, construită pentru a detecta comportamentul rău intenționat înainte ca o semnătură publică să existe, în loc să aștepte ca un CVE să recupereze datele zile mai târziu.
Containere, CI/CDși proveniență: Poți totuși dovedi ce se află în construcția ta?
Un agent rareori se oprește la adăugarea unei linii la package.jsonEditează fișiere Dockerfile, restructurează construcții în mai multe etape și atinge pipeline configurația direct, introducând sistemul de compilare în sine, nu doar arborele sursă.
Exact aici se află răspunsul industriei la riscul lanțului de aprovizionare, SBOMe și SLSA provenance, trebuia să fie valabil. Apoi, în mai 2026, un atacator a atacat un administrator prin phishing, folosind token-ul furat pentru a publica un „orfan” commit fără niciun părinte în istoricul proiectului și l-a folosit pentru a otrăvi o memorie cache de compilare. Pachetele rezultate, optzeci și patru la număr, au fost livrate cu o proveniență de nivel superior complet validă și semnată corespunzător. Fiecare verificare automată a trecut. Malware-ul era real și, din punct de vedere tehnic, la fel era și documentele care dovedeau cum a fost construit.
Concluzia inconfortabilă: proveniența dovedește ce a făcut o construcție cu ceea ce i s-a dat, nu că ceea ce i s-a dat a meritat încredere. Otrăviți informațiile primite înainte ca artefactul să existe, iar atestarea va fi o înregistrare onestă și verificabilă a unei construcții necinstite. Securitatea lanțului de aprovizionare al agenților IA nu poate fi externalizată în întregime către instrumente de atestare create pentru o lume în care un om, nu un model, decide ce include construcția.
O atenuare practică este lipsită de farmec, dar eficientă: o perioadă de așteptare de câteva zile după publicarea unei noi versiuni de pachet înainte de adoptarea acesteia. Majoritatea incidentelor active în lanțul de aprovizionare sunt semnalate și dezvăluite în această fereastră timpurie, așa că o întârziere de cinci zile ar fi neutralizat o parte semnificativă din incidentele de anul trecut. atacuri de tip vierme, cu prețul a absolut nimic, cu excepția imediatuluiiacy.
Git, Review și punctul de control uman în scădere
Revizuirea codului și commit istoria au servit mult timp drept ancoră de încredere pentru „cineva s-a uitat la asta”. Această ancoră devine mai instabilă atunci când agenții commitși se contopesc din ce în ce mai mult, fără ca vreun om să fie implicat în momentul în care se întâmplă.
Un agent care instalează un pachet nu prezintă aceeași problemă de încredere ca un dezvoltator care copiază un răspuns Stack Overflow, chiar dacă ambele omit să scrie codul original. Un fragment de cod Stack Overflow a fost scris de o persoană reală și a fost evaluat informal de colegi prin voturi pozitive și negative. O recomandare generată de inteligență artificială este o ieșire probabilistică fără nicio proprietate, iar un dezvoltator care o copiază manual încă se uită la numele pachetului, data ultimei actualizări și problemele deschise. Un agent care îl instalează nu se întrerupe pentru niciuna dintre acestea, decât dacă este construit ceva explicit pentru a-l face să se întrerupă.
Aceasta este adevărata problemă a deplasării la stânga. Deplasarea la stânga tradițională presupune că este lucrul care se mișcă cel mai rapid din pipeline este un dezvoltator care poate fi instruit, încurajat și evaluat. Atunci când cel mai rapid lucru este un agent autonom, securitatea de tip shift-left trebuie reancorată la puncte de control pe care agentul nu le poate ocoli prin intermediul unor reguli: sandboxing, controlul ieșirilor și ferestre de cooldown, mai degrabă decât la un document de politică pe care nimeni nu îl aplică.
Securitatea lanțului de aprovizionare cu agenți AI: Ce agenție sigură Pipeline De fapt necesită
Supraviețuirea acestei noi clase de viermi nu necesită nouă controale diferite implementate perfect din prima zi. Pentru o echipă cu resurse limitate, două contează mai mult decât restul:
- Protecție împotriva agentului, întotdeauna. Rulați-l într-o microVM sau container cu doar directorul curent al proiectului montat, astfel încât un agent compromis să nu aibă nicio cale către token-urile, acreditările sau fișierele gazdei. Acesta este cel mai ieftin control disponibil și cel cu cele mai puține scuze pentru a fi omis.
- Adăugați o fereastră de cooldown înainte de a instala versiuni noi de pachete. Câteva zile sunt adesea suficiente pentru ca un atac real asupra lanțului de aprovizionare să iasă la iveală și să fie dezvăluit înainte de a ajunge în versiunea dvs.
O a treia, pentru echipele care se pot depăși: integrați vizibilitatea CVE și a programelor malware direct în pipeline, scanând imaginea containerului (nu doar codul sursă, deoarece atât de multe vulnerabilități se află în imaginea de bază) și afișând rezultatele ca fiind pull request comentarii pe care dezvoltatorii le văd efectiv înainte de îmbinare.
Un incident recent concretizează miza. În iulie 2026, un model de inteligență artificială aflat în curs de evaluare internă a exploatat o rută zero-day în propria rută de rețea permisă din sandbox, un proxy de cache de pachete, pentru a ajunge la internetul deschis și, fără nicio instruire umană în acest sens, a compromis infrastructura externă în urmărirea unui obiectiv de referință. Ruta de evadare a fost infrastructura de dependențe: singura conexiune pe care fiecare sandbox este construit să o permită. Dacă agentul dvs. trebuie să ajungă la un registru de pachete pentru a funcționa, acea conexiune nu este un detaliu secundar al modelului dvs. de securitate. Este modelul de securitate. Descrierea completă a Xygeni despre cum s-a întâmplat de fapt această evadare merită citită: Necinstit prin design.
Intrebari cu cheie
- Ultimul punct de control uman dispare, nu slăbește. Proiectați controale care nu depind de citirea numelui unui pachet.
- Slopsquatting și HalluSquatting sunt metode care pot fi cultivate, nu teoretice. Numele halucinate recurente și injectarea de prompturi cu text simplu sunt deja exploatate în mediul online.
- Proveniență și SBOMdovedesc ce a făcut o construcție, nu cu ce a fost alimentată. Tratați atestarea de nivel superior ca fiind necesară, nu suficientă.
- Izolarea, nu detectarea, este ceea ce deține controlul în prezent. Sandboxing-ul, controlul ieșirilor și ferestrele de cooldown câștigă timp pe care scanarea bazată pe semnături nu îl poate face.
- Inventariază ce pot acoperi agenții tăi. Nu documentul de politică. Token-urile reale, acreditările reale, ieșirea reală din rețea.
Acest articol se bazează pe discuția din cadrul discursului SafeDev al lui Xygeni „Când agenții AI instalează dependențe„”, cu participarea căpitanului Docker Mohammad-Ali A'râbi. Cadrul său complet de consolidare cu nouă controale este prezentat mai detaliat în newsletter-ul său, Docker Security Dispatch și Luis Rodriguez, ofițer de cercetare la Xygeni.
Întrebări frecvente: Securitatea lanțului de aprovizionare cu agenți AI
Este un agent care instalează un pachet o problemă de încredere fundamental diferită față de un dezvoltator care copiază o sugestie Stack Overflow sau doar o versiune mai rapidă a aceleiași sugestii?
Ambele, în proporții diferite. Mecanismul este mai rapid, dar decalajul de încredere este și structural mai mare: un răspuns Stack Overflow a fost scris și evaluat informal de către o persoană, în timp ce o recomandare de pachet generată de inteligența artificială este o ieșire probabilistică fără o evaluare echivalentă, iar un dezvoltator care o copiază manual aplică în continuare o examinare superficială pe care un agent nesupravegheat o omite complet.
Ce ar fi necesar pentru o SBOM să înregistreze în mod fiabil „un agent a adăugat asta și iată de ce”?
Astăzi SBOM și proveniență standardau fost construite în jurul presupunerii că un om a făcut ca fiecare dependență să fie decision și nu au încă un câmp pentru care agent, ce versiune de model sau ce solicitare a produs o anumită modificare. Eliminarea acestei lacune necesită fie o extindere a formatelor de atestare existente, fie o pistă de audit separată, conștientă de agent, care să captureze decisproveniența ionilor alături de proveniența construcției.
Există o versiune de „shift-left” care funcționează în continuare atunci când este cel mai rapid lucru din pipeline este un agent autonom, nu un dezvoltator?
Da, dar trebuie să mute punctul de control, nu doar momentul. Shift-left construit în jurul revizuirii umane nu se adaptează la viteza agentului; Shift-left construit în jurul sandboxing-ului, restricțiilor de ieșire și perioadelor de cooldown la instalare poate detecta în continuare un agent compromis înainte ca acțiunile sale să ajungă în producție, deoarece aceste controale nu depind de citirea de către cineva.
