Vdor v Mercor razkriva, kako krhka je odprtokodna infrastruktura sodobne umetne inteligence

Naslov in uvod

Vdor v Mercor ni le še en incident v informacijski varnosti – je ogledalo stanja celotnega AI ekosistema. En sam kompromitiran odprtokodni paket, LiteLLM, je po poročanju povezan z na tisoče podjetij, med njimi tudi z 10‑milijardnim samorogom Mercor, ki pomaga trenirati modele za OpenAI, Anthropic in druge. To je šolski primer, kako odvisni smo postali od »nevidnega« odprtokodnega lepila. V nadaljevanju analiziramo, kaj se je zgodilo, zakaj je LiteLLM tako kritična točka, kaj to pove o varnostni zrelosti AI startupov in kakšne posledice ima za evropski, tudi slovenski prostor.

Novica na kratko

Kot poroča TechCrunch, je AI platforma Mercor potrdila varnostni incident, povezan z napadom na dobavno verigo, pri katerem je bil kompromitiran odprtokodni projekt LiteLLM – knjižnica za delo z velikimi jezikovnimi modeli.

Po navedbah TechCruncha:

• je Mercor sporočil, da je bil »eden izmed tisočih podjetij«, ki jih je prizadel kompromis LiteLLM, ki ga varnostni raziskovalci povezujejo s skupino TeamPCP;
• je hekerska skupina Lapsus$ posebej trdila, da je pridobila podatke Mercorja in na svoji strani objavila vzorec – med drugim podatke, povezane z internimi Slack sistemi in ticketingom, ter videoposnetke domnevnih pogovorov med AI sistemi Mercorja in izvajalci;
• je Mercor poudaril, da je incident hitro zamejil, sprožil sanacijo in vključil zunanje forenzične strokovnjake, ni pa odgovoril na vprašanja o tem, katere vrste podatkov so bile morebiti dostopane ali odtujene;
• je bil zlonamerni del kode v LiteLLM odkrit in odstranjen v nekaj urah, knjižnica pa ima po podatkih podjetja Snyk, na katere se sklicuje TechCrunch, vsak dan milijone prenosov.

Obseg prizadetih organizacij in morebitna dejanska izpostavitev podatkov še ni znan.

Zakaj je to pomembno

Mercor ni običajno rekrutacijsko orodje. Deluje kot infrastruktura za človeško znanje v AI svetu: povezuje podjetja, kot sta OpenAI in Anthropic, s strokovnjaki – zdravniki, odvetniki, znanstveniki – ki sodelujejo pri treniranju in vrednotenju modelov. Podjetje navaja več kot 2 milijona dolarjev dnevnih izplačil izvajalcem. To pomeni potencialno izpostavljenost:

• osebnih in finančnih podatkov visoko kvalificiranih izvajalcev,
• zaupnih nalog, pozivov (promptov) in evalvacijskih scenarijev naročnikov,
• pogovorov med človeškimi strokovnjaki in AI sistemi.

Če je bil dostop do tega res mogoč, posledice niso zgolj »še ena kraja podatkov«:

• razkriti so lahko načini testiranja in omejevaje modelov,
• vidni so lahko realni primeri iz medicine, prava ali financ,
• napadalci lahko sklepajo o notranjih procesih najmočnejših AI laboratorijev.

Strategično je še bolj zaskrbljujoče nekaj drugega: 10‑milijardno AI podjetje je po vsej verjetnosti padlo zaradi zastrupljenega odprtokodnega paketa, ne zaradi eksotične ranljivosti v oblaku.

Incident razkrije tri neprijetne resnice:

1. AI samorogi stojijo na ramenih slabo financiranih skrbnikov odprte kode. LiteLLM je tipičen primer knjižnice, ki »vsi uporabljajo, nihče ne plača«.
2. Sklepanje certifikatov ni enako resnični varnosti. Menjava ponudnika za skladnost (compliance) pri LiteLLM po incidentu je simptom, da se zaupanje preveč opira na obrazce, premalo na pregled kode.
3. Napadalci sledijo denarju – to pomeni AI. Skupine, kot sta Lapsus$ in TeamPCP, ciljajo v samo sredico AI skladovnic, kjer lahko prek enega vstopa pridejo do mnogih žrtev.

Širša slika

Napad na LiteLLM se popolnoma ujema v trend napadov na programsko dobavno verigo. Namesto da bi neposredno lomili varnost velikih podjetij, napadalci kompromitirajo dobavitelje ali knjižnice, ki jih vsi uporabljajo.

Zgodovina ponuja jasne vzporednice:

• SolarWinds (2020) je pokazal, kako zastrupljene posodobitve enega ponudnika odprejo vrata v vlade in korporacije.
• Log4Shell (2021) je izkoristil univerzalno logging knjižnico in prisilil cel svet v panično krpanje.
• Poskus vstavljanja stranske kode v XZ Utils (2024) je bil zaustavljen v zadnjem trenutku, preden bi dosegel večino Linux distribucij.

LiteLLM je v AI ekosistemu strukturno podoben: navidez »nizko tvegan« pripomoček, ki razvijalcem olajša delo z modeli. Prav ta poenostavitev pa koncentrira tveganje. Spreminjanje vedenja v takšni knjižnici je cenejše in lažje kot napad na samega ponudnika modela ali velike stranke.

Pri AI so tveganja še večja zaradi:

• občutljivosti podatkov (zaupne zahteve, primeri iz prakse, poslovne skrivnosti),
• velike avtomatizacije (zlonamerni paket lahko avtomatsko krade ključe ali podatke pri številnih odjemalcih),
• hitrega sprejemanja orodij, kjer varnostni pregledi ne dohajajo razvoja.

Večji igralci že odgovarjajo na ta trend:

• gradijo interne ogledalne repozitorije preverjenih paketov,
• zahtevajo SBOM (software bill of materials) od dobaviteljev,
• omejujejo uporabo »naključnih« odprtokodnih knjižnic in forsirajo lastne SDK‑je.

Po primeru Mercor/LiteLLM bodo ti pritiski le še večji. Varnostne ekipe bodo spraševale: Katere knjižnice v našem AI skladu imajo podoben domet kot LiteLLM? in ali se zanašamo na projekte, kjer en sam skrbnik odloča o varnosti tisočih podjetij?

Evropski in lokalni pogled

Za Evropo incident prihaja v trenutku, ko se zakonodaja ostro fokusira na dobavno verigo. Direktiva NIS2, Akt o kibernetski odpornosti (CRA) in Akt o umetni inteligenci vsi poudarjajo odgovornost za komponente, na katerih gradimo storitve.

Če preko Mercorja sodelujejo evropski ali slovenski izvajalci, so pomembna tri vprašanja:

• Ali so bili prizadeti osebni podatki, kar sproži obveznosti po GDPR – vključno z obveščanjem nadzornih organov in posameznikov?
• Kako stranke Mercorja, ki spadajo v kategorije »bistvenih« ali »pomembnih« subjektov po NIS2, dokazujejo, da so dobavno verigo (vključno z LiteLLM) obvladovale?
• Kako bodo bodoče zahteve EU AI Akta o obvladovanju tveganj in sledljivosti podatkov vplivale na platforme, ki organizirajo človeško delo za treniranje modelov?

Za slovenska podjetja in raziskovalce, ki uporabljajo Mercor ali podobne platforme za dodatni zaslužek, gre za zelo praktično vprašanje: varnostne odločitve nekega odprtokodnega projekta v ZDA lahko neposredno vplivajo na vaš dohodek in varstvo vaših osebnih podatkov.

Po drugi strani incident daje dodatno težo razpravam o digitalni suverenosti. EU že financira utrjevanje kritične odprte kode; tovrstni primeri bodo pospešili:

• zahteve po evropskih, pregledanih AI orodjih,
• vključevanje odprtokodnih skrbnikov v javno financirane varnostne programe,
• strožje pogoje za ameriške AI ponudnike, ki obdelujejo podatke EU državljanov.

Pogled naprej

Dogajanje okoli LiteLLM je najbrž šele na začetku. V naslednjih mesecih bo ključnih več stvari:

1. Tehnična razjasnitev napada. Forenzične analize bodo pokazale, ali so bili kompromitirani razvijalci, gradni sistemi ali distribucijska infrastruktura ter ali so podobne tehnike že uporabljene pri drugih AI knjižnicah.
2. Obseg žrtev. Če se bo izkazalo, da je prizadetih res na tisoče podjetij, bo LiteLLM pristal v istih predstavitvah CISO‑jev kot SolarWinds in Log4j – kot primer, zakaj je dobavna veriga največje tveganje.
3. Regulatorne reakcije. Evropski nadzorni organi bodo incident gotovo uporabili kot konkreten argument za strožjo implementacijo NIS2, CRA in AI Akta.

Za AI startupe so domače naloge jasne:

• uvesti strogo politiko odvisnosti, interne registre odobrenih paketov in avtomatizirano preverjanje,
• voditi SBOM in strateško obravnavati skrbnike ključnih odprtokodnih komponent,
• razširiti »AI varnost« z modelov (bias, alignment) na celotno infrastrukturo.

Za slovenski ekosistem – od ljubljanskih startupov do večjih podjetij – je to trenutek za streznitev. Investicije v GPU in modele brez resne investicije v varnostno arhitekturo so kratkovidne. V naslednjih dveh do treh letih bo stopnja zaupanja v AI ponudnike v veliki meri odvisna od tega, kako transparentno in odgovorno upravljajo svojo odprtokodno dobavno verigo.

Sklep

Primer Mercor–LiteLLM je opozorilo, da se revolucija umetne inteligence naslanja na krhko odprtokodno infrastrukturo, ki jo napadalci zdaj aktivno ciljajo. Uporabniki, regulatorji in vlagatelji bi morali pri vsakem AI ponudniku zastaviti preprosto vprašanje: pokažite nam svojo dobavno verigo. Dokler bodo AI podjetja več vlagala v nove modele kot v varnost svojih odvisnosti, bomo iste lekcije plačevali znova – vsakič z večjim tveganjem in višjo ceno.