Vaiduoklis saugykloje: kaip haliucinuotos priklausomybės griauna saugią programinės įrangos tiekimo grandinę

Viskas prasidėjo nuo įprastos užduoties vidutinio dydžio finansinių paslaugų įmonėje 2026 m. pradžioje. Vyresnysis „DevOps“ inžinierius, kuriam buvo pavesta optimizuoti pasenusią „Python“ pagrindu veikiančią tarpinę programinę įrangą, kreipėsi į pažangų didelį kalbos modelį (LLM), kad šis padėtų refaktūrizuoti sudėtingą duomenų patvirtinimo rutiną. Dirbtinis intelektas (DI) pateikė elegantišką 20 eilučių sprendimą, kuriame buvo iškviečiama biblioteka pavadinimu fastapi-secure-auth-extension. Biblioteka atrodė patikima, jos sintaksė buvo tobula, o problemą ji išsprendė meistriškai. Per kelias valandas kodas buvo peržiūrėtas, sujungtas ir perkeltas į testavimo aplinką.

Problema buvo ta, kad fastapi-secure-auth-extension neegzistavo – bent jau iki tol, kol prieš tris savaites situacija pasikeitė. Grėsmių sukėlėjas, stebintis dažnus LLM haliucinacijų modelius, nustatė, kad keli populiarūs modeliai dažnai siūlo šį neegzistuojantį paketą. Todėl jie užregistravo šį pavadinimą „Python“ paketų indekse (PyPI) ir įkėlė į jį slaptą, daugiapakopę prisijungimo duomenų rinkimo programą. Kol banko saugumo operacijų centras (SOC) pastebėjo neteisėtą išeinantį srautą į įtartiną galinį tašką Rytų Europoje, jų kūrimo konvejerio vientisumas jau buvo pažeistas.

Žiūrint iš rizikos perspektyvos, tai nebuvo tradicinių ugniasienių ar šifravimo nesėkmė. Tai buvo pasitikėjimo nesėkmė laikais, kai riba tarp sugeneruoto turinio ir patikrinamos realybės išsitrynė. Kaip redaktorius, praleidęs metus analizuodamas pažangias nuolatines grėsmes (APT) ir bendraudamas su „baltųjų skrybėlių“ tyrėjais per šifruotus „Signal“ kanalus, manau, kad ši atakų paviršiaus evoliucija yra ypač bauginanti. Mes nebeturime kovoti tik su kenkėjišku kodu; mes kovojame su statistine tikimybe, kad mašina klysta.

Generatyvinio DI tikimybiniai spąstai

Norėdami suprasti, kodėl šios haliucinacijos yra tokios pavojingos, turime pažvelgti į LLM architektūrinį lygmenį. Šie modeliai nėra duomenų bazės; tai sudėtingi automatinio užbaigimo varikliai. Jie veikia naudodami leksemas (tokens) ir tikimybes, prognozuodami kitą teksto dalį pagal mokymosi metu įsisavintus dėsningumus. Kai modelis susiduria su specifine technine užklausa, jis neieško faktinio atsakymo. Vietoj to, jis sugeneruoja (haliucinuoja) įtikinamai skambantį atsakymą.

Programinės įrangos kūrimo pasaulyje tai sukelia reiškinį, kurį tyrėjai dabar vadina „DI paketų haliucinacija“. Kai LLM pasiūlo biblioteką, kuri neegzistuoja, ji sukuria vakuumą. Piktavaliai dabar aktyviai užpildo šiuos vakuumus. Jie patys naudoja modelius, kad nustatytų, kurios „netikros“ bibliotekos rekomenduojamos dažniausiai, o tada atlieka skaitmeninį „sklypų užgrobimą“, užregistruodami tuos pavadinimus viešose saugyklose, tokiose kaip NPM, PyPI ar „GitHub“.

Žvelgiant į grėsmių aplinką, tai yra meistriškas programinės įrangos tiekimo grandinės sugriovimas. Pastaruosius penkerius metus buvome apsėsti „Nulinio pasitikėjimo“ (Zero Trust) ir programinės įrangos sudėties specifikacijų (SBOM), tačiau dabar matome, kaip kuriamas „juodasis įėjimas“ per pačius įrankius, skirtus mūsų produktyvumui didinti. Atmetus lopymą, tai yra esminė duomenų vientisumo problema, reikalaujanti keisti požiūrį į „žmogiškąją ugniasienę“.

Ne tik kodas: kai meluoja dokumentacija

Nors haliucinuoti paketai yra tiesioginė grėsmė kūrėjams, rizika yra labiau paplitusi nei kelios kenkėjiškos bibliotekos. Įvykus pažeidimui, incidentų tyrėjai dažnai pasikliauja dokumentacija ir sistemos žurnalais, kad atkurtų įvykių seką. Tačiau organizacijoms integruojant DI į savo vidines žinių bazes ir SOC procedūrų aprašus, „vidinių haliucinacijų“ rizika auga.

Įsivaizduokite scenarijų, kai automatizuotas saugumo asistentas haliucinuoja konkretų debesijos aplinkos konfigūracijos nustatymą. Jei jaunesnysis administratorius pasinaudos tuo patarimu, jis gali netyčia palikti atvirą S3 saugyklą arba išjungti kritinę ugniasienės taisyklę, tikėdamas, kad laikosi geriausios praktikos. Neseniai kalbėjausi su teismo ekspertizės analitiku, kuris aptiko neteisingai sukonfigūruotą „Kubernetes“ klasterį – tai buvo tiesioginis rezultatas to, kad DI pasiūlė pasenusį ir nesaugų parametrą, kuris dabartinėje programinės įrangos versijoje nebeegzistavo.

Tai yra šiuolaikinio DI architektūrinis paradoksas: kuo labiau juo pasikliaujame valdydami savo tinklų sudėtingumą, tuo daugiau įdiegiame subtilių, detalių pažeidžiamumų, kurie yra nematomi tradiciniams skenavimo įrankiams. DI nesiekia būti piktavališkas; jis tiesiog stengiasi būti naudingas, ir dėl šio uolumo jis sukuria skaitmeninį Trojos arklį.

Integralumo krizė CIA triadoje

Savo pranešimuose visada grįžtu prie CIA triados: konfidencialumo (Confidentiality), integralumo (Integrity) ir prieinamumo (Availability). Dešimtmečius pramonė daugiausia dėmesio skyrė konfidencialumui (duomenų nutekėjimo stabdymui) ir prieinamumui (DDoS ir išpirkos reikalaujančių programų stabdymui). Tačiau DI haliucinacijos yra tiesioginis išpuolis prieš integralumą.

Jei duomenys, kuriais remiamės priimdami saugumo sprendimus, yra haliucinuoti, visa mūsų gynybinė pozicija tampa kortų nameliu. Norint įvertinti atakų paviršių 2026 m., turime vertinti DI rezultatus kaip potencialiai toksiškus, kol neįrodyta priešingai. Štai kodėl daugelis tyrėjų, su kuriais bendrauju per PGP, dabar pasisako už „patikrinamo DI“ sistemą. Tai ne tik netinkamų žodžių filtravimas; tai DI atsakymų pagrindimas realaus pasaulio, autoritetingais duomenų šaltiniais – procesas, žinomas kaip papildytas generavimas išgaunant informaciją (RAG).

Tačiau net ir RAG nėra stebuklinga priemonė. Jei pagrindiniai išgaunami duomenys yra pažeisti arba jei modelis klaidingai interpretuoja išgautą kontekstą, haliucinacija išlieka, nors ir sudėtingesne forma. Žvelgiant proaktyviai, turime vertinti LLM kaip nepatikimą tinklo vartotoją.

Praktinė gynyba: kaip audituoti miražą

Negalime tiesiog uždrausti DI; produktyvumo padidėjimas yra per didelis, kad jį ignoruotume. Vietoj to turime sukurti atsparią sistemą, kuri atsižvelgtų į „talentingą, bet patologinį melagį“, sėdintį prie klaviatūros. Galutiniam vartotojui, o juo labiau įmonių vadovams, šie žingsniai nebėra pasirenkami:

• Privalomas rankinis viso DI sugeneruoto kodo patikrinimas: jokia DI pasiūlyta biblioteka, funkcija ar konfigūracija neturėtų patekti į gamybinę aplinką be žmogaus, kuris patikrintų jos egzistavimą ir kilmę viešoje ar privačioje saugykloje.
• Haliucinacijas atpažįstančios SCA įrankių diegimas: šiuolaikiniai programinės įrangos sudėties analizės (SCA) įrankiai turi būti sukonfigūruoti taip, kad pažymėtų bet kurią biblioteką, kuri buvo užregistruota visai neseniai arba neturi aiškios prižiūrėtojų istorijos, nes tai yra pagrindiniai haliucinacijų užgrobimo atakos požymiai.
• DI testavimas izoliuotoje aplinkoje („Sandbox“): bet kokios DI sugeneruotos kodo ištraukos arba infrastruktūros kaip kodo (IaC) šablonai pirmiausia turėtų būti vykdomi izoliuotoje, decentralizuotoje aplinkoje. Tai leidžia stebėti neteisėtus išorinius ryšius prieš kodui pasiekiant jūsų pagrindinį tinklą.
• Išsamus DI agentų leidimų valdymas: jei naudojate DI agentus, turinčius įgaliojimus atlikti pakeitimus jūsų aplinkoje, jų leidimai turi būti griežtai apriboti. Niekada nesuteikite DI „Dievo režimo“ ar administratoriaus teisių; jis turėtų veikti tik su minimaliomis privilegijomis, būtinomis užduočiai atlikti.

Kelias į priekį: pasitikėk, bet tikrink

Prieš kelis dešimtmečius sužinojome, kad negalime pasitikėti tinklo perimetru. Pasenusį pilies griovį pakeitėme „Nuliniu pasitikėjimu“ – apsaugos darbuotoju prie kiekvienų vidinių durų. Šiandien tą patį skepticizmą turime taikyti informacijai, kurią generuoja mūsų pačių įrankiai. Anksčiau „šešėlinis IT“ buvo korporatyvinio tinklo tamsioji materija, tačiau šiandien „šešėlinis intelektas“ yra didesnė rizika.

Toliau stebint šias kylančias grėsmes, mano sveika paranoja tik auga. Kiekvieną kartą, kai matau kūrėją, giriantį pokalbių robotą už tai, kad jis per kelias sekundes išsprendė sudėtingą klaidą, susimąstau, kas paslėpta to sprendimo smulkiajame šrifte. Integralumas yra saugumo pagrindas. Jei prarasime gebėjimą atskirti faktą nuo statistiškai tikėtino melo, prarasime gebėjimą ginti savo sistemas.

Jūsų kitas žingsnis aiškus: šiandien pat audituokite savo kūrimo darbo eigą. Ar jūsų inžinieriai turi protokolą DI siūlomoms priklausomybėms tikrinti? Jei atsakymas yra „ne“, jūs ne tik naudojate DI; jūs kuriate skaitmeninę įkaitų situaciją, kuri tik laukia, kada įvyks.

Šaltiniai:

• NIST AI 100-1: Artificial Intelligence Risk Management Framework
• MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems)
• OWASP Top 10 for Large Language Model Applications
• Industry analysis from Snyk and Lasso Security on Package Hallucinations (2024-2025)

Atsakomybės apribojimas: šis straipsnis pateikiamas tik informaciniais ir švietimo tikslais. Tai nėra profesionali teisinė ar kibernetinio saugumo konsultacija. Organizacijos turėtų atlikti savo nepriklausomą rizikos vertinimą ir pasitarti su kvalifikuotais kibernetinio saugumo specialistais prieš diegdamos naujus saugumo protokolus ar DI integracijas.