CVD, bug bounty un penetrācijas tests nav viens un tas pats

Coordinated Vulnerability Disclosure būtība ir organizēt ceļu no ievainojamības konstatēšanas līdz tās drošai paziņošanai, izvērtēšanai, novēršanai un, ja tas ir pamatoti, publiskošanai.

NIS2 12. pants prasa katrai dalībvalstij noteikt CSIRT, kas darbojas kā koordinators un uzticams starpnieks starp ievainojamības ziņotāju un potenciāli ievainojamā IKT produkta ražotāju vai pakalpojuma sniedzēju. Koordinatora uzdevumos ietilpst iesaistīto pušu identificēšana, palīdzība ziņotājam, publiskošanas termiņu saskaņošana un vairāku subjektu skarto ievainojamību koordinēšana.1

Arī ISO/IEC 29147 CVD un vulnerability disclosure apraksta caur ziņojumu saņemšanu, koordinēšanu un informācijas par novēršanu publiskošanu.2

Tas ir svarīgs nošķīrums.

CVD nepasaka, ka pētniekam obligāti jāveic pilns tehniskais tests. CVD pasaka, kā rīkoties ar ievainojamības informāciju un iesaistītajām pusēm.

Pētījums var sākties pirms CVD procesa. Ziņojums var ienākt nejauši atrastas ievainojamības dēļ. Viena ievainojamība var skart vairākus piegādātājus. Koordinators var būt vajadzīgs tieši tāpēc, ka ziņotājs pats nemaz nezina, kurš ir īstais adresāts.

CVD galvenā vērtība ir koordinācija.

Vulnerability Disclosure Policy jeb VDP ir organizācijas noteikts publisks ceļš ievainojamību ziņošanai.

Praksē laba VDP parasti pasaka vismaz:

• kādi resursi ir tvērumā;
• kur ziņot;
• kādas darbības ir pieļaujamas un kādas nav;
• kādu informāciju vajag ziņojumā;
• kā organizācija reaģēs;
• kā tiek risināta publiskošana;
• kādi nosacījumi attiecas uz pētnieka rīcību.

HackerOne savā VDP un bug bounty salīdzinājumā VDP raksturo tieši kā organizācijas vadlīnijas ārējiem ziņotājiem un kā būtiskas sastāvdaļas min scope, procesa aprakstu, ziņojumu izvērtēšanu un safe-harbour formulējumu.3

Taču VDP nav tas pats, kas CVD.

VDP ir vienas organizācijas politika. CVD ir koordinēšanas process.

VDP var būt daļa no CVD ekosistēmas. CVD var notikt arī tad, ja konkrētajam piegādātājam nav labi izveidotas publiskas VDP.

Latvijā CERT.LV platforma apvieno abus elementus: tā nodrošina nacionālo koordinācijas ceļu, bet resursu pārziņi platformā var izveidot savas programmas ar konkrētiem resursiem, prasībām un ierobežojumiem.4

Bug bounty programma parasti izmanto daudzus tos pašus elementus, ko VDP:

• definētu scope;
• noteikumus;
• ziņošanas kanālu;
• triage;
• severity vai impact izvērtēšanu;
• publiskošanas nosacījumus.

Atšķirība ir ekonomiska un operacionāla: programma paredz atlīdzību par noteiktiem kvalificētiem atradumiem.

Tas maina pētnieku motivāciju un programmas pārvaldību, bet nepārvērš atlīdzību par papildu pilnvarojumu.

Ja programma maksā 5000 EUR par kritisku ievainojamību, tas nenozīmē, ka pētnieks drīkst iziet ārpus scope, traucēt produkciju vai izmantot reālu klientu datus, lai pierādītu lielāku ietekmi.

Atlīdzības tabula pasaka, par ko maksā.

Scope un programmas noteikumi pasaka, ko drīkst darīt.

Latvijas CERT.LV CVD platformas 2026. gada noteikumi šo robežu formulē ļoti skaidri. CVD procesa ietvaros mantiska atlīdzība pēc noklusējuma nav paredzēta. Resursa pārzinis savā programmā var paredzēt Bug Bounty, un tad atlīdzība attiecas tikai uz konkrētās programmas ietvaros apstrādātajiem ziņojumiem.4

Tas ir labs piemērs, kā CVD un bug bounty var pārklāties, bet nav sinonīmi.

Pentestam raksturīga cita attiecību struktūra.

Organizācija apzināti pasūta testu. Pirms darba sākuma ir noteikts, ko drīkst testēt, kādos laikos, ar kādiem ierobežojumiem, kā rīkoties incidenta gadījumā, kas ir kontaktpersonas un kādi ir gala nodevumi.

NIST SP 800-115 testēšanas Rules of Engagement definē kā detalizētas vadlīnijas un ierobežojumus drošības testa izpildei, kas tiek noteikti pirms testa un dod testa komandai pilnvarojumu veikt definētās darbības bez nepieciešamības katrai no tām atsevišķi lūgt jaunu atļauju.5

Tas ir būtiski atšķirīgs sākuma punkts no neatkarīga pētnieka.

Pentestā pasūtītājs var iepriekš atļaut, piemēram:

• autentificētu testēšanu;
• noteiktu ievainojamību ekspluatāciju;
• privilēģiju eskalācijas pārbaudi;
• datubāzes piekļuves demonstrāciju ar testa datiem;
• noteiktu tīkla segmentu pārbaudi;
• sociālās inženierijas elementus, ja tie ir skaidri iekļauti uzdevumā.

Taču arī pentesterim pilnvarojums nav bezgalīgs.

ROE ir ne tikai atļauju saraksts. Tā ir robeža.

Latvijas regulējumā terminoloģijai ir praktiska nozīme.

Ministru kabineta noteikumi Nr. 397 atsevišķā nodaļā regulē NKDL subjektu ielaušanās testus un drošības skenēšanu. Tie nosaka gan testu veicējus, gan īpašas prasības IKT kritiskajai infrastruktūrai.6

Tādēļ nevajadzētu automātiski pārnest šīs normas uz jebkuru neatkarīgu vulnerability research situāciju.

Piemēram, 138. punktā paredzētā 48 stundu iepriekšējā informēšana attiecas uz konkrēti noteikto IKT kritiskās infrastruktūras drošības skenēšanas režīmu. Tā nav universāla prasība ikvienam drošības pētniekam, pirms viņš internetā pārbauda jebkuru ievainojamību.6

Tieši šādas kļūdas rodas, ja terminus sajauc.

Red team darbs bieži izmanto tos pašus tehniskos paņēmienus kā pentests. Mērķis tomēr ir cits.

Parasts pentests parasti cenšas pietiekami sistemātiski pārbaudīt iepriekš noteiktu sistēmu vai kontroles kopumu un dokumentēt atrastās vājās vietas.

Red team tests biežāk sākas no mērķa:

Vai kontrolēts pretinieks spēj sasniegt noteiktu kritisku rezultātu, izmantojot reālistisku uzbrukuma ķēdi?

Tāpēc red team var apvienot infrastruktūras, aplikāciju, identitātes, lietotāju, piegādes ķēdes un sociālās inženierijas elementus — ja tie ir skaidri autorizēti.

TIBER-EU šo atšķirību parāda īpaši labi. 2025. gada ietvars apraksta threat-intelligence-based red team testu kā kontrolētu, konkrētajai organizācijai pielāgotu uzbrukuma simulāciju dzīvajās produkcijas sistēmās, kas imitē reālu draudu dalībnieku taktikas, tehnikas un procedūras un aptver cilvēkus, procesus un tehnoloģijas.7

Finanšu sektorā DORA TLPT ir īpašs regulēts šā tipa testa režīms ar atsevišķām prasībām tvērumam, testētājiem un kompetento iestāžu iesaistei.8

Bug bounty nav TLPT. Pentests nav automātiski red team. Un red team nav attaisnojums bezgalīgam scope.

Šī tabula ir darbības režīmu salīdzinājums, ne juridiska kvalifikācijas formula.

Konkrētas tiesības vienmēr nosaka piemērojamās tiesības, faktiskie programmas vai līguma noteikumi un konkrētais resurss.

Šī ir viena no biežākajām vadības kļūdām.

Organizācija izveido publisku bug bounty un pieņem, ka līdz ar to tai vairs nevajag regulāru ielaušanās testēšanu.

Bounty modelis dod kaut ko ļoti vērtīgu: daudz dažādu pētnieku, dažādas hipotēzes, plašu laika logu un stimulu atrast neparastas kļūdas.

Tas nedod garantētu pārklājumu.

Neviens bounty hunter nav obligāti atbildīgs par to, lai:

• pārbaudītu visas būtiskās aplikācijas funkcijas;
• izietu cauri noteiktai kontroles matricai;
• notestētu katru privileģēto lomu;
• verificētu visu iepriekšējo findingu remediation;
• uzrakstītu vadībai vienotu secinājumu par visa tvēruma drošības stāvokli.

Pētnieks meklē atradumu, par kuru ir jēga ziņot un, bounty gadījumā, iespējams saņemt atlīdzību.

Pentesta komandai savukārt var būt līgumisks pienākums pārbaudīt arī vietas, kurās nekas kritisks netiek atrasts, un dokumentēt šo pārklājumu.

Tāpēc:

bug bounty optimizē unikālu atradumu plūsmu; pentests optimizē saskaņota pārbaudes tvēruma izpildi.

Organizācijai var būt vajadzīgi abi.

Arī pretējais salīdzinājums ir maldinošs.

Pentesteris nesaņem atlīdzību tikai tad, ja atrod kritisku ievainojamību.

Labs pentesta rezultāts var būt arī:

• apstiprinājums, ka konkrētās kontroles izturēja pārbaudi;
• vidējas ietekmes problēmu kopums;
• konfigurācijas nepilnības;
• nepietiekama segmentācija;
• vajadzība atkārtoti testēt remediation;
• secinājums, ka izvēlētās uzbrukuma hipotēzes nav izdevies realizēt.

Tas joprojām ir darba rezultāts.

Bounty ekonomikā “nekas jauns nav atrasts” parasti nav apmaksājams finding.

Tāpēc organizācijai, kas grib izmērīt kontroles pārklājumu, nevajadzētu savu prasību pārtulkot tikai bounty noteikumos.

Apskatīsim vienu piemēru.

Pētnieks konstatē IDOR/BOLA tipa autorizācijas kļūdu.

Lai to pierādītu, viņš mēģina piekļūt citam objektam ar manipulētu identifikatoru.

Publiskā VDP/CVD programmā noteikumi var atļaut izmantot tikai paša testa kontus un pieprasīt apstāties, tiklīdz piekļuve cita lietotāja objektam ir tehniski pierādāma.

Bug bounty programmā var būt tāda pati robeža, papildus nosakot atlīdzības kritērijus un duplicate noteikumus.

Pentestā klientam var būt speciāli sagatavoti vairāku lomu konti un atļauja pārbaudīt horizontālu un vertikālu piekļuves kontroli daudz plašāk.

Red team testā pati IDOR kļūda var būt tikai viens solis ceļā uz saskaņotu mērķi, piemēram, noteiktas kritiskas funkcijas kompromitēšanas simulāciju.

Paņēmiens ir viens.

Pilnvarojums nav viens.

Safe-harbour formulējums var mazināt nenoteiktību pētniekam, kurš ievēro programmas noteikumus. Šajā salīdzinājumā to ir precīzāk uztvert kā politikas slāni virs definēta scope, nevis kā ceturto testēšanas modeli vai pārnesamu pilnvarojumu attiecībā uz trešo pušu sistēmām, cilvēkiem vai datiem.

Plašāks jautājums par to, ko organizācija vispār var atļaut, kur paliek krimināltiesību robeža un kāpēc labticība neaizstāj atļauju, ir analizēts rakstā Labticīga kiberdrošības izpēte Latvijā.

CVD/VDP, bug bounty un ielaušanās testā tieši scope pārvērš vispārīgu modeļa nosaukumu praktiskā vienošanās režīmā. Tam jānosaka ietvertie resursi un identitātes, atļautās metodes un intensitāte, trešo pušu robežas, datu apstrādes noteikumi, stop condition un disclosure kārtība.

CERT.LV 2026. gada platformas noteikumi prasa pirms katras testēšanas iterācijas pārbaudīt programmas izmaiņas un samērot testēšanas metodes un intensitāti ar resursa veiktspēju.4 Tas labi parāda, kāpēc scope nav vienreiz izlasīts domēnu saraksts.

Testēšanas atļaujas un testa apturēšanas robežas detalizēti analizētas good-faith research rakstā, bet nejauša piekļuve citu personu datiem — rakstā Personas dati ievainojamību izpētē.

Mature security programme neizvēlas vienu no šiem mehānismiem kā uzvarētāju.

Tas lieto katru tur, kur tas dod citu vērtību.

CVD / VDP — atvērta ieeja neparedzētiem atradumiem

Ja cilvēks atrod problēmu, organizācijai vajag kanālu, kur to droši paziņot.

Tas ir pamata higiēnas slānis.

Bug bounty — paplašināta neatkarīgu pētnieku motivācija

Bounty ir jēga, ja organizācija spēj triage, ātri reaģēt, novērst atradumus un pārvaldīt duplicate, scope un atlīdzības strīdus.

Pretējā gadījumā tā var nopirkt reportu plūsmu, kuru pati nespēj apstrādāt.

Pentests — pārbaudāms pārklājums

Ja vajag atbildēt uz jautājumu “vai šis konkrētais tvērums tika sistemātiski pārbaudīts?”, vajag plānotu engagement.

Red team — aizsardzības spēju pārbaude pret reālistisku uzbrukuma ķēdi

Red team ir noderīgs, kad mērķis vairs nav tikai atrast tehnisku ievainojamību, bet pārbaudīt, vai organizācija spēj novērst, pamanīt un apturēt mērķētu uzbrukumu.

Tie ir papildinoši slāņi, ne konkurējoši produkti.

Latvijā šie nošķīrumi kļuvuši īpaši redzami.

Nacionālās kiberdrošības likuma 39. un 40. pants regulē koordinētu ievainojamību atklāšanu un novēršanu NKDL tvērumā, tostarp ziņojuma iesniegšanu kompetentajai kiberincidentu novēršanas institūcijai un ievainojamības novēršanas procesu.9

CERT.LV 2026. gada 1. augusta platformas noteikumi savukārt ļauj resursu pārziņiem publicēt programmas ar konkrētiem testējamiem resursiem, prasībām un ierobežojumiem, un atsevišķos gadījumos programmā paredzēt arī Bug Bounty atlīdzību.4

Paralēli MK noteikumi Nr. 397 atsevišķi regulē NKDL subjektu ielaušanās testus un drošības skenēšanu.6

Tātad pat vienas valsts regulējumā jau ir redzami dažādi slāņi:

koordinēta ziņošana; programmas līmeņa testēšanas noteikumi; iespējamā atlīdzība; pasūtīta ielaušanās testēšana.

Šo slāņu sajaukšana nerada vienkāršāku sistēmu. Tā rada neskaidrākas robežas.

Ja organizācija nevar aizpildīt šo tabulu, problēma nav programmas nosaukumā.

Problēma ir kontroles dizainā.

CVD, VDP, bug bounty, pentests un red team izmanto pārklājošas tehniskās prasmes, bet tie nav savstarpēji aizvietojami.

CVD dod koordinācijas ceļu.

VDP pasaka ārējam pētniekam, kā organizācija grib saņemt ziņojumus un kādās robežās tā ļauj testēt.

Bug bounty šim modelim pievieno mērķētu ekonomisku stimulu.

Pentests ir iepriekš pilnvarots un plānots pārbaudes darbs ar noteiktu pārklājumu un nodevumiem.

Red team simulē pretinieku, lai pārbaudītu ne tikai tehnisku ievainojamību esamību, bet arī aizsardzības, atklāšanas un reaģēšanas spējas.

Svarīgākais jautājums tāpēc nav:

“Vai šis ir ethical hacking?”

Svarīgākais jautājums ir:

“Kādā režīmā mēs strādājam, kur ir tā robežas un kas tieši dod pilnvarojumu nākamajai darbībai?”

Avoti pārbaudīti 2026. gada 25. septembrī. Rakstā lietotais piecu režīmu salīdzinājums ir autora praktiska klasifikācija. Tas nav mēģinājums radīt jaunas juridiskas kategorijas. Latvijas normatīvajos aktos lietotais termins ir “ielaušanās tests”; “pentests” rakstā izmantots kā nozares saīsinājums.

Šis raksts ir tehniskas, procesuālas un tiesiskā konteksta analīze, nevis individuāla juridiska konsultācija.