No Vibe Coding līdz Vibe Cybersecurity: kad mākslīgais intelekts sāk aizstāt kompetenci

Programmatūras funkcionālā pareizība un drošība ir divas atšķirīgas īpašības. Lietotne var veiksmīgi reģistrēt lietotājus, apstrādāt maksājumus un glabāt dokumentus, vienlaikus saturēt piekļuves kontroles kļūdas, nepietiekamu datu izolāciju vai nedrošu pieprasījumu apstrādi. Lietotājs to var arī nepamanīt, jo normālas darbības laikā šādas problēmas bieži neizpaužas.

Veracode 2026. gada pavasara pētījumā testēja MI ģenerētu kodu 80 uzdevumos, aptverot Java, JavaScript, C# un Python un četras konkrētas drošības vājumu kategorijas. Aptuveni 45% ģenerēšanas gadījumu neatbilda pētījumā izmantotajām drošības pārbaudēm. Šis rezultāts neļauj apgalvot, ka gandrīz puse visa MI radītā koda ir ievainojama.5 Tas parāda kaut ko pietiekami nopietnu arī bez šādas pārspīlēšanas: labs funkcionālais rezultāts vēl neapliecina drošu realizāciju.

Iedomāsimies nelielu uzņēmumu, kas ar MI palīdzību izveido klientu portālu. Lietotāji var autentificēties, apskatīt dokumentus un mainīt sava konta informāciju. Sistēma iztur parastos lietotāja saskarnes testus. Taču neviens nav pārbaudījis, vai lietotājs, mainot dokumenta identifikatoru pieprasījumā, nevar piekļūt cita klienta dokumentam. Nav arī skaidrs, kā tiek nodalītas organizācijas, kam pieder dažādi dati.

Uzņēmums pēc tam ar MI palīdzību izveido drošības pārbaudes skriptu, saņem pozitīvu pārskatu un uzskata, ka sistēma ir droša. Iespējams, pārbaudīts tikai tas, ko modelis pats ieteica pārbaudīt. Ja sākotnēji tika nepamanīta piekļuves kontroles robeža, tā var palikt nepamanīta arī automatizētajā auditā.

Šāds scenārijs ir ilustratīvs, nevis apraksts par konkrētu uzņēmumu. Tas parāda risku, ko veido kopīgs, nepārbaudīts pieņēmums izstrādē un drošības novērtējumā. Viena automatizēta procesa kļūdu otrs var neatklāt, īpaši tad, ja abos tiek atkārtoti tie paši pieņēmumi.

Drošības izpētē MI ģenerētas hipotēzes var būt ļoti noderīgas. Modelis var pamanīt aizdomīgu ievades apstrādi, neparastu datu plūsmu vai potenciāli nedrošu bibliotēkas izmantošanu. Pieredzējis pētnieks pēc tam pārbauda, vai attiecīgais kods vispār ir sasniedzams, kādi priekšnosacījumi nepieciešami problēmas izmantošanai, kādas drošības kontroles jau darbojas un vai secinājumam ir praktiska ietekme.

Bez šīs pārbaudes var rasties iespaidīgs ziņojums par kritisku ievainojamību, kuru nav iespējams reproducēt. Piemēram, statiskajā analīzē ir pamanīta nedroša funkcija, bet ražošanas sistēmā neviens ārējs ievades ceļš līdz tai nenonāk. Vai arī modelis atrod potenciāli bīstamu konfigurāciju, ignorējot kontroles, kuras attiecīgajā vidē šo risku novērš. Ziņojumā var būt korekta terminoloģija, ticams uzbrukuma apraksts un pat šķietami pārliecinošs labojums. Tomēr starp iespējamu kļūdu un pierādītu ievainojamību joprojām trūkst būtiskāko posmu.

2026. gadā tas vairs nav tikai teorētisks piemērs. Google martā publiski informēja par būtisku MI ģenerētu ziņojumu pieaugumu savā atvērtā pirmkoda ievainojamību atlīdzības programmā. Starp problēmām tika minēti nepareizi ievainojamību izmantošanas apraksti, kā arī atradumi, kuri identificēja programmēšanas kļūdu, bet neuzrādīja nozīmīgu drošības ietekmi. Google paaugstināja pierādījumu prasības atsevišķām atradumu kategorijām, tostarp paredzot precīzākus reproducēšanas pierādījumus vai jau pieņemtu labojumu.4

Līdzīgu spiedienu aprakstīja HackerOne. 2026. gada maijā platforma ziņoja, ka pēc jaudīgāku MI rīku parādīšanās nozarē ievainojamību ziņojumu apjoms bija pieaudzis vairāk nekā par 100%. Daļa iesniegumu bija vērtīgi, bet daļa saturēja dublikātus, nepietiekamus pierādījumus vai secinājumus, kurus nevarēja apstiprināt. Šis pieaugums nepasaka, cik cilvēku ir kļuvuši par kvalificētiem pētniekiem.3 Tas parāda, ka ziņojumu radīšanas kapacitāte var augt daudz straujāk par to apstrādes iespējām.

2026. gada janvārī curl projekta uzturētājs Daniels Stenbergs paziņoja par atlīdzības programmas pārtraukšanu. Viens no galvenajiem iemesliem bija nekvalitatīvu ievainojamību ziņojumu pieaugums. Iepriekš projektā par apstiprinātām ievainojamībām tika atzīti vairāk nekā 15% iesniegumu, bet 2025. gadā šis īpatsvars nokritās zem 5%. Uzturētājiem nācās tērēt laiku, lai izskaidrotu, kāpēc pārliecinoši formulēti apgalvojumi patiesībā neatklāj drošības problēmu.1

Ar šo faktu būtu vienkārši noslēgt rakstu un pasludināt, ka MI ir sabojājis drošības pētniecību. Diemžēl šāds secinājums nebūtu godīgs pret pārējiem notikumiem.

2026. gada aprīlī Stenbergs aprakstīja būtiskas pārmaiņas. Projekts martā bija atgriezies pie HackerOne kā ziņošanas kanāla, un jauno ziņojumu kvalitāte bija ievērojami augstāka. Apstiprināto ievainojamību īpatsvars atkal sasniedza aptuveni 15–16%, lai gan ziņojumu kopējais apjoms turpināja pieaugt. Viņš arī norādīja, ka MI palīdzība kļuvusi izplatīta gandrīz visos ziņojumos.2

Šis ir viens no vērtīgākajiem pretargumentiem vienkāršotai kritikai. MI var radīt daudz nevajadzīga darba, bet tas var arī palīdzēt atklāt īstas, sarežģītas ievainojamības. Abas parādības iespējams novērot vienas nozares un pat viena projekta ietvaros. Tāpēc vērtēt pētnieka kompetenci tikai pēc izmantotajiem rīkiem būtu aplami.

Daudz vairāk pasaka viņa spēja pierādīt, ko rīks ir atradis.

Vibe Cybersecurity problēmu nevajadzētu reducēt tikai uz bug bounty platformām. Tā var izpausties arī drošības konsultācijās, incidentu analīzē, drošības operāciju centros, atbilstības novērtējumos un programmatūras izstrādē.

Piemēram, konsultants ar MI palīdzību var sagatavot drošības audita pārskatu, kurā minēti pareizi standarti, pietiekami daudz profesionālu terminu un detalizēts ieteikumu saraksts. Taču, ja viņš nav pārbaudījis faktiskās piekļuves tiesības, konfigurācijas, datu plūsmas vai sistēmas darbību, pasūtītājs saņem dokumentu, kura pārliecinošais noformējums var pārsniegt tā pierādījumu vērtību.

Līdzīgi incidentu analīzē MI var piedāvāt ticamu notikumu ķēdi, balstoties uz nepilnīgiem žurnālfailiem. Ja cilvēks nezina, kuri datu avoti trūkst, kā interpretējami laika zīmogi vai kuras darbības nav reģistrētas, viņš var pasludināt kļūdainu incidenta cēloni. Pēc tam šo secinājumu iespējams izmantot nepareiziem drošības ieguldījumiem, kļūdainām izmaiņām konfigurācijā vai nepamatotiem apgalvojumiem par notikušo.

Atbilstības jomā pastāv līdzīgs risks. MI var palīdzēt sasaistīt kontroles ar standartu prasībām, bet pats kontroles apraksts nepierāda tās darbību. Ja politikā ir rakstīts, ka privileģētās piekļuves tiek regulāri pārskatītas, es prasītu pēdējās pārbaudes rezultātu, atklātās neatbilstības un pierādījumus par to novēršanu. Skaists kontroles apraksts šeit neko neaizstāj.

NIST mākslīgā intelekta risku pārvaldības materiālos aplūko arī kļūdainas, pārliecinoši pasniegtas MI atbildes. Šie dokumenti palīdz izprast risku, taču tie neatbrīvo organizāciju no pienākuma pašai definēt pieņemamus pierādījumus, atbildību un pārbaudes procesu. Brīvprātīgas risku pārvaldības vadlīnijas nav apliecinājums tam, ka konkrēta drošības pārbaude patiešām notikusi.6

Programmatūras izstrādē pazīstams tehniskā parāda jēdziens. Ātrs risinājums reizēm palīdz sasniegt vajadzīgo rezultātu, bet vēlāk pieprasa papildu darbu, lai sistēmu uzturētu vai sakārtotu. MI asistētā drošības izpētē es redzu līdzīgu problēmu, kuru varētu saukt par pārbaudes parādu.

Tas rodas, kad hipotēzes, secinājumi vai drošības novērtējumi tiek pieņemti un izmantoti tālāk bez pietiekamas validācijas. Viens cilvēks ģenerē iespējamu ievainojamību sarakstu, nākamais no tā sagatavo riska novērtējumu, vēl kāds izmanto šo novērtējumu prioritāšu noteikšanai. Dokumentu skaits aug, bet sākotnējā apgalvojuma patiesums joprojām nav pārbaudīts. Ja pēc tam atklājas kļūda, nākas atgriezties pie sākuma un pārskatīt visu no tās atkarīgo darbu.

Sliktākajā gadījumā kļūdu neviens arī nepamana. Organizācijas vadība saņem zaļu drošības statusu, komanda pāriet pie nākamajiem uzdevumiem, bet sākotnējais pieņēmums paliek spēkā. Tas ir bīstamāk par skaidri atzītu nezināšanu, jo nepamatota pārliecība samazina vēlmi kaut ko pārbaudīt.

Tomēr pārbaudes parāds nav automātiskas sekas MI izmantošanai. Labi organizēta automatizācija ar reprodukcijas testiem, neatkarīgu validāciju un dokumentētiem lēmumiem var šo darbu ievērojami samazināt. Izšķiroša ir procesa uzbūve, nevis rīka nosaukums.

Es nesāktu ar diplomiem, sertifikātiem, LinkedIn profilu vai jautājumu, kuru MI modeli pētnieks izmanto. Tie var sniegt kontekstu, bet nedod atbildi par konkrētā darba kvalitāti.

Drošības novērtējumam izvēlētos vienu būtisku atradumu un lūgtu tā autoram iziet cauri pilnai pārbaudes ķēdei.

Sākumā — sistēmas izpratne. Kas tieši tiek analizēts? Kur atrodas attiecīgā funkcionalitāte, kuri komponenti to izsauc un kādas uzticības robežas starp tiem pastāv? Vai autors spēj paskaidrot arhitektūru arī bez sagatavota MI kopsavilkuma?

Tālāk — hipotēzes pārbaude. Kas liecina par drošības problēmu, kādi ir tās izmantošanas priekšnosacījumi un kādi novērojumi šo hipotēzi atspēkotu? Ja modelis ir atzīmējis aizdomīgu koda fragmentu, vai autors var parādīt reālu izpildes ceļu līdz tam?

Pēc tam — reproducējamība. Vai ir iespējams drošā, autorizētā vidē atkārtot attiecīgo darbību un iegūt to pašu rezultātu? Vai ir saglabāti nepieciešamie pieņēmumi, programmatūras versijas, ievades dati un novērojumi? Kur beidzas novērojums un sākas interpretācija?

Svarīgākais — faktiskā ietekme. Ko ievainojamība ļauj izdarīt, kādas kontroles tai traucē un kādēļ konkrētais rezultāts rada drošības risku? Nedrīkst automātiski pieņemt, ka aizdomīgs koda fragments nozīmē kritisku ievainojamību.

Noslēgumā — labojums un atkārtota pārbaude. Vai ieteiktais risinājums novērš identificēto problēmu, neizjaucot citu funkcionalitāti? Kā to var pārbaudīt? Kurš pieņem lēmumu par atlikušo risku?

Šo piecu posmu pārbaudi piedāvāju kā praktisku autora modeli. Tā nav sertifikācijas shēma vai oficiāls NIST standarts. Tomēr tā ļauj diezgan ātri pamanīt, vai cilvēks izprot savu secinājumu vai tikai veiksmīgi atkārto gatavu tekstu.

Jāpatur prātā arī autorizācijas robežas. Spēja pierādīt ievainojamību nedod automātiskas tiesības testēt svešu sistēmu. Labi sagatavots pētnieks zina gan to, kā pārbaudīt hipotēzi, gan to, kad pārbaude jāpārtrauc.

Praktiskā robeža starp produktīvu MI izmantošanu un Vibe Cybersecurity nav jautājums par to, vai MI vispār tiek izmantots. Tā ir robeža starp palīdzību analīzē un secinājuma aizstāšanu.

MI var ļoti labi palīdzēt veidot hipotēzes, meklēt saistītus koda fragmentus, apkopot lielu datu daudzumu, sagatavot testu variantus, salīdzināt konfigurācijas un dokumentēt jau pārbaudītu rezultātu. Taču pats MI ģenerētais secinājums vēl nepierāda ne sasniedzamību, ne ekspluatējamību, ne autorizācijas esamību, ne faktisko biznesa ietekmi.

MI var paātrināt ceļu līdz pierādījumam. Tam nevajadzētu kļūt par pašu pierādījumu.

Profesionālai drošības sistēmai tādēļ jāspēj saglabāt arī secinājuma izcelsmi. No kurienes radās hipotēze? Kādi dati tika izmantoti? Kas tika pārbaudīts? Kāds bija negatīvais rezultāts? Kurš pieņēma lēmumu, ka atradums ir pietiekami pierādīts? Jo vairāk darba tiek automatizēts, jo svarīgāka kļūst šī pēctecība.

Manuprāt, MI var ievērojami paātrināt profesionāļa darbu, un būtu muļķīgi ignorēt tā sniegtās iespējas. Tas var palīdzēt analizēt lielas koda bāzes, atrast sakarības starp ievainojamībām, sagatavot testus un pārbaudīt alternatīvas hipotēzes. Cilvēkam, kurš saprot analizējamo sistēmu un zina savas metodes ierobežojumus, šādi rīki dod reālas priekšrocības.

Vienlaikus jaunās iespējas maina arī profesionālās uzticamības novērtēšanu. Agrāk sarežģīti noformēts tehniskais ziņojums varēja vismaz netieši liecināt par ieguldītu darbu. Tagad šādu tekstu iespējams radīt ļoti ātri, un tā noformējums pats par sevi vairs daudz nepasaka. Daudz vērtīgāka kļūst pierādījumu izcelsme, reproducējamība, analīzes robežu izpratne un spēja pieņemt pamatotu lēmumu situācijā, kurā rīka ieteikums izrādās nepareizs.

Arī iesācēju loma nav jānoniecina. Cilvēks, kurš ar MI palīdzību atradis reālu ievainojamību, spēj to droši reproducēt un korekti izskaidrot, ir devis vērtīgu pienesumu neatkarīgi no savas iepriekšējās pieredzes. Turpretī iespaidīgs profesionālais profils, sertifikātu saraksts un desmitiem ģenerētu pārskatu nav pietiekams pamats uzticēties nepārbaudītiem secinājumiem.

Es daudz labprātāk uzticētos pētniekam, kurš skaidri pasaka, ko viņš vēl nav spējis pārbaudīt, nekā cilvēkam, kurš uz jebkuru jautājumu nekavējoties sniedz pārliecinošu atbildi. Kiberdrošībā spēja atzīt nenoteiktību bieži ir daļa no profesionālas kompetences.

Vibe Coding parādīja, cik ātri iespējams nonākt līdz strādājošam programmatūras prototipam. Vibe Cybersecurity apzīmē nākamo risku: tikpat ātri iespējams nonākt līdz pārliecinošam drošības secinājumam. Abu rezultātu patiesā kvalitāte atklājas brīdī, kad kādam nākas tos neatkarīgi pārbaudīt.

Ja cilvēks apgalvo, ka sistēma ir droša, es vispirms prasītu parādīt, kā viņš līdz šim secinājumam nonāca. Un ko tieši viņš nepārbaudīja.