Pierādījumi ir svarīgāki par tekstu: minimālais standarts AI asistētam ievainojamības ziņojumam

Ģeneratīvais AI vāja reporta izskatu maina ātrāk nekā pierādījumu prasības. Ziņojums tagad var būt garš, gramatiski nevainojams un profesionāli strukturēts, lai gan tajā joprojām ir nepārbaudīts endpoint, nestrādājošs payload, noklusēts priekšnoteikums vai impact, kas nav demonstrēts.

Šīs izmaiņas sistēmiskā ekonomika ir analizēta atsevišķi rakstā AI slop nav tikai satura problēma — tā ir pārbaudes izmaksu problēma. Šis raksts paliek reporta robežā: kam jābūt patiesam, pirms vulnerability hypothesis ir gatava iesniegšanai?

AI asistētā darbplūsmā ir lietderīgi saglabāt skaidrus stāvokļus.

Modelis drīkst palīdzēt jebkurā no šiem posmiem.

Tas drīkst pateikt:

“Šis kods izskatās pēc iespējama path traversal.”

Tas drīkst ieteikt testu.

Tas drīkst izveidot payload kandidātu.

Tas drīkst palīdzēt sakārtot jau iegūtos request/response pierādījumus.

Bet tas nedrīkst nemanāmi pārvērst:

“varētu būt” par “ir”.

YesWeHack 2026. gada praktiskajā piemērā LLM pareizi identificēja DOM XSS klasi, bet uzģenerēja PoC, kuru aplikācijas filtrs bloķēja. Tikai pēc manuālas analīzes pētnieks izveidoja strādājošu payload.9 Tas ir ļoti labs piemērs: vulnerability hypothesis var būt pareiza, kamēr konkrētais pierādījums vēl ir nepareizs.

Te ir svarīgs terminoloģisks precizējums.

Drošības pētniecība vienmēr ir izmantojusi automatizāciju:

• fuzzing;
• scannerus;
• crawlerus;
• static analysis;
• symbolic execution;
• custom scripts;
• exploit harnesses;
• reproducēšanas testus.

AI šo instrumentu loku paplašina.

Tāpēc kvalitatīva prasība nav:

“Findingam jābūt atrastam manuāli.”

Prasībai jābūt:

“Reporteris ir personīgi pārbaudījis un saprot, ka iesniegtais pierādījums attiecas uz konkrēto targetu un dara tieši to, ko reportā apgalvo.”

Deterministisks Python skripts var būt labāks pierādījums par desmit manuāliem klikšķiem.

Fuzzeris var atrast reālu memory corruption.

Crash var būt reproducējams bez pilna exploit.

Race condition var prasīt simtiem atkārtojumu un statistisku reproducējamības aprakstu.

Svarīga ir verificēta causal chain, ne cilvēka roku skaits.

Šī problēma nav radusies ar LLM.

FIRST PSIRT Services Framework iesaka organizācijām publicēt minimumu kvalitatīvam vulnerability report; kā tipisku baseline min write-up, reproduction steps, pārbaudīto platformu un PoC. Framework atsevišķi izdala vulnerability reproduction kā PSIRT funkciju, lai pārbaudītu un saprastu nosacījumus, kas noved pie ievainojamā stāvokļa.1

AI neko fundamentāli nemaina.

Tas vienkārši padara daudz vieglāk uzrakstīt tekstu, kas izskatās pēc šāda reporta, neizdarot pašu verifikāciju.

Es izmantotu šādu principu:

Katram materiālam apgalvojumam reportā ir jābūt piesaistāmam novērojumam, atkārtojamam solim vai skaidri marķētam pieņēmumam.

No tā izriet praktisks minimums.

1. Scope un atļaujas konteksts

Reportā vai tā metadatos jābūt skaidram:

• kura programma/politika attiecas;
• kurš asset tika testēts;
• vai tests notika atļautajā laikā un režīmā, ja tāds noteikts;
• kuri programmas ierobežojumi ir būtiski findinga interpretācijai.

AI asistēta testēšana nemaina scope.

HackerOne pašreizējā politika tieši prasa, lai arī autonomous/semi-autonomous AI testing ievērotu programmas scope, automation, request-volume un rate-limit noteikumus.2

Latvijā CERT.LV platformas noteikumi tāpat sasaista ziņošanu ar konkrētu programmu un konkrēto resursu.12

Ja findings atrasts nejauši ārpus aktīva scope, tālākā testēšana nav automātiski atļauta tikai tāpēc, ka AI saka “critical”.

Plašāk CVD, bug bounty un pentesta robežas analizētas atsevišķā rakstā.

2. Precīza target identitāte

Nepietiek ar:

example.com is vulnerable.

Vajag tādu identitāti, kas ļauj saņēmējam atkārtot testu:

• host / URL / API route;
• mobilās lietotnes build;
• produkta versija;
• repo/commit, ja tas ir source finding;
• konfigurācija vai feature flag, ja tas ir būtiski;
• loma vai konta tips;
• testēšanas datums/laiks, ja sistēma strauji mainās.

AI bieži aizpilda trūkstošo kontekstu ar “parasti šādos gadījumos…”.

Reportā nevajag “parasti”.

Vajag to targetu, kuru tu pārbaudīji.

3. Preconditions

Daudzi pārspīlēti impact apgalvojumi rodas no noklusētiem priekšnoteikumiem.

Piemēram:

• vajadzīgs autentificēts konts;
• vajadzīga admin loma;
• vajadzīgs upura klikšķis;
• jāzina objekta ID;
• jābūt vienā tenantā;
• jābūt iespējotai konkrētai funkcijai;
• attack chain prasa citu ievainojamību;
• exploit darbojas tikai konkrētā browserī vai buildā.

Šie nosacījumi nav neērti sīkumi.

Tie ir findinga daļa.

Labs reports tos nepaslēpj, lai severity izskatītos augstāka.

4. Reprodukcijas soļi

Citai tehniski kompetentai personai jāspēj no reporta saprast:

1. no kāda stāvokļa sākt;
2. ko tieši nosūtīt vai izdarīt;
3. ko sagaidīt;
4. kā atšķirt veiksmīgu exploit no normālas sistēmas uzvedības.

HackerOne pašreizējie submission standards prasa reproducējamu, step-by-step impact un PoC.2 Intigriti reportu vadlīnijas uzsver, ka reprodukcijai vajadzīgajai informācijai jābūt pašā reportā, ne tikai screenshotā vai video.6

Labs tests:

Vai triageris var reproducēt findingu bez tā, ka viņam jāuzmin nākamais solis?

5. Minimāls PoC vai ekvivalents pierādījums

PoC nav obligāti exploit framework.

Atkarībā no findinga pietiekams pierādījums var būt:

• precīzs HTTP request/response pāris;
• divu paša kontrolētu kontu autorizācijas pārbaude;
• crash input + stack trace/sanitizer output;
• minimāls test script;
• event log;
• izmaiņa, kas notiek tikai pēc neatļautas darbības;
• atkārtojama race condition ar noteiktu success rate;
• video kā papildpierādījums, ja tekstā joprojām ir reproducēšanas soļi.

Intigriti 2026. gada triage standarts pēc noklusējuma prasa rakstisku step-by-step uzbrukuma demonstrāciju un “simplest possible demonstration”, kas pierāda exploitable behaviour un impact.7

Vārds simplest te ir svarīgāks par spectacular.

PoC mērķis nav pārsteigt.

Tas ir atbildēt uz šauru jautājumu:

Vai drošības robežu var pārkāpt tā, kā reportā apgalvots?

6. Actual vs expected behaviour

Labs reports pasaka abas puses.

Actual

Authenticated user A can retrieve object B belonging to user B by changing /api/orders/{id}.

Expected

Server-side authorisation should reject access to an object outside user A's authorised object set.

Expected behaviour nevajag izgudrot.

Tā pamats var būt:

• aplikācijas lomu modelis;
• programmas apraksts;
• API dokumentācija;
• konsekventa sistēmas uzvedība citā endpointā;
• drošības kontroles deklarācija;
• skaidra tenant isolation robeža.

Ja paredzamais security boundary nav zināms, to godīgi pasaka.

Tas ir labāk nekā AI uzģenerēts “the application should follow best practices”.

7. Demonstrētais impact un hipotētiskais impact jānodala

Šis ir viens no svarīgākajiem laukiem.

Demonstrēts impact

Tas, ko PoC faktiski parāda.

User A var nolasīt user B invoice title un amount.

Pamatots tālākais impact

Tas, kas loģiski izriet no pierādījuma ar skaidriem priekšnoteikumiem.

Ja tas pats server-side authorisation defekts attiecas uz citiem invoice ID, var būt iespējama plašāka cross-account ekspozīcija; tā netika masveidā pārbaudīta datu minimizācijas dēļ.

Spekulatīvs impact

Full database compromise, RCE, regulatory fines, complete account takeover.

Ja trešajam nav attack chain, to nepasniedz kā faktu.

AI ir ļoti labs plausiblu “worst-case” stāstu rakstīšanā.

Tas nav tas pats, kas pierādījums.

Daudzas platformas lūdz reportera severity vērtējumu.

HackerOne no 2026. gada 21. septembra programmās, kur severity ir obligāta, prasa to izvēlēties reporta iesniegšanas laikā.3 CERT.LV platformas noteikumi paredz ievainojamības ietekmes novērtēšanā izmantot starptautiski atzītu CVSS kalkulatoru.12

Tas nemaina vienu būtisku robežu:

CVSS score nepadara hipotēzi par validētu findingu.

FIRST CVSS v4.0 pats uzsver, ka Base score raksturo vulnerability severity, nevis organizācijas risku, un ka environment un threat context ir atsevišķi slāņi.13

Tāpēc AI asistētā reportā severity sadaļā es prasītu:

• CVSS versiju;
• vector string, ja lieto CVSS;
• īsu pamatojumu strīdīgajiem metrics;
• skaidru nošķīrumu starp demonstrēto un pieņemto impact;
• programmas specifisko scoring policy, ja tāda ir.

Ja triageris vēlāk maina severity, tas nenozīmē, ka report bija nederīgs.

Savukārt sistemātiski piepūsts severity ir kvalitātes problēma.

AI var ļoti pārliecinoši aprakstīt attack path, ignorējot to, ka produkcijā to bloķē cita kontrole.

HackerOne pašreizējie standards tieši prasa ņemt vērā real-world mitigations un defense-in-depth; ja mitigation eksistē, vajag praktisku exploit path, kas parāda, kāpēc findings joprojām ir derīgs.2

Tas nenozīmē, ka defense-in-depth “atceļ” pamatdefektu.

Bet reportam jāpasaka:

• kura kontrole bija ieslēgta;
• vai tā faktiski bloķēja exploit;
• vai to izdevās apiet;
• vai findings eksistē tikai neatbalstītā konfigurācijā;
• vai security boundary joprojām tiek pārkāpta citā veidā.

Konteksts nav triagera darbs vien.

Spēcīgākais PoC nav tas, kurš izvelk visvairāk datu. Ja viena kontrolēta atbilde jau pierāda autorizācijas kļūdu, tūkstošiem reālu ierakstu iegūšana parasti palielina risku ātrāk nekā tehnisko pārliecību.

Arī platformu noteikumi uzsver ekspozīcijas minimizēšanu un tikai tāda pierādījuma iegūšanu, kas vajadzīgs konkrētā defekta demonstrēšanai.512 GDPR lomas, pierādījumu glabāšana un personas datu aizsardzības pārkāpuma process detalizēti analizēti rakstā Personas dati ievainojamību izpētē.

AI asistēta reporting rada vēl vienu risku, kas nav saistīts ar hallucination.

Reporteris var paņemt:

• privātas programmas nosaukumu;
• neatklātu endpoint;
• session token;
• source fragmentu;
• customer data;
• PoC;
• iekšēju architecture detail

un iekopēt to ārējā AI servisā.

No reporting kvalitātes viedokļa tas var palīdzēt uzrakstīt labāku tekstu.

No confidentiality viedokļa tas var būt programmas noteikumu pārkāpums.

Bugcrowd Code of Conduct GenAI lietošanas sadaļā tieši prasa saglabāt confidential information un findingu konfidencialitāti.4 Intigriti arī ierobežo privātu programmu datu un vulnerability reproduction information iznešanu uz trešajām pusēm.5

Tāpēc AI workflow pirms prompta vajag atsevišķu jautājumu:

Vai man vispār ir atļauts šo informāciju ievadīt izvēlētajā modelī vai servisā?

AI tool izvēle ir daļa no opsec.

Labs reports var izrādīties duplicate.

Tas nenozīmē, ka vulnerability nebija reāla vai report bija slikts.

Ārējais pētnieks bieži nevar redzēt privāto reportu vēsturi.

Tāpēc “pierādi, ka tas nav duplicate” nevar būt universāls minimuma kritērijs.

Reporteris tomēr var pārbaudīt to, kas viņam ir pieejams:

• savu iepriekšējo reportu vēsturi;
• publiskos advisories;
• zināmu CVE vai vendor issue;
• vai vairāki endpointi nav viena root cause varianti, kuri programmas politika prasa apvienot.

AI īpaši viegli ģenerē “jaunus” reportus par vienu un to pašu pattern dažādos endpointos.

Programmas noteikumi nosaka, vai tie ir atsevišķi findingi vai viena root cause.

Arī šeit nevajag radīt mākslīgu industrijas konsensu.

Intigriti pašreizējais Code of Conduct prasa atklāt, kad un kā AI izmantots submission sagatavošanā.5

Citu platformu formulējumi var būt citādi.

Tāpēc mans minimuma standarts nav:

“Katram reportam obligāti jābūt AI disclosure banner.”

Tas ir:

ievēro konkrētās platformas/programmas disclosure prasības un saglabā pietiekamu darba provenance, lai tu pats vari atbildēt par katru reporta apgalvojumu.

Svarīgākais nav “AI detector score”.

Svarīgākais ir tas, vai reportera vārds zem ziņojuma nozīmē:

Es šo pārbaudīju. Es saprotu, ko iesniedzu.

Praktiski es vulnerability reportam izmantotu šādu struktūru.

reporter_attestation nav juridisks zvērests.

Tā semantika ir vienkārša:

Visi endpointi, payloadi, request/response rezultāti un apgalvotie exploitation soļi ir pārbaudīti pret norādīto targetu; hipotētiski turpinājumi ir marķēti kā hipotētiski.

Šis viens noteikums izgriež pārsteidzoši daudz AI slop.

Pirms reporta iesniegšanas es sev uzdotu šos jautājumus.

Tas ir minimums, ne maksimālais reporta formāts.

Arī “kvalitātes standarts” var aiziet par tālu.

Reportam nav obligāti jābūt:

• garam;
• perfektā angļu valodā;
• ar diagrammu;
• ar pilnu exploit chain līdz crown jewels;
• ar CVE kandidātu;
• ar remediation patch;
• ar “professional” AI stilu;
• ar video;
• ar trim screenshotu lapām;
• ar reportera minētu precīzu uzņēmuma finansiālo risku.

OWASP disclosure guidance uzsver pietiekamu informāciju, lai vulnerability varētu saprast un reproducēt, supporting evidence un impact — ne retorisku apjomu.11

Īss, precīzs, reproducējams reports ir labāks par 2000 vārdu teoriju.

Programmas pusē secinājums ir apzināti šaurs: evidence minimumam jābūt skaidram jau intake brīdī. Jānošķir insufficient evidence no pierādīta false positive, lētās preflight pārbaudes var automatizēt, bet gala secinājumam par drošības robežu jāsaglabā cilvēka validācija.110

Plašāki jautājumi par rindas kapacitāti, throttling, reputāciju, atvērtību un verifikācijas ekonomiku pieder rakstam AI slop nav tikai satura problēma, ne šim reporta standartam.

AI drošības pētniecībā nav jāaizliedz.

Tas jāieliek pareizā vietā pierādījumu ķēdē.

AI var palīdzēt atrast anomāliju.

Var palīdzēt uzbūvēt hipotēzi.

Var palīdzēt sagatavot testu.

Var palīdzēt analizēt kodu.

Var palīdzēt uzrakstīt reportu.

Bet brīdī, kad nospiež Submit, ziņojumam vairs nevajadzētu būt modeļa hipotēzei.

Tam jābūt reportera verificētam apgalvojumam ar reproducējamu pierādījumu un skaidri ierobežotu impact.

Īsāk:

A vulnerability hypothesis is not a vulnerability finding.

Un labs reports nav tas, kurš izklausās pārliecinoši.

Labs reports ir tas, kuru var pārbaudīt.

Platformu politikas un tehniskie avoti pārbaudīti 2026. gada 25. septembrī. Platformu noteikumi var mainīties, tāpēc konkrētā bug bounty/VDP programmā vienmēr primāri jāievēro aktuālie programmas noteikumi. Šajā rakstā piedāvātais “minimuma pierādījuma līgums”, reporta kartīte un pre-submission evidence gate ir autora praktisks modelis, ne FIRST, CERT.LV vai kādas bug bounty platformas oficiāls vienots standarts.

Šis raksts ir drošības pētniecības un vulnerability reporting prakses analīze, nevis individuāla juridiska konsultācija.