Vibe coding uzņēmumos: kā nepieļaut, ka MI ģenerēta programmatūra kļūst par drošības problēmu?

Prototips parasti pierāda konkrētu scenāriju: lietotājs nospiež pogu, saņem atbildi un var turpināt darbu. Droša uzņēmuma sistēma savukārt ir jāpārbauda arī apstākļos, kad lietotājs nav autorizēts, ievade ir kļūdaina vai ļaunprātīga, piegādātāja serviss nav pieejams, datubāze atbild negaidīti vai viena klienta dati nedrīkst būt redzami citam. Ja prasību sarakstā ir tikai veiksmīgais scenārijs, MI var izveidot precīzi to, kas prasīts, un vienlaikus atstāt nepārbaudītas visbīstamākās robežas.

Šī nav tikai MI radīta problēma. Arī cilvēka rakstītā programmatūrā rodas autorizācijas kļūdas, nedroša ievades apstrāde un nepareizas konfigurācijas. Atšķirība ir darba ātrumā un kontroles paradumos: ja jaunas funkcijas var uzģenerēt ātrāk, nekā komanda spēj izprast to drošības sekas, nepārbaudīto izmaiņu apjoms aug. Lielāks koda apjoms pats par sevi nepierāda lielāku ievainojamību īpatsvaru; tas palielina pārbaudāmo virsmu un rada vadības problēmu, ja kontroles jauda paliek nemainīga.

OWASP 2025. gada tīmekļa lietotņu risku apkopojumā injekciju joprojām aplūko kā atsevišķu, būtisku ievainojamību klasi. Nepietiekama ievades apstrāde, piekļuves kontrole un nedroša mijiedarbība ar datubāzēm nepazūd tikai tāpēc, ka kodu uzrakstījis moderns modelis S02. Turklāt MI asistenta klātbūtne var pievienot atsevišķu risku: ja rīks lasa neuzticamu repozitorija saturu, tīmekļa lapas vai darba uzdevumus un spēj izpildīt komandas, ārējā tekstā ievietotas instrukcijas var mēģināt ietekmēt tā rīcību. OWASP šo problēmu apraksta kā prompt injection, kas jānošķir no tradicionālas SQL vai komandrindas injekcijas pašā lietotnē S03.

Pirmais slānis ir ģenerētās lietotnes drošība: vai tās funkcijas pareizi aizsargā datus, identitātes, sesijas un operācijas? Otrais ir izstrādes procesa drošība: kā MI rīks piekļūst repozitorijam, noslēpumiem, iekšējiem dokumentiem, terminālim un CI/CD konfigurācijai? Trešais ir programmatūras piegādes drošība: no kurām bibliotēkām un būvēšanas darbībām izveidots izlaidums, kurš to ir apstiprinājis un kā tas nokļuvis ražošanā? Katram slānim vajadzīgas atšķirīgas kontroles, un viena veiksmīga koda skenēšana tos visus neaptver.

Piemēram, MI var ģenerēt pilnīgi korektu datubāzes vaicājumu, bet lietotnes API pirms tā neidentificē konkrētā ieraksta īpašnieku. Statiskā analīze ne vienmēr atklās šādu biznesa autorizācijas kļūdu. Citā gadījumā kods var būt kvalitatīvs, bet izstrādes aģentam atļauts izlasīt produkcijas piekļuves atslēgas vai mainīt izvietošanas darbplūsmu. Trešajā gadījumā tests un pārskatīšana notiek pret vienu atkarību kopu, bet faktiskā būvēšana bez pietiekamas fiksācijas iegūst citas versijas. Šie piemēri ilustrē atšķirīgus neveiksmes ceļus; tie nav apgalvojums par konkrēta MI produkta novērotu incidentu.

Bieži vien sākotnējā uzdevumā ir aprakstīts, ko sistēmai vajag darīt, bet nav pateikts, ko tā nekādā gadījumā nedrīkst darīt. Ja MI tiek lūgts izveidot klientu dokumentu portālu, prasībām jāietver ne vien augšupielāde un lejupielāde, bet arī dokumentu īpašumtiesību pārbaude katram pieprasījumam, failu tipa un izmēra ierobežojumi, droša glabāšana, audita notikumi un pārbaudāma dzēšana. Prasība “izveido drošu portālu” ir pārāk neskaidra, lai pēc tās varētu objektīvi pieņemt darbu.

Uzņēmumam ir vērtīgi formulēt drošības invariantus: apgalvojumus, kam jāpaliek patiesiem neatkarīgi no implementācijas. Piemēram, “klients A nevar izlasīt klienta B datus”, “neautorizēts pieprasījums nevar mainīt maksājuma statusu”, “publiski pieejama saskarne nekad neatgriež servera noslēpumus” un “produkcionālu datu dzēšanu nevar palaist izstrādes aģents”. Katram šādam apgalvojumam vajadzīgs pārbaudes veids: negatīvs integrācijas tests, piekļuves politikas tests, konfigurācijas pārbaude vai neatkarīga atbildīgā apstiprinājums. Tas ļauj vērtēt rezultātu, nevis ģeneratora pārliecinošumu.

NIST SSDF ir noderīgs kā procesa pamats, jo tas aptver programmatūras aizsardzību, drošas izstrādes prakses, ievainojamību novēršanu un atbildības sadalījumu. Tas nav “MI sertifikāts” un pats par sevi neapstiprina atsevišķas sistēmas drošumu S01. Tāpēc uzņēmumam SSDF principus jāpārvērš savā tehnoloģiju stekam atbilstošos izpildāmos vārtos.

MI asistents, kurš piedāvā koda fragmentus, un aģents, kurš spēj palaist termināļa komandas, instalēt pakotnes, labot konfigurāciju un veidot pull request, nav viens un tas pats darbības modelis. Otrajam ir jāierobežo tiesības tāpat kā jebkurai citai automatizētai identitātei. Lasīšanas tiesības nav rakstīšanas tiesības; izmaiņas atsevišķā darba zarā nav atļauja apvienot tās ar galveno zaru; testu palaišana nav atļauja piekļūt ražošanas noslēpumiem.

Praktiski tas nozīmē izolētu izstrādes vidi, atsevišķus īslaicīgus akreditācijas datus, minimālu tīkla piekļuvi, aizliegtu piekļuvi produkcijas datiem un izpildes ierakstus. Ārējās lapas, README faili, issue apraksti un trešo pušu atkarību dokumentācija ir jāuztver kā dati, nevis kā instrukcijas, kurām drīkst piešķirt sistēmas administratora autoritāti. OWASP MI lietotņu riska vadlīnijas īpaši pievērš uzmanību neuzticama satura ietekmei, sensitīvas informācijas noplūdei un pārmērīgām pilnvarām S03.

Cilvēka apstiprinājums augsta riska darbībām ir jēgpilns tikai tad, ja apstiprinātājs redz, kas tieši tiks izdarīts. Vispārīga poga “atļaut visu” nepierāda kontroli. Jābūt redzamam komandas saturam, skartajiem failiem, tīkla galamērķiem vai izmaiņu kopumam un, nepieciešamības gadījumā, atšķirīgai personai, kura apstiprina darbību. Arī tā nav absolūta garantija: pārskatīšanas kvalitāti nosaka konteksts, laiks un cilvēka kompetence.

MI ģenerēts risinājums var izvēlēties bibliotēkas vai ierosināt pakotņu instalēšanu, nepaskaidrojot to uzturēšanas vēsturi, izcelsmi un nepieciešamību. Atkarības nav automātiski nedrošas, taču tās pārvieto uzticēšanās robežu ārpus uzņēmuma. Ja ieviesta papildu pakotne vienkāršam uzdevumam, jāspēj izskaidrot, kāpēc tā ir vajadzīga, no kurienes tā nāk un kā organizācija reaģēs uz tās ievainojamībām vai kompromitēšanu.

Minimālais pārvaldības komplekts ietver deklarētas tiešās atkarības, fiksētu atrisināto versiju stāvokli (lockfile vai ekosistēmas ekvivalentu), skenēšanu pret zināmām ievainojamībām, licences un izcelsmes izvērtēšanu atbilstoši riskam, kā arī procedūru atjauninājumu testēšanai. Slēgtā būvēšanas vidē jāzina arī, kādas atkarības faktiski nonāca gala artefaktā. SBOM jeb programmatūras sastāvdaļu saraksts palīdz inventarizēt komponentus, bet nepasaka, vai lietotnes biznesa loģika ir pareiza, un neaizstāj ievainojamību analīzi.

Vērts īpaši uzmanīties no vienkāršiem automātiskās instalēšanas paraugiem, kuros aģents bez pārskatīšanas lejupielādē un izpilda nepazīstamu skriptu. Šādā situācijā “veiksmīgs builds” var nozīmēt tikai to, ka nedroša darbība ir tehniski izdevusies. Piegādes ķēdes drošība sākas ar ievades kontrolēšanu un turpinās līdz izlaiduma pārbaudei; tā nav viena skenera izvēle.

Automātiski ģenerēti testi nereti labi apstiprina paša ģenerētā risinājuma paredzēto uzvedību, bet tie var pārņemt tā kļūdainos pieņēmumus. Ja implementācijā trūkst klientu izolācijas, no tās pašas prasības ģenerētais tests var nepārbaudīt pieprasījumu ar sveša klienta identifikatoru. Tādēļ testu avotiem jābūt neatkarīgiem: biznesa prasības, draudu modelis, iepriekšējie incidenti un konkrētas drošības politikas, ne tikai esošā koda interpretācija.

Pārbaudes vēlams veidot slāņos. Vienībtesti apliecina izolētu funkciju uzvedību; integrācijas testi pārbauda datubāzes, identitāšu un pakalpojumu robežas; negatīvie autorizācijas testi mēģina šķērsot lietotāju un klientu robežas; statiskā analīze meklē noteiktas kļūdu klases; atkarību analīze pārbauda zināmas problēmas komponentos; dinamiskā testēšana vērtē darbojošos lietotni. Augstāka riska produktiem nepieciešama manuāla drošības pārskatīšana un mērķēti adversariāli testi. OWASP norāda uz koda pārskatīšanas un automatizētas testēšanas kombināciju injekciju atklāšanai, nevis uz vienu universālu testu S02.

Kritiskais jautājums ir nevis “cik testu ir zaļi?”, bet “kuru risku katrs tests tiešām aptver?”. Simts veiksmīgi testi var būt mazāk noderīgi nekā viens pareizi izveidots tests, kas pierāda nepieļaujamu piekļuvi citas organizācijas datiem. Vienlaikus viens tests nekad nevar pierādīt pilnīgu drošību. Tāpēc svarīga ir sasaite starp konkrētu risku, kontroli, testa rezultātu un atbildīgo personu.

Pat labi pārskatīts kods nedod pārliecību par izlaidumu, ja nav zināms, kā tas uzbūvēts. Būvēšanas laikā var tikt iegūtas citas atkarības, izmantotas atšķirīgas konfigurācijas vai palaisti ārēji skripti. Uzņēmumam jāspēj sasaistīt izlaisto artefaktu ar konkrētu pirmkoda revīziju, būvēšanas vidi un definētu procesu. Tieši šo problēmu risina SLSA pieeja programmatūras piegādes ķēdes drošībai S04.

SLSA 1.2 Build līmeņi nav produkta kvalitātes atzīmes. Pirmajā līmenī ir izcelsmes apliecinājuma (provenance) pamats; otrajā paredzēts parakstīts apliecinājums no atbilstošas mitinātas būvēšanas platformas; trešais stiprina būvēšanas platformas izolāciju un aizsardzību S04. Tas palīdz konstatēt, kur un kā artefakts radies, bet automātiski nenozīmē, ka tajā nav autorizācijas kļūdu. Arī reproducējama būvēšana un provenance nav viens un tas pats: izcelsmes ieraksts var pastāvēt bez pierādījuma, ka neatkarīgs atkārtojums dod bitu līmenī identisku rezultātu.

Praktiskais mērķis nav sākt ar augstāko līmeni uz papīra. Vispirms jāpanāk, ka izlaidumam ir nemaināms identifikators, pārskatāma pirmkoda revīzija, zināmas atkarības, izolēta CI vide, saglabāti testi un apstiprinājuma ieraksts. Nākamais solis ir kriptogrāfiski pārbaudāms būvēšanas izcelsmes apliecinājums un artefakta verificēšana pirms izvietošanas. Ja kāds no kritiskajiem pierādījumiem trūkst, produkcijas izlaide jāaptur atbilstoši iepriekš definētai riska politikai, nevis jāaizstāj pierādījums ar ģeneratora tekstu “done”.

Uzņēmumam nevajag radīt atsevišķu birokrātiju katram MI ģenerētam failam. Labāks risinājums ir izmantot vienu pieņemšanas procesu visām programmatūras izmaiņām, pielāgojot pārbaudes riskam. MI izmantojums ir konteksts, kas ietekmē pārskatīšanu, bet ne attaisnojums vājākiem kritērijiem. Tāpat nav saprātīgi pieprasīt identisku drošības apjomu iekšējam prezentācijas prototipam un klientu maksājumu sistēmai.

Šāda matrica ir autora ieteikts pārvaldības modelis, nevis kādas institūcijas obligāta sertifikācijas prasība. Tās vērtība ir skaidra pierādījumu ķēde: ja pēc incidenta uzņēmums nevar noteikt, kurš apstiprināja riskantu izmaiņu, kādu kodu pārbaudīja un kas tika izvietots, problēma nav tikai izstrādes ātrumā. Tā ir kontroles un atbildības trūkums.

Iedomāsimies, ka MI izveido funkciju, kura ļauj klienta administratoram eksportēt savas organizācijas darījumu ierakstus. Demonstrācijā viss darbojas: pēc klikšķa tiek izveidots CSV fails. Pirms funkciju pieņem, komanda formulē četrus aizliegtus scenārijus: citas organizācijas datu eksports, eksports bez atbilstošas lomas, piekļuve failam pēc tiesību atsaukšanas un datu noplūde caur kļūdu vai žurnāla ierakstu. Katrs scenārijs jātestē API un glabāšanas slānī, nepaļaujoties tikai uz paslēptu pogu saskarnē.

Tad jāpārbauda eksportēšanas ierobežojumi: datu apjoms, izpildes laiks, pagaidu faila glabāšanas termiņš, parakstītu lejupielādes saišu derīgums, CSV formulas ievades risks un audita ieraksts par pieprasītāju. Jāizvērtē, vai rīks izveidojis jaunu ārēju pakotni un vai tai patiešām ir nepieciešama piekļuve datiem. Tikai pēc negatīvo testu, koda pārskatīšanas un izlaiduma sasaistes ar pārbaudīto revīziju funkcija kļūst par produkcijas kandidātu. Piemērs ir hipotētisks; tas ilustrē pieņemšanas metodiku, nevis dokumentētu incidentu.

Šāda pieeja ļauj MI izmantot tur, kur tas tiešām palīdz: sagatavot implementācijas variantus, testu skeletus, dokumentāciju un atkārtojamu darbu. Taču uzņēmums saglabā neatkarīgu definīciju tam, ko uzskata par pareizu un pieņemamu. Ģenerētais kods drīkst būt ātrs; drošības pieņemšanas kritēriji nedrīkst mainīties atkarībā no tā, cik pārliecinoši modelis paskaidro savu rezultātu.

Izstrādes ātrumu var izmērīt pēc laika līdz izmaiņas pieņemšanai, taču ar šo metriku vien nepietiek. Ja funkcijas tiek radītas ātrāk, bet vēlāk jālabo vairāk defektu, jāveic avārijas atgriešanas vai pieaug drošības pārskatīšanas rinda, sākotnējais ieguvums var pazust. Noderīgi skatīt kopā laiku no uzdevuma līdz drošai izvietošanai, pārskatīšanas aizturi, atkārtoti atvērtās izmaiņas, pēcizlaiduma defektus, incidentus un neveiksmīgus izvietojumus. Šo datu interpretācijā jāņem vērā uzdevumu sarežģītība un komandas pieredze; tikai vienas nedēļas vai vienas komandas novērojums neļauj secināt, ka MI pats izraisījis uzlabojumu vai pasliktinājumu.

Jāuzmanās arī no metriku spēlēšanas. Testu skaits nav testu kvalitāte, atrasto skenera brīdinājumu skaits nav tiešs ievainojamību skaits, savukārt nulles incidentu periods nav pierādījums, ka kontroles darbojas. Daudz informatīvāk ir jautāt, vai iepriekš definētie kritiskie aizliegumi ir pārbaudīti, vai pārkāpumi bloķē izlaidumu un vai pierādījumus var atkārtoti pārbaudīt cilvēks, kurš nav piedalījies funkcijas ģenerēšanā.

MI asistēta izstrāde ir saprātīgs instruments agrīnām ideju pārbaudēm, izolētiem prototipiem, iekšējiem rīkiem ar skaidrām piekļuves robežām un atkārtojamām programmēšanas darbībām. Arī uzņēmumam kritiskā programmatūrā MI var būt noderīgs, ja komanda saglabā inženiertehnisku pārskatīšanu, draudu modelēšanu un kontrolētu izlaiduma procesu. Nopietns ierobežojums nepieciešams nevis tāpēc, ka kods ģenerēts ar MI, bet tāpēc, ka neizprastas izmaiņas iegūst piekļuvi sensitīviem datiem, naudas plūsmām, ražošanas infrastruktūrai vai drošībai kritiskām funkcijām.

Tāpēc vienlīdz aplami būtu gan aizliegt jebkuru MI ģenerētu kodu, gan pieņemt, ka pietiek ar jaudīgu modeli un pāris automātiskiem testiem. Pirmajā gadījumā uzņēmums var nepamatoti zaudēt produktivitātes iespēju, otrajā — pārvietot risku uz klientiem un incidentu reaģēšanas komandu. Pārdomāta politika nosaka, kādus uzdevumus drīkst deleģēt, kādā izolācijā, ar kādām pilnvarām un kādiem pierādījumiem jābūt pirms izlaiduma.

Vibe coding ir mainījis to, cik ātri iespējams iegūt funkcionējošu programmatūras pirmo versiju. Tas nav mainījis drošības pamatjautājumus: kurš var piekļūt datiem, ko sistēma drīkst izdarīt, kā to pārbauda un kā pierāda, ka pārbaudītais izlaidums ir tas pats, kas nonācis ražošanā. Ja uzņēmums šos jautājumus ir pārvērtis izpildāmās prasībās, automatizētos un manuālos testos, ierobežotās piekļuves tiesībās un pārbaudāmā piegādes ķēdē, MI kļūst par izmantojamu izstrādes instrumentu. Ja šādas sistēmas nav, demonstrācijas ātrums var tikai aizsegt nepabeigtu inženierdarbu.