Bug bounty programma: ko patiesībā optimizē laba programma?

Vispirms jāsaglabā viena robeža.

CVD dod ceļu vulnerability ziņošanai un koordinācijai.

Bug bounty šim modelim pievieno atlīdzības un pētnieku tirgus mehānismu.

Tāpēc bug bounty parasti papildus jādefinē:

• reward eligibility;
• bounty ranges;
• severity/impact loģika;
• duplicate noteikumi;
• pirmā ziņotāja princips;
• researcher reputation;
• dispute process;
• payment process;
• īpašas campaign/invite loģikas.

Atlīdzība nemaina pamatprasības:

• scope;
• atļautās metodes;
• minimāli nepieciešams PoC;
• datu minimizācija;
• droša disclosure koordinācija.

Plašāk CVD un bug bounty robeža ir aprakstīta atsevišķā rakstā.

Daudz reportu var nozīmēt:

• plašu attack surface;
• daudz aktīvu pētnieku;
• jauna scope pievienošanu;
• ļoti zemas kvalitātes submission plūsmu;
• vienu systemic issue sadalītu daudzos reportos;
• neatrisinātus known issues, kurus atkārtoti atrod citi pētnieki;
• AI/automation radītu triage slodzi.

Tāpēc:

Laba programma vairāk interesējas par:

nevis par ieejas plūsmas lielumu.

Tas ir svarīgi arī 2026. gada kontekstā, kad platformas publiski apraksta būtisku submission-volume pieaugumu un lielāku triage slodzi.5

Arī “mēs izmaksājām miljonu” nav pašpietiekams security metric.

Liela izmaksu summa var nozīmēt:

• vērtīgus findingus;
• plašu programmu;
• augstu bounties tirgus cenu;
• lielu pētnieku skaitu;
• agresīvu bonus campaign;
• vai vienkārši augstu cenu par problēmām, kuras organizācijas iekšējais SDLC turpina atkārtoti radīt.

Bounty budget ir jāskata pret rezultātu.

Piemēram:

• kādas asset klases saņēma pētnieku uzmanību;
• cik findingu bija jauni root causes;
• cik tika novērsti;
• vai variants atkārtojas;
• vai programma atklāja blind spots;
• vai findings mainīja secure-development kontroli.

Bug bounty nav pirkums:

“samaksājām par 100 bugs”.

Tas ir ārējas, konkurējošas pētnieku uzmanības tirgus.

Labs pētnieks var izvēlēties.

Viņš var savu vakaru, nedēļu vai mēnesi ieguldīt:

• tavā programmā;
• citas organizācijas bounty;
• privātā programmā;
• pentest darbā;
• vulnerability research savam portfolio;
• exploit development;
• open source;
• apmācībā.

Tāpēc pētnieka iespēju izmaksas ir reālas.

ENISA jau savos CVD ekonomikas pētījumos ir uzsvērusi, ka researcher motivation nav tikai nauda: to veido peļņa, reputācija, karjeras vērtība, izaicinājums, mācīšanās un ētiska motivācija.1

YesWeHack 2026. gada hunter aptaujā private-program invites kā prioritāti minēja apmēram puse respondentu; svarīgi bija arī bounty ranges, jauns scope, scope plašums un tehnoloģiju atbilstība pētnieka prasmēm.4

Šie skaitļi ir vienas platformas auditorijas aptauja, ne universāls pētnieku populācijas mērījums.

Taču tie labi ilustrē dizaina jautājumu:

kāpēc kompetentam pētniekam būtu jāizvēlas tieši tava programma?

Programma var būt juridiski korekta un vienlaikus pētniekam neinteresanta.

Piemēram:

Tehniski programma eksistē.

Ekonomiski tā maz ko piesaista.

Savukārt pārāk plats scope bez iekšējās triage/remediation kapacitātes var radīt pretēju problēmu.

HackerOne 2026. gada maturity framework uzsver skaidru asset scope, testing requirements un programmas spēju atbalstīt pētniekus; tā augstākās brieduma prakses pat paredz ļoti plašu internet-facing asset coverage tikai organizācijām, kurām tam ir pietiekama inventāra un triage kapacitāte.6

Tāpēc scope jāprojektē pēc formulas:

Ne tikai:

Nobriedušai bug bounty programmai vajag skaidru slāni arī starp scope un findingu.

Praktiska ķēde ir:

scope un policy → atļauja → reconnaissance / observation → ar evidence pamatots candidate → cilvēka validācija → finding → reports

Šī atšķirība ir svarīga, jo novērots endpoint, technology fingerprint, object identifier vai neparasta atbilde vēl nav ievainojamība. Tas ir pierādījums, kas var pamatot kontrolētu validācijas soli. Candidate jāsaglabā, no kurienes novērojums radās, kura scope norma bija piemērojama, kāda darbība to radīja un kuri nākamie soļi ir atļauti, bloķēti vai prasa apstiprinājumu.

Reconnaissance ir piemērota vieta ierobežotai automatizācijai. YesWeHack intervijā Rabhi apraksta recon automatizēšanu, dziļāku vulnerability testēšanu atstājot manuālu, un arī PortSwigger aktuālais workflow nošķir scope un attack-surface kartēšanu no ievainojamību testēšanas.1516

Tāpēc programmai jāoptimizē izskaidrojami kandidāti, nevis raw scanner volume. Discovery rīks pats nedrīkst paplašināt scope, un candidate nedrīkst kļūt par findingu, kamēr cilvēks vai līdzvērtīgi kontrolēts validācijas process nav pierādījis drošības nosacījumu.

Kad programmā tiek pievienots:

• jauns produkts;
• jauna API;
• jauna mobile versija;
• jauna AI funkcija;
• jauns authentication flow;
• jauns maksājumu process;

tas var būt daudz interesantāks par gadiem testētu aktīvu.

YesWeHack 2026. gada aptaujā nesen pievienotu scope prioritizēja 42% aptaujāto hunteru, bet sen ilgstoši scope bija daudz mazāk pievilcīgs.4

No tā neizriet, ka vecs scope vairs nav jātestē.

Tas nozīmē, ka programmai jāspēj atsvaidzināt pētnieka uzmanību:

• ar jaunu scope;
• temporary campaign;
• focus bounty;
• jaunu attack class;
• private invite;
• lielāku bounty noteiktam assetam.

Tādā veidā bounty darbojas kā attention allocation mechanism.

Slikta bounty politika saka:

“Reward depends on impact at our discretion.”

Tas dod organizācijai elastību.

Pētniekam tas dod cenu neziņu.

Labāka politika pasaka:

• ko nozīmē Low/Medium/High/Critical;
• vai cena mainās pēc asset criticality;
• vai tiek maksāts pēc CVSS vai faktiskās business impact;
• kā tiek vērtētas attack chains;
• kas notiek ar systemic issue;
• kā rīkojas ar zero-day vai known issue;
• kad iespējams bonus;
• kad bounty nepienākas.

HackerOne 2026. gada maturity framework iesaka objektīvākas bounty tabulas ar konkrētiem piemēriem un skaidri formulētu impact-based payment filozofiju.6

Intigriti līdzīgi iesaka reward policy skaidri aprakstīt duplicates, bonuses, custom rewards un faktorus, kas ietekmē galīgo bounty.11

Paredzamība ir daļa no atlīdzības.

Pētniekam nav jāzina precīzs cents pirms submission.

Viņam vajadzētu spēt prognozēt kārtu.

Viena no biežākajām problēmām bounty ekonomikā ir šāda:

Tas ir normāls ekonomisks stimuls.

To nevar atrisināt, izliekoties, ka tā nav.

Programmai jānošķir:

1. technical severity;
2. business/security impact;
3. reward policy;
4. internal risk treatment.

Tie var korelēt.

Tie nav identiski.

HackerOne dokumentācija severity izmanto arī bounty range strukturēšanai, bet pati platformas guidance nošķir severity no organizācijas gala risk-treatment lēmuma.89

Intigriti triage standarti līdzīgi uzsver, ka platformas severity ne vienmēr ir tas pats, kas findinga importance vai risk konkrētai organizācijai.13

Labs dispute nav:

pētnieks grib Critical, uzņēmums grib Medium.

Labs dispute ir:

kuri pierādītie preconditions, attack steps un impacts attaisno konkrēto novērtējumu?

Bug bounty ekonomika parasti balstās uz first-to-report.

Tas ir saprotams.

Divreiz maksāt pilnu bounty par vienu un to pašu root cause parasti nav jēgas.

Taču no tā neizriet:

duplicate = slikts researchers vai false finding.

Bugcrowd savā aktuālajā reward modelī pat piešķir noteiktus reputation/kudos punktus daļai augstākas prioritātes duplicates, ja oriģinālais findings tiek pieņemts.10

Intigriti 2026. gada submission-handling vadlīnijas duplicate definē pēc same underlying vulnerability / same fix principa. Ja root cause vai nepieciešamais fix ir cits, līdzīgs findings nav automātiski duplicate.12

Tas ir labs principa formulējums:

Iedomāsimies, ka pētnieks atrod vienu autorizācijas kļūdu.

Pēc tam izrādās, ka tā pati broken authorization funkcija izmantota 40 endpointos.

Ir divas sliktas galējības.

A. maksāt 40 pilnas bounties Tas stimulē mākslīgu report fragmentation.

B. samaksāt tikai par pirmo endpointu un ignorēt papildu analīzes vērtību Tas nestimulē researcheru parādīt systemic impact.

HackerOne platformas standarti šādās situācijās iesaka atlīdzību sasaistīt ar papildu vērtību, ne vienkārši reportu skaitu.9

Tāpēc reward modelim ir vērts atšķirt:

• first manifestation;
• root-cause identification;
• materially new impact;
• new asset class;
• new privilege boundary;
• new exploit chain;
• tikai vēl vienu tā paša defekta URL.

Tas samazina gan programmas izmaksu spēlēšanu, gan researcher frustrāciju.

Ja viens Critical findings 18 mēnešus paliek neatrisināts, pētnieki to turpina neatkarīgi atrast.

No programmas viedokļa tie ir duplicates.

No researcher viedokļa:

es patstāvīgi ieguldīju darbu un atradu reālu, joprojām exploitable problēmu.

Šeit sākas fairness problēma.

HackerOne 2026. gada maturity framework pat iesaka nobriedušām programmām dokumentēt, kā tās rīkojas ar ilgstoši neatrisinātiem duplicate findings, tostarp iespējamu time-bound deduplication window vai daļēju reward pēc ilgstošas exposure.6

Tas nav universāls nozares standarts.

Bet problēma ir reāla.

Ja organizācija gadiem saglabā vulnerability, duplicate cost nedrīkst pilnībā tikt pārbīdīts uz jauno pētnieku.

Pētnieks neiegulda tikai tehnisko laiku.

Viņš uzņemas arī gaidīšanas risku.

Ja programma:

• 30 dienas neatbild;
• 60 dienas diskutē severity;
• pēc trim mēnešiem pasaka duplicate;
• bounty izmaksā pēc pusgada;

tad faktiskā research economics kļūst sliktāka pat pie nomināli labas bounty tabulas.

HackerOne maturity guidance kā baseline min noteiktus first-human-response un triage response targets un uzsver regulārus status updates.6

Intigriti 2026. gada programmas dokumentācijā tāpat saista strukturētu un konsekventu submission handling ar efektīvu remediation, taisnīgu researcher evaluation un ilgtermiņa programmas kvalitāti.12

Tāpēc:

communication latency ir programmas ekonomisks parametrs.

Ja finding ir validēts un reward lēmums pieņemts, pētniekam nevajadzētu finansēt organizācijas iekšējo birokrātiju.

Payout process var prasīt:

• identity checks;
• nodokļu datus;
• sanctions/compliance checks;
• bankas vai payment-provider processing.

Tas ir normāli.

Programmai tomēr jāprojektē process tā, lai:

• bounty rezervēts;
• researcher zina statusu;
• nav negaidīta budget exhaustion;
• maksājuma termiņš ir saprotams.

Intigriti pat tehniski rezervē bounty summu validation laikā un automātiski suspendē programmu, ja atlikušais budžets kļūst par mazu, lai saglabātu spēju pētniekiem samaksāt.14

Tas ilustrē vienkāršu principu:

neuzaicini cilvēkus medīt bugs, ja neesi sagatavojis naudu par validētiem rezultātiem.

Publiska bug bounty platforma var dot tūkstošiem potenciālu pētnieku.

Tas nenozīmē, ka tūkstoši kvalitatīvi pētīs tavu produktu.

Vērtīgs ir arī cits efekts:

Ilgtermiņa pētnieks var kļūt daudz efektīvāks par cilvēku, kurš vienreiz noskenē landing page.

HackerOne 2026. gadā ieviesa atsevišķu Hacker Engagement dashboard ar unique researcher participation un saistītiem engagement signāliem, tieši uzsverot veselīga aktīvo pētnieku skaita nozīmi programmas darbībā.7

Taču retention nedrīkst kļūt par slēgtu klubu.

Programmai vajag abus:

• atkārtoti kvalitatīvus researcherus;
• iespēju ienākt jaunam talantam.

Ir vilinoši uzzīmēt:

kā obligātu maturity ladder.

Tā nav universāla patiesība.

Dažām organizācijām publiska programma ir piemērota.

Citām — ne.

Kritiski aktīvi, sensitīvi dati vai ļoti ierobežota production tolerance var pamatot:

• invitation-only modeli;
• vetted researchers;
• noteiktus test windows;
• identitātes pārbaudi;
• sandbox;
• īpašu monitoring;
• emergency stop.

ENISA savā CVD politikas pārskatā atzīmēja, ka bug bounty dažos apstākļos darbojas labi, bet sensitīvi dati, komercnoslēpumi un programmu izmaksas var būt reāli šķēršļi universālai pieejai.2

Pareizais jautājums nav:

“Vai mums vajag public bounty?”

Tas ir:

“Kādu ārējās izpētes modeli mūsu attack surface, riska tolerance un operacionālā kapacitāte spēj droši izmantot?”

Platformas izmanto reputāciju, signal, ranking un private invites.

Tas palīdz.

Pētnieks ar ilgstošu kvalitatīvu vēsturi var būt labs kandidāts:

• privātam scope;
• sarežģītam targetam;
• jaunas funkcijas campaign;
• kritiskākam aktīvam.

Taču:

Evidence joprojām nosaka findinga tehnisko patiesumu.

Reputācija var palīdzēt sadalīt uzmanību.

Tā nedrīkst aizstāt reproducēšanu.

Hall of Fame, CVE attribution, public thanks, challenge coins, private invites un testimonials var būt vērtīgi.

ENISA ekonomikas darbs reputāciju un karjeras vērtību tieši identificē kā reālus pētnieku stimulus.1

Taču organizācija nedrīkst izmantot:

“mēs tevi pieminēsim LinkedIn”

kā ekonomisku triku situācijā, kur tā faktiski sagaida dārgu profesionālu darbu un solīja bounty.

Monetāri un nemonetāri stimuli papildina viens otru.

Tie nav savstarpēji aizvietojami visos gadījumos.

Ja man būtu jāizvēlas viena vienība, es neskaitītu reports.

Es skatītos uz:

unikālu, verificētu security insight, kas noved pie konkrētas drošības stāvokļa izmaiņas.

Tas var būt:

• viens ļoti konkrēts bug;
• systemic root cause;
• jauna attack chain;
• jauns variants;
• arhitektūras security boundary defekts.

Šī vienība savieno bug bounty ar organizācijas drošību.

Citādi bounty viegli kļūst par paralēlu ticket factory.

Signal kvalitāte

• valid-report ratio;
• duplicate ratio;
• needs more information ratio;
• non-security/no-impact ratio;
• unique root-cause findings;
• material new-impact findings.

Pētnieku ekonomika

• first human response;
• triage time;
• bounty-decision time;
• payout time;
• dispute rate;
• severity-change rate;
• researcher return rate;
• kvalitatīvu researcheru retention.

Coverage

• cik kritisko assetu faktiski saņem pētnieku uzmanību;
• findingi pa asset class;
• findingi uz jauna scope;
• findingi uz ilgstoši netestētām daļām;
• private campaign coverage;
• jaunas vulnerability classes.

Remediation rezultāti

• time to mitigation;
• time to fix;
• percentage retested;
• failed-retest rate;
• reopened findings;
• repeat root causes;
• variants found after closure.

Programmas drošums

• accidental-impact incidents;
• scope disputes;
• data-handling incidents;
• rate-limit/DoS pārkāpumi;
• legal escalations.

Nevienu no tiem nevajadzētu izmantot kā vienu KPI.

Tie veido programmas stāvokļa ainu.

Ne kā matemātisku modeli, bet kā dizaina jautājumu es to formulētu šādi:

Svarīgi ir arī tas, ko formulā nav:

Reporti ir input.

Drošība ir outcome.

Pirms programmas atvēršanas es prasītu atbildes uz šādiem jautājumiem.

Scope

• Kas tieši ir in scope?
• Kas ir out of scope?
• Kuri third-party aktīvi nav mūsu pilnvarojumā?
• Kā researchers saņem test accounts?
• Kādas darbības ir aizliegtas?
• Kā notiek emergency stop?

Rewards

• Kā severity/impact pārtop bounty?
• Vai asset criticality maina reward?
• Kā vērtē attack chain?
• Kas ir duplicate?
• Kā vērtē systemic issue?
• Kā rīkojas ar known but unresolved finding?
• Kad iespējams bonus?

Operations

• Cik ātri būs first human response?
• Kas veic triage?
• Kas pieņem severity/reward lēmumu?
• Kā notiek dispute?
• Kāds ir payout process?
• Kas notiek, ja budget izsīkst?

Remediation gatavība

• Kas ir owner?
• Vai researcher var retestēt?
• Kā tiek risināti ilgstoši findings?
• Kad notiek disclosure?
• Kā finding nonāk Secure SDLC feedback loop?

Ja uz pēdējo bloku nav atbilžu, organizācija vēl nav gatava bug bounty.

Tā ir gatava tikai saņemt vairāk reportu.

Viena no sliktākajām bug bounty interpretācijām ir:

mēs nepaspējām droši uzbūvēt, lai crowd atrod.

Crowd ir ļoti labs instruments:

• ārējam skatpunktam;
• neparedzētiem attack chains;
• lielam tehniku daudzveidības spektram;
• production reality pārbaudei;
• ilgstošam “always on” pressure.

Tas nav aizvietotājs:

• threat modeling;
• secure coding;
• code review;
• SAST/DAST;
• dependency management;
• pentest;
• architecture review;
• access-control design;
• release gates.

ENISA savā national vulnerability programmes darbā pat formulēja šo diskusiju kā “paying by impact instead of work” pretstatā nepieciešamībai turpināt ieguldīt security by design un preventīvās kontrolēs.3

Labs bounty atrod atlikušās robežkļūdas.

Tas nav ārpakalpojums organizācijas atbildībai.

Ja researchers atrod IDOR, jautājums nav tikai:

kur ir šis endpoint?

Jautājums ir:

kāpēc authorization test to nepamanīja un kur vēl darbojas tas pats pattern?

Ja atrod SSRF:

kāds design control ļāva neuzticamam inputam sasniegt network fetch?

Ja atrod business-logic abuse:

kuru invariant produktu komanda nebija formalizējusi?

Tātad bounty outputam vajag:

Ja tas nenotiek, programma var gadiem maksāt par vienu un to pašu kļūdu klasi dažādās vietās.

Beigās es to reducētu līdz sešām lietām.

1. Pareiza pētnieku uzmanība

Ne maksimāls cilvēku skaits, bet pietiekama kompetence pareizajos aktīvos.

2. Jauns signāls

Ne maksimāls reportu skaits, bet unikāli findings un jauna security knowledge.

3. Taisnīga un paredzama ekonomika

Pētnieks saprot scope, reward, duplicates, timing un dispute noteikumus.

4. Zema koordinācijas berze

Ātra komunikācija, konsekvents triage un skaidrs lēmums.

5. Remediation conversion

Findingam jāmaina faktiskais produkta drošības stāvoklis.

6. Ilgtermiņa mācīšanās

Root cause jānonāk atpakaļ Secure SDLC, ne tikai Resolved statusā.

Šāda programma necenšas “nopirkt bugs”.

Tā izmanto ārēju pētnieku tirgu kā vienu no security assurance slāņiem.

Bug bounty programma nav laba tāpēc, ka tajā ir daudz hackeru.

Tā nav laba tāpēc, ka izmaksā lielas bounty.

Tā nav laba tāpēc, ka katru mēnesi ģenerē skaistu “Critical findings” grafiku.

Tā ir laba, ja spēj atkārtoti izdarīt kaut ko daudz grūtāku:

piesaistīt kvalitatīvu ārējo uzmanību tur, kur organizācijai tā visvairāk vajadzīga, taisnīgi atalgot jaunu security value un pārvērst findingu pārbaudītā drošības uzlabojumā.

Tāpēc programmas centrālā vienība nav bounty.

Tā nav arī reports.

Tā ir:

uzticams researcher → unikāls evidence → taisnīgs lēmums → remediation → retest → mācīšanās.

Ja šī ķēde strādā, bounty ir drošības instruments.

Ja nestrādā, tā ir tikai dārga reportu plūsma.

Avoti pārbaudīti 2026. gada 25. septembrī. Platformu programmas un reward noteikumi laika gaitā mainās. Šajā rakstā piedāvātā “objective function”, metriķu grupa un programmas dizaina modelis ir autora praktiska analīze, ne vienots HackerOne, Bugcrowd, Intigriti, YesWeHack vai ENISA standarts.

Šis raksts ir bug bounty un crowdsourced security programmu dizaina analīze, nevis konkrētas platformas vai reward politikas juridisks skaidrojums.