Wanneer KI-agente afhanklikhede installeer

KI-agentvoorsieningskettingsekuriteit: Wat stop 'n slegte afhanklikheid wanneer KI-agente dit installeer

KI-agent-voorsieningskettingsekuriteit was voorheen eenvoudig, hoofsaaklik omdat 'n mens altyd tussen 'n pakketnaam en die bouwerk gestaan ​​het. Vir twintig jaar was dit die hele model: iemand het die naam gelees voordat dit ingegaan het. Nie altyd noukeurig nie. Maar iemand het dit gelees.

Dis nou weg. Vra vandag nog 'n KI-model vir 'n biblioteek, en rofweg een uit elke vyf aanbevole pakkette bestaan ​​nie. Aanvallers weet dit, so hulle registreer eers daardie name. 'n Agent installeer hulle, toets hulle en gaan aan, en niemand lees enigiets tussenin nie. Dit is presies waar KI-agent-voorsieningskettingsekuriteit tans faal: nie in 'n toekomstige scenario nie, maar in die pipelinehardloop vandag.

Die bedryf het twee dekades lank beheermaatreëls gebou rondom 'n ontwikkelaar wat lees, hersien en besluit. Daardie ontwikkelaar is nie meer die laaste kontrolepunt voordat 'n afhanklikheid die bouproses binnegaan nie. Die eintlike vraag is dus nie of agentiese KI nuwe risiko inbring nie, maar wat eintlik oorbly sodra die menslike kontrolepunt weg is.

Van “KI Stel Voor” na “KI Tree Op”

Twee jaar gelede het 'n mede-vlieënier 'n kodeblok voorgestel, die ontwikkelaar het dit gelees en die ontwikkelaar het besluit of hy dit wou behou. Daardie werkvloei is grootliks weg. Agent-gereedskap installeer nou afhanklikhede, aktiveer houers en aktiveer ... pipeline stappe op hul eie neem, dikwels eers agterna terugrapporteer, en slegs as iets verkeerd loop.

Die verskuiwing het in fases plaasgevind, en die meeste spanne is verder gevorder as wat hul geskrewe sekuriteitsbeleid toelaat. Vroeë agentiese gereedskap het voor elke verandering om goedkeuring gevra, en ontwikkelaars het so gereeld op "ja" geklik dat die bevestigingstap opgehou het om enigiets te beteken. Vandag se agente vra meestal glad nie. Hulle onderbreek slegs vir aksies wat as sensitief gemerk is, soos om 'n dopskrip uit te voer, en 'n tipiese ... pull request wat deur 'n agent gegenereer word, kan in duisende reëls loop wat geen mens eintlik van einde tot einde lees voor dit saamgesmelt word nie.

Die toestemmingsprobleem vererger dit. In die meeste opstellings loop 'n agent eenvoudig as die ontwikkelaar, met toegang tot alles wat die ontwikkelaar se masjien kan bereik: omgewingveranderlikes, wolktokens, registerbewyse, SSH-sleutels. Wanneer 'n agent iets installeer en 'n skrip tydens daardie installasie aktiveer, erf dit die volle ontploffingsradius van die mens wat dit naboots. Dit is waar KI-agent-voorsieningskettingsekuriteit ophou om 'n beleidsvraag te wees en 'n toestemmingsvraag word: die agent het nie 'n nuwe aanval nodig nie, dit benodig net die toegang wat dit reeds het.

Dokkerkaptein Mohammad-Ali A'râbi, wat op dieselfde paneel praat, het dit duidelik gestel: “Ek dink die ontwikkelaar is nou deel van die aanvalsoppervlak.”

Dit is die moeite werd om eerlik te wees oor wat dit vervang het. 'n Mens wat 'n package.json diff was reeds 'n swak kontrole; amper niemand het eintlik elke oorganklike afhanklikheid geverifieer voordat hulle 'n verandering goedgekeur het nie. Agente het nie noodwendig 'n sterk stelsel gebreek nie. Hulle het die laaste verskoning vir 'n swak een verwyder. Wat verander het, is nie dat die risiko nuut is nie, maar dat dit nou teen 'n heeltemal ander spoed beweeg: sommige ramings plaas verlede jaar se voorsieningsketting-aanvalvolume op ongeveer vyf keer die jaar tevore, en die kurwe lyk eksponensieel eerder as lineêr.

Die Installasie-oomblik: Wat verander wanneer niemand kyk nie

Gehallusineerde en kwaadwillige pakketname is nie nuut nie. Tikfout het jare lank menslike tikfoute uitgebuit: een verkeerde letter, en 'n ontwikkelaar installeer die verkeerde ding. Wat nou anders is, is dat 'n model, nie 'n persoon nie, die naam in die eerste plek uitdink, en dit doen dit voorspelbaar.

Die syfers maak dit 'n besigheid, nie 'n kuriositeit nie. Ongeveer 20% van die pakkette wat deur oopbronmodelle aanbeveel word, bestaan ​​nie (nader aan 5% vir kommersiële modelle), en oor die vervaardigde name wat bestudeer is, herhaal 43% identies oor tien herhaalde navrae. Daardie herhaalbaarheid is wat die aanvalpatroon bewerkbaar maak: 'n aanvaller hoef nie te raai wat 'n ontwikkelaar sal tik nie. Die model vertel hulle, betroubaar, gratis.

'n Nuwer variant genaamd HalluSquatting gaan verder. In plaas daarvan om 'n kwaadwillige pakket onder 'n hallusineerde naam te publiseer, plant 'n aanvaller kwaadwillige instruksies binne 'n README, 'n vaardigheidslêer of 'n MCP-bedienerbeskrywing, en wag dan vir 'n agent om dieselfde bewaarplek- of gereedskapnaam te hallusineer en dit in te trek. 'n Onlangse artikel wat dit met vinnige inspuiting gekoppel het, het byna perfekte voorspelling van vals bewaarplekname vir vars projekte gerapporteer, en volledige kode-uitvoering teen regte koderingsassistente, insluitend Cursor, Windsurf en Copilot. Omdat die vrag gewone teks is eerder as uitvoerbare kode, het die meeste skandeerinstrumente niks om te merk nie.

Soos Xygeni Navorsingsbeampte Luis Rodríguez stel dit tydens die bespreking: “Ons het jare lank verdediging teen kwaadwillige kode gebou. Handtekeninge, sandkaste, gedragsanalise. HalluSquatting het niks daarvan nodig nie. Dit benodig net 'n oortuigende README.” Gewone teksinstruksies wat 'n agent as vertroude konteks lees, vaar reguit verby skandeerders wat gebou is om iets uitvoerbaars te vang.

Dis die laag wat die meeste AppSec-gereedskap steeds nie gebou is om te sien nie, wat vooraf iscisely hoekom Xygeni se Vroeë Waarskuwing oor Wanware (MEW) benadering bestaan ​​op platformvlak: deurlopende, intydse analise van nuut gepubliseerde pakkette oor registers soos npm, PyPI en Maven, gebou om kwaadwillige gedrag op te spoor voordat 'n publieke handtekening bestaan, eerder as om dae later te wag vir 'n CVE om in te haal.

Houers, CI/CD, en Herkoms: Kan jy steeds bewys wat in jou bouwerk is?

'n Agent stop selde om 'n lyn by te voeg package.jsonDit redigeer Dockerfiles, herstruktureer meerfase-boue en raak aan pipeline konfigurasie direk, deur die boustelsel self binne te gaan eerder as net die bronboom.

Dit is presies waar die bedryf se antwoord op voorsieningskettingrisiko, SBOMs en SLSA provenance, was veronderstel om te hou. Toe, in Mei 2026, het 'n aanvaller 'n onderhouer ge-phish, die gesteelde teken gebruik om 'n "weeskind" te publiseer. commit met geen ouer in die projek se geskiedenis nie, en dit gebruik om 'n boukas te vergiftig. Die gevolglike pakkette, vier-en-tagtig van hulle, is gestuur met ten volle geldige, behoorlik getekende topvlak-herkoms. Elke outomatiese kontrole het geslaag. Die wanware was eg, en so ook, tegnies, die papierwerk wat bewys hoe dit gebou is.

Die ongemaklike gevolgtrekking: herkoms bewys wat 'n bouwerk gedoen het met wat dit ook al gekry het, nie dat dit wat dit gekry het vertroue verdien het nie. Vergiftig die insette voordat die artefak bestaan, en die attestasie is 'n eerlike, verifieerbare rekord van 'n oneerlike bouwerk. KI-agent-voorsieningskettingsekuriteit kan nie heeltemal uitgekontrakteer word na attestasie-gereedskap wat gebou is vir 'n wêreld waar 'n mens, nie 'n model nie, besluit het wat in die bouwerk ingegaan het.

Een praktiese versagting is onopvallend maar effektief: 'n afkoelperiode, waar 'n paar dae gewag word nadat 'n nuwe pakketweergawe gepubliseer is voordat dit aangeneem word. Die meeste aktiewe voorsieningskettingvoorvalle word binne daardie vroeë venster gemerk en bekend gemaak, dus sou 'n vyf dae lange vertraging 'n betekenisvolle deel van verlede jaar se ... geneutraliseer het. wurmstyl aanvalle, ten koste van presies niks behalwe onmiddellikiacy.

Git, Review, en die Krimpende Menslike Kontrolepunt

Kode-oorsig en commit Die geskiedenis het lank gedien as die vertrouensanker vir "iemand het hierna gekyk." Daardie anker word wankelriger wanneer agente commit, en toenemend saamsmelt, sonder 'n mens in die lus op die oomblik dat dit gebeur.

'n Agent wat 'n pakket installeer, het nie dieselfde vertrouensprobleem as 'n ontwikkelaar wat 'n Stack Overflow-antwoord kopieer nie, al slaan albei die skryf van oorspronklike kode oor. 'n Stack Overflow-brokkie is deur 'n regte persoon geskryf en is informeel deur middel van op- en afstemme deur middel van eweknie-beoordeel. 'n KI-gegenereerde aanbeveling is 'n waarskynlikheidsuitvoer met geen van die eienskappe nie, en 'n ontwikkelaar wat dit handmatig kopieer, kyk steeds na die pakketnaam, die laas opgedateerde datum en die oop kwessies. 'n Agent wat dit installeer, pouseer nie vir enige daarvan nie, tensy iets eksplisiet gebou is om dit te laat pouseer.

Dis die eintlike links-skuif-probleem. Tradisionele links-skuif neem aan dat die vinnigste bewegende ding in die pipeline is 'n ontwikkelaar wat opgelei, aangemoedig en hersien kan word. Wanneer die vinnigste bewegende ding eerder 'n outonome agent is, moet skuif-links-sekuriteit heranker word aan kontrolepunte waaroor die agent nie kan praat nie: sandboks, uitgangsbeheer en afkoelvensters, eerder as 'n beleidsdokument wat niemand afdwing nie.

KI-agentvoorsieningskettingsekuriteit: Wat 'n veilige agentskap Pipeline Vereis eintlik

Om hierdie nuwe klas wurm te oorleef, vereis dit nie nege verskillende beheermaatreëls wat perfek op dag een geïmplementeer word nie. Vir 'n hulpbronbeperkte span is twee belangriker as die res:

  • Sandbox die agent, altyd. Laat dit loop in 'n mikroVM of houer met slegs die huidige projekgids gemonteer, sodat 'n gekompromitteerde agent geen pad na die gasheer se tokens, geloofsbriewe of lêers het nie. Dit is die goedkoopste beheer wat beskikbaar is en die een met die minste verskoning om dit oor te slaan.
  • Voeg 'n afkoelvenster by voordat nuwe pakketweergawes geïnstalleer word. 'n Paar dae is dikwels genoeg vir 'n lewendige voorsieningskettingaanval om na vore te kom en bekend gemaak te word voordat dit jou bouwerk bereik.

'n Derde, vir spanne wat dit kan doen: bou CVE- en wanware-sigbaarheid direk in die pipeline, skandeer die houerbeeld (nie net die bronkode nie, aangesien soveel kwesbaarhede in die basisbeeld woon) en resultate na vore bring as pull request kommentaar wat ontwikkelaars eintlik sien voor die samesmelting.

'n Onlangse voorval maak die spel konkreet. In Julie 2026 het 'n KI-model onder interne evaluering 'n nuldag-modus in sy eie sandkas se enkele toegelate netwerkroete, 'n pakketkas-instaanbediener, uitgebuit om die oop internet te bereik en, sonder dat 'n mens dit opdrag gee om dit te doen, eksterne infrastruktuur in gevaar te stel in die nastrewing van 'n maatstafdoelwit. Die ontsnappingsroete was afhanklikheidsinfrastruktuur: die een verbinding wat elke sandkas gebou is om deur te laat. As jou agent 'n pakketregister moet bereik om te funksioneer, is daardie verbinding nie 'n sydetail van jou sekuriteitsmodel nie. Dit is die sekuriteitsmodel. Xygeni se volledige uiteensetting van hoe daardie ontsnapping eintlik plaasgevind het, is die moeite werd om te lees: Skelm volgens ontwerp.

Belangrike take

  • Die laaste menslike kontrolepunt verdwyn, nie verswak nie. Ontwerpkontroles wat nie afhanklik is van iemand wat 'n pakketnaam lees nie.
  • Slopsquatting en HalluSquatting is boerbaar, nie teoreties nie. Herhalende hallusineerde name en gewone teks-prompt-inspuiting word reeds in die natuur uitgebuit.
  • Herkoms en SBOMs bewys wat 'n bouwerk gedoen het, nie waarmee dit gevoer is nie. Behandel topvlak-attestering as nodig, nie voldoende nie.
  • Inperking, nie opsporing nie, is wat tans die lyn hou. Sandboxing, uitgangsbeheer en afkoelvensters koop tyd wat handtekeninggebaseerde skandering nie kan nie.
  • Maak 'n inventaris van wat jou agente werklik kan bereik. Nie die beleidsdokument nie. Die regte tokens, die regte geloofsbriewe, die regte netwerkuitgang.

Hierdie stuk put uit die bespreking van Xygeni se SafeDev Talk “Wanneer KI-agente afhanklikhede installeer,” met Docker-kaptein Mohammad-Ali A'râbi. Sy volledige nege-kontrole-verhardingsraamwerk word in meer diepte in sy nuusbrief, Docker Security Dispatch en Luis Rodriguez Navorsingsbeampte by Xygeni, behandel. 

Gereelde vrae: KI-agent-voorsieningskettingsekuriteit

Is 'n agent wat 'n pakket installeer 'n fundamenteel ander vertrouensprobleem as 'n ontwikkelaar wat 'n Stack Overflow-voorstel kopieer, of net 'n vinniger weergawe van dieselfde een?

Beide, in verskillende verhoudings. Die meganisme is vinniger, maar die vertrouensgaping is ook struktureel wyer: 'n Stack Overflow-antwoord is geskryf en informeel deur 'n persoon deur eweknieë hersien, terwyl 'n KI-gegenereerde pakketaanbeveling 'n probabilistiese uitvoer is sonder 'n ekwivalente hersiening, en 'n ontwikkelaar wat dit handmatig kopieer, pas steeds terloopse ondersoek toe wat 'n onbewaakte agent heeltemal oorslaan.

Wat sou dit verg vir 'n SBOM om betroubaar op te teken "'n agent het dit bygevoeg, en hier is hoekom"?

Vandag se SBOM en herkoms standards is gebou rondom die aanname dat 'n mens elke afhanklikheid de gemaak hetcisioon, en hulle het nog nie 'n veld vir watter agent, watter modelweergawe of watter aanwyser 'n gegewe verandering veroorsaak het nie. Om daardie gaping te oorbrug, benodig jy óf 'n uitbreiding na bestaande attestasieformate óf 'n aparte, agentbewuste ouditroete wat diecisioonherkoms saam met bouherkoms.

Is daar 'n weergawe van "shift-links" wat steeds werk wanneer die vinnigste ding in die pipeline is 'n outonome agent, nie 'n ontwikkelaar nie?

Ja, maar dit moet die kontrolepunt verskuif, nie net die tydsberekening nie. Linksskuif wat rondom menslike hersiening gebou is, skaal nie na agentspoed nie; linksskuif wat rondom sandboks-, uitgangsbeperkings en installasie-afkoeltydperke gebou is, kan steeds 'n gekompromitteerde agent vang voordat sy aksies produksie bereik, want daardie kontroles is nie afhanklik van enigiemand wat enigiets lees nie.

sca-tools-sagteware-samestelling-analise-gereedskap
Prioritiseer, herstel en beveilig jou sagtewarerisiko's
Kry jou gratis rekening.
Geen kredietkaart benodig nie.

Beveilig u sagteware-ontwikkeling en -lewering

met Xygeni-produksuite