Profesionālais darbsCeļvedisKiberdrošība

CVD praksē: no ievainojamības ziņojuma līdz verificētai aizvēršanai

Kā ārējs vulnerability report kļūst par pārbaudītu findingu, remediation darbu, retestu un auditējami aizvērtu drošības jautājumu.

Zigmārs AncveirsTechnology Leader in FinTech & RegTech · Cybersecurity & Ethical HackingPublicēts: 2026. gada 26. septembrīPārskatīts: 2026. gada 26. septembrī13 min

Ievads

Daudzām organizācijām koordinēta ievainojamību atklāšana sākas ar e-pasta adresi.

security@example.com

Tas ir vajadzīgs.

Tas nav CVD process.

Īsts CVD process sākas tajā brīdī, kad kāds ārpus organizācijas iesniedz tehnisku apgalvojumu, kuru organizācijai jāpārvērš par pārbaudāmu, īpašniekam piesaistītu, novēršamu un beigās verificēti aizveramu drošības jautājumu.

Tas nozīmē daudz vairāk par reporta saņemšanu.

Praktiskā dzīves cikla minimums ir:

``text report → acknowledge → triage → reproduce → assign ownership → assess impact and urgency → remediate → retest → coordinate disclosure → close → learn ``

Šī secība izskatās vienkārša.

Reālajā organizācijā gandrīz katrs posms var izgāzties atsevišķi.

Reportu var neviens neizlasīt.

Triageris var nesaprast targetu.

Findingu var nevarēt reproducēt.

Engineering var salabot simptomu, ne root cause.

Patch var būt uzrakstīts, bet neizlaists produkcijā.

Pētnieks var retestēt citu versiju nekā tā, kas tika salabota.

Ticketu var aizvērt, lai gan security boundary joprojām ir salauzta.

Tieši tāpēc CVD ir jāprojektē kā dzīves cikls ar stāvokļiem un exit criteria, nevis kā inbox.

Divi standarti faktiski apraksta divas procesa puses

ISO/IEC 29147:2018 un ISO/IEC 30111:2019 ir labs sākuma pāris.

ISO/IEC 29147 fokusējas uz vulnerability disclosure: kā vendors saņem ziņojumus, komunicē ar ziņotājiem un izplata informāciju par ievainojamībām.1

ISO/IEC 30111 fokusējas uz vulnerability handling: kā vendors apstrādā un novērš ziņotas potenciālās ievainojamības produktā vai pakalpojumā.2

ISO publiskā informācija rāda, ka 29147:2018 tika atkārtoti apstiprināts 2024. gadā, bet 30111:2019 — 2025. gadā; abas versijas uz 2026. gada septembri joprojām ir spēkā esoši standarti, lai gan paredzēti pārskatīšanai.1 2

Šis sadalījums ir praktiski noderīgs:

CVD izgāžas, ja viena no šīm pusēm nav savienota ar otru.

Publisks disclosure kanāls bez iekšēja remediation procesa tikai ātrāk ievada problēmas organizācijā, kura tās nespēj pabeigt.

ārējā puse:
reporter ↔ coordinator/vendor
          ISO 29147

iekšējā puse:
vendor/PSIRT ↔ engineering/product/release
          ISO 30111

1. Intake: reportam vispirms ir jānokļūst pareizajā sistēmā

Pirmais procesa mērķis nav izlemt, vai researchers ir “labs” vai findings ir “critical”.

Tas ir daudz vienkāršāks:

nepazaudēt ziņojumu un piesaistīt tam izsekojamu case ID.

Intake slānim vajag:

vienu publiski atrodamu kanālu;
strukturētu reporta formu vai vismaz skaidru minimumu;
drošu iespēju sensitīva evidence nodošanai;
automātisku vai ātru saņemšanas apstiprinājumu;
case ID;
sākotnējo timestamp;
reporter contact vai anonimitātes režīmu;
skaidru incident-response eskalācijas ceļu.

NIST SP 800-216 tieši iesaka formalizēt potenciālu vulnerability reportu saņemšanu, izvērtēšanu un pārvaldību, nevis atstāt tos neformālā e-pasta plūsmā.3

FIRST multi-party koordinācijas vadlīnijas savukārt iesaka publicēt aktuālu security kontaktu un apstiprināt katras komunikācijas saņemšanu.5

Saņemšanas apstiprinājums nenozīmē:

“finding validated”.

Tas nozīmē:

“mēs to saņēmām, un tas nav pazudis”.

Exit criterion

RECEIVED drīkst pāriet uz nākamo stāvokli, ja:

reportam ir case ID;
saglabāts iesniegšanas laiks;
ir pietiekama informācija, lai identificētu targetu vai pieprasītu precizējumu;
ir noteikts sākotnējais process owner.

2. Acknowledgement: reporteri nedrīkst turēt neziņā

Labs acknowledgement ir īss.

Tam nav jāsola rezultāts.

Tam jāpasaka:

ka reports ir saņemts;
kāds ir case ID;
vai vajadzīga papildu informācija;
kas notiks tālāk;
kā notiks turpmākā saziņa.

FIRST iesaka uzturēt regulāru komunikāciju ar finder un informēt arī tad, ja mainās iespējamais disclosure termiņš.5

Tas ir operacionāli svarīgi.

Klusums veicina sliktu koordināciju:

Tātad acknowledgement nav pieklājības funkcija.

Tas ir coordination control.

reporter sees no response
→ assumes nobody is working
→ escalates
→ contacts more people
→ duplicates appear
→ publication risk increases

3. Triage: noteikt, kas mums vispār ir priekšā

Triage ir nevis severity scoring, bet klasifikācija.

Pirmajā tehniskajā pārskatā jāatbild vismaz uz šādiem jautājumiem:

vai target pieder organizācijai vai ir tās atbildībā;
vai reports attiecas uz atbalstītu produktu/versiju;
vai ir pietiekams evidence;
vai tas ir duplicate;
vai tas ir security finding, hardening suggestion vai expected behaviour;
vai ir pazīmes, ka notikusi reāla ekspluatācija;
vai jāiesaista incident response;
vai problēma skar trešo pušu komponentu vai vairākus vendorus;
kas ir tehniskais owner.

NIST SP 800-216 iesaka triāžā ņemt vērā ekspluatācijas vienkāršību, sistēmas ekspozīciju un tehniskās ietekmes smagumu, vienlaikus piesaistot šo informāciju reālajam sistēmas kontekstam.4

Svarīgs nošķīrums:

triage priority ≠ final risk decision

un:

severity ≠ validity.

Ja reports ir nepilnīgs, tas vēl nenozīmē false positive.

Pareizs statuss var būt:

NEEDS_INFORMATION

nevis:

INVALID.

Starp triage un reproduction ir atļaujas vārti

Ievainojamības reporta saņemšana rada koordinācijas uzdevumu. Tā pati par sevi nedod saņēmējam vai tā rīkiem atļauju sūtīt jaunus aktīvus pieprasījumus skartajai sistēmai.

Pirms aktīvas reproduction jānoskaidro skartais resurss un tā pārzinis, produkts vai versija, aktuālais scope vai cits pilnvarojums, duplicate statuss un jau iesniegtie pierādījumi. Pasīvus pierādījumus var normalizēt bez mijiedarbības ar mērķi. Aktīva reproduction sākas tikai tad, ja konkrēto darbību atļauj programma, līgums, resursa pārzinis vai cits piemērojams pamats un to pieļauj aktuālā policy.

Ja atļauja nav skaidra vai avoti konfliktē, drošais stāvoklis ir nekāda aktīva tīkla darbība. Tas saglabā robežu starp četriem modeļiem: CVD koordināciju, bug bounty dalību, pasūtītu ielaušanās testu un iekšēju drošības testēšanu.

Praktiska ķēde ir:

reports → scope un pilnvarojuma noskaidrošana → evidence normalizācija → triage → autorizēta reproduction → validation

Automatizācija var palīdzēt discovery un evidence apstrādē, bet tā nedrīkst klusi pārvērst disclosure inbox par neierobežotu skeneri. Arī publiskie testēšanas workflow sākas ar scope noteikšanu pirms attack surface kartēšanas un testēšanas.9 10

4. Reproduction: organizācijai pašai jāpārbauda security condition

Ārēja pētnieka reports nav tikai jāizlasa.

Tas, kur iespējams, ir jāreproducē.

Reproduction mērķis ir atbildēt:

Vai mūsu kontrolētā vidē, uz konkrētās versijas un ar noteiktajiem preconditions tiešām rodas aprakstītais security boundary pārkāpums?

Tas var prasīt:

request/response atkārtojumu;
divus testa kontus;
konkrētu produktu build;
konfigurācijas reprodukciju;
crash reproducer;
test harness;
logu vai telemetry pārbaudi.

FIRST PSIRT Services Framework vulnerability reproduction uzskata par atsevišķu PSIRT funkciju, kas palīdz pārbaudīt findingu un saprast nosacījumus, kuri noved pie ievainojamā stāvokļa.6

CERT.LV platformas 2026. gada noteikumi Latvijā prasa, lai ziņojums saturētu pietiekamu informāciju ievainojamā resursa identificēšanai un demonstrētu, kā ievainojamību var izpildīt pret konkrēto resursu ar PoC.8

Reproduction nav researcher eksāmens

Ja vendoram neizdodas atkārtot findingu, pareizā reakcija nav automātiski:

“cannot reproduce → invalid”.

Var būt:

atšķirīga versija;
WAF/CDN atšķirība;
reģionāla konfigurācija;
feature flag;
race condition;
reporter account state;
problēma jau nejauši salabota;
evidence nepietiekams.

Tāpēc CANNOT_REPRODUCE ir procesa stāvoklis, ne obligāti gala spriedums.

5. Incident-response override: finding var izrādīties noticis incidents

CVD un incident response nedrīkst sajaukt.

Taču tiem jābūt savienotiem.

Ja reprodukcijas vai logu analīzes laikā parādās pazīmes, ka ievainojamība:

jau ir ekspluatēta;
izmantota datu iegūšanai;
izmantota persistence;
saistīta ar aktīvu kampaņu;
skar kompromitētus akreditācijas datus;

tad process nedrīkst turpināties tikai kā parasts remediation tickets.

Vajag atsevišķu:

Tas nenozīmē, ka CVD case jāslēdz.

Abas plūsmas var darboties paralēli:

CVD koordinē vulnerability remediation un researcher communication;
incident response izmeklē kompromitāciju, containment, eradication un notification pienākumus.

Šis ir viens no svarīgākajiem “forkiem” procesā.

CVD case
      │
      ├─ no exploitation evidence → normal remediation
      │
      └─ exploitation evidence → incident-response escalation

6. Ownership: katram findingam vajag vienu atbildīgu remediation owner

“Security team knows about it” nav ownership.

Procesam vajag vienu identificējamu atbildīgo:

produkta owner;
service owner;
engineering lead;
vendor manager;
platform team;
PSIRT case owner.

Var būt desmit iesaistītie.

Tomēr jābūt vienam, kurš atbild par:

Kas tieši novedīs šo findingu līdz pārbaudītai novēršanai?

Ja ievainojamība skar trešās puses komponentu, ownership kļūst sarežģītāks.

Organizācija var nebūt tā, kas raksta patch.

Tā joprojām ir atbildīga par savu riska lēmumu:

workaround;
izolēšana;
feature disable;
compensating control;
update;
vendor escalation;
exposure reduction.

7. Priority: CVD termiņš nav tas pats, kas “visu labot vienādā laikā”

CVD koordinācijā vajag termiņus.

Taču termiņš nedrīkst kļūt par universālu risk score.

Latvijas NKDL 40. pants subjektiem nosaka ievainojamības novēršanai nepieciešamās darbības kompetentās institūcijas noteiktajā termiņā, bet ne vēlāk kā 90 dienu laikā pēc informācijas saņemšanas; objektīvu iemeslu gadījumā termiņu var pagarināt, bet ne vairāk kā līdz 180 dienām no ziņojuma iesniegšanas.7

CERT.LV platformas noteikumos 90 dienu periods izmantots arī kā vispārējais remediation references termiņš, ņemot vērā ievainojamības sarežģītību un kritiskumu.8

Tas nenozīmē:

“Critical arī drīkst gaidīt 90 dienas.”

Un nenozīmē:

“90. dienā automātiski jāpublicē.”

Organizācijas iekšējā priority var prasīt stundas vai dienas, ja:

notiek aktīva ekspluatācija;
ir publisks PoC;
skarta interneta robeža;
ietekme ir būtiska;
nav compensating control.

Par šo lēmumu loģiku atsevišķi: No ievainojamību saraksta līdz pamatotam lēmumam.

8. Remediation: jālabo root cause vai skaidri jāpasaka, ka to nedara

Remediation var būt:

code fix;
configuration change;
dependency update;
access-control izmaiņa;
feature disable;
architecture change;
compensating control;
workaround;
produkta izņemšana no ekspluatācijas.

Svarīgākais ir skaidri nošķirt:

fix — novērš ievainojamības cēloni;

mitigation — samazina exploitability vai impact;

workaround — pagaidu darbība, kas lietotājam jāveic;

risk acceptance — apzināts lēmums pagaidām nelabot.

Tie nav viens un tas pats stāvoklis.

FIRST PSIRT Framework remediation sadaļa uzsver remedy plānošanu, validāciju un informēšanu par to, kad labojums kļūst pieejams stakeholderiem.6

“Patch written” vēl nav remediation complete

Ja commit eksistē Git repozitorijā, bet:

nav release;
release nav izplatīts;
SaaS produkcijā nav deploy;
klientam nav pieejams update;
vulnerable component joprojām darbojas;

finding nav praktiski novērsts.

CVD closure vajag sasaistīt ar reālo piegādes modeli.

9. Retest: pārbaudīt security boundary, ne tikai patch eksistenci

Retest nav:

“developer saka, ka salabots”.

Retest arī nav vienkārši:

“scanner vairs nerāda findingu”.

Labs retest atkārto sākotnējo drošības apgalvojumu pret to stāvokli, kuru paredzēts uzskatīt par salabotu.

Piemēram:

sākotnējais findings

User A var piekļūt User B objektam.

retest

Pēc remediation User A ar sākotnējo exploitation ceļu un būtiskajiem variantiem vairs nevar piekļūt User B objektam; server-side authorization atgriež paredzēto rezultātu.

Pētnieks var būt ļoti vērtīgs retestā.

CERT.LV platformas noteikumi pat tieši paredz drošības pētniekam pienākumu savlaicīgi reaģēt uz jautājumiem un apstiprināt ievainojamības novēršanas faktu.8

Tas ir svarīgs process-signāls:

CVD dalībnieks nav tikai reporta autors.

Viņš var piedalīties closure evidence izveidē.

10. Retest var atklāt variantu vai nepilnīgu remediation

Ir vismaz četri iespējamie rezultāti:

Tie nedrīkst visi nonākt statusā RESOLVED.

Piemēram, developers salabo vienu IDOR endpointu ar klienta puses pārbaudi, bet citi endpointi izmanto to pašu backend authorization defektu.

Sākotnējais PoC vairs nestrādā.

Root cause joprojām pastāv.

Tāpēc retestam jāskatās ne tikai uz exact payload, bet arī uz security property.

A. FIX VERIFIED
B. MITIGATION WORKS, ROOT CAUSE REMAINS
C. PARTIAL FIX / VARIANT REMAINS
D. FIX INTRODUCES NEW ISSUE

11. Disclosure: remediation un publiskošana ir koordinējami, bet ne identiski notikumi

Publiskošanai var būt vairāki mērķi:

informēt lietotājus par update;
sniegt mitigation;
dot CVE/EUVD atsauci;
atzīt pētnieka ieguldījumu;
dokumentēt drošības uzlabojumu;
palīdzēt downstream vendoram saprast exposure.

FIRST multi-party vadlīnijas iesaka koordinēt disclosure termiņus, uzturēt saziņu ar finder un, ja nav pierādījumu par agrāku publisku disclosure vai aktīvu exploitation, nodrošināt saprātīgu embargo periodu izmeklēšanai un fix izstrādei.5

Latvijas CERT.LV platformā publiskojamās informācijas apjomu saskaņo ziņotājs un resursa pārzinis, CERT.LV pirms publicēšanas izvērtē saturu, bet pilna reporta publiskošanai nepieciešama iesaistīto pušu piekrišana.8

Svarīgais nošķīrums:

remediation deadline ≠ automatic disclosure deadline

un:

disclosure ≠ closure.

Advisory var būt publicēts, kamēr daļa downstream lietotāju joprojām nav uzlikuši fix.

12. Multi-party vulnerability: divpusējs workflow vairs nav pietiekams

Vienkāršais modelis ir:

Mūsdienu supply chain bieži izskatās šādi:

FIRST tieši norāda, ka open source, trešo pušu programmatūra, bug bounty programmu izplatība un sarežģītas piegādes ķēdes padara klasisko divpusējo koordināciju nepietiekamu.5

Multi-party gadījumā vajag:

lead coordinator;
stakeholder map;
versiju un dependency karti;
vienotu vai saskaņotu disclosure timeline;
drošu agrīno paziņošanu downstream pusēm;
skaidru embargo informācijas apriti;
novēršanas statusu pa katru produktu.

Te “kurš ir vendor?” vairs nav viens jautājums.

Tas ir grafiks.

researcher ↔ vendor

researcher
   ↓
coordinator
   ↓
upstream OSS project
   ↓
library vendor
   ↓
cloud service
   ↓
downstream product vendors
   ↓
end users

13. Closure: ticket statusam vajag pierādījumu

Es izmantotu šādu minimuma closure testu.

Finding drīkst aizvērt kā VERIFIED_CLOSED, ja:

identificēts skartais asset/produkts un versijas;
root cause vai precīzi definēta security condition ir dokumentēta;
remediation/mitigation lēmumam ir owner;
produkcijā vai izplatāmajā release ir ieviests paredzētais risinājums;
retests pārbauda sākotnējo security boundary;
zināmie būtiskie varianti ir izvērtēti;
incident-response jautājums, ja tāds bija, ir nodots attiecīgajam procesam;
disclosure/advisory lēmums ir dokumentēts;
reporteris/koordinators ir informēts par iznākumu atbilstoši procesam;
saglabāts minimālais audit evidence.

Ja ir tikai 1.–4. punkts, es to sauktu par:

REMEDIATION_IMPLEMENTED

nevis:

VERIFIED_CLOSED.

Tas ir autora praktisks process modelis, ne ISO statusu nomenklatūra.

“Resolved” nedrīkst būt semantiski tukšs

CERT.LV platformā resursa pārziņa pārstāvim jāmaina reporta statuss atbilstoši apstrādes gaitai — saņemto reportu uz Atvērts, bet pēc novēršanas uz Atrisināts.8

Iekšējā organizācijas sistēmā es zem šā viena ārējā statusa glabātu detalizētāku evidence:

Tas padara statusu auditējamu.

remediation:
  type: root_cause_fix | mitigation | workaround | risk_acceptance
  artifact: release / commit / configuration / control
  deployed_to:
  deployed_at:

retest:
  performed: true/false
  performed_by:
  target_version:
  original_path_blocked: true/false
  variants_checked:
  result:

closure:
  owner:
  decision_at:
  disclosure_status:
  residual_risk:

CVD process nedrīkst mēģināt atrisināt visu

Vēl viena nobrieduša procesa pazīme ir spēja pateikt:

šis jautājums pieder citai plūsmai.

Piemēram:

Šie procesi var savienoties.

Tie nav jāsapludina vienā mega-ticketā.

CVD process nedrīkst mēģināt atrisināt visu
Situācija	Primārais process
ārējs potenciāls vulnerability reports	CVD
aktīvas kompromitācijas pazīmes	incident response
neatjaunināta zināma CVE konkrētā assetā	vulnerability management
līgumiski pasūtīts tests	pentest/remediation workflow
bug bounty atlīdzības strīds	programmas reward/dispute process
personas datu breach	privacy/breach assessment
supply-chain multi-vendor finding	multi-party coordination

Vienkāršs CVD state machine

Praktiski organizācijai pietiek sākt ar kaut ko šādu:

Paralēlais zars:

Multi-party zars:

Nav svarīgi lietot tieši šos statusu vārdus.

Svarīgi, lai katrs statuss nozīmētu kaut ko pārbaudāmu.

SUBMITTED
   ↓
RECEIVED
   ↓
TRIAGE
   ├── NEEDS_INFORMATION
   ├── OUT_OF_SCOPE
   ├── DUPLICATE
   ├── NOT_A_SECURITY_ISSUE
   └── VALIDATED
            ↓
        OWNED
            ↓
      REMEDIATION
       ├── MITIGATION_ONLY
       ├── BLOCKED_EXTERNAL
       └── FIX_READY
            ↓
          RETEST
       ├── FAILED_RETEST
       ├── PARTIAL_FIX
       └── VERIFIED
            ↓
       DISCLOSURE_DECISION
            ↓
      VERIFIED_CLOSED

ANY STATE
   ↓ if exploitation evidence
INCIDENT_RESPONSE

VALIDATED
   ↓ if shared component / multiple vendors
COORDINATION
   ↓
per-vendor remediation + disclosure

Ko mērīt

CVD programmas kvalitāti nevajag mērīt tikai ar:

“cik reportu saņēmām?”

Noderīgāki rādītāji:

time to acknowledge;
time to first technical triage;
percentage reproducible without clarification;
time to assign owner;
time to mitigation;
time to fix available;
time to fix deployed;
retest success rate;
reopened-after-fix rate;
duplicate rate;
percentage requiring multi-party coordination;
researcher response latency;
percentage closed with verified retest;
cases escalated to incident response;
stale cases without owner.

Arī te uzmanīgi:

metric nav mērķis pats par sevi.

Ja organizācija optimizē tikai “time to close”, tā var sākt slēgt ticketus ātrāk, nevis kļūt drošāka.

Minimālais CVD case record

Es saglabātu vismaz:

Šis nav “vēl viens compliance dokuments”.

Tas ir minimums, lai pēc sešiem mēnešiem varētu atbildēt:

Ko mēs saņēmām, ko pārbaudījām, ko izdarījām un ar ko pierādījām, ka jautājums tiešām ir aizvērts?

case_id:
received_at:
reporter_reference:
program_or_channel:
affected_asset:
affected_version:

report_claim:
evidence_received:
reproduction_status:
reproduction_environment:
preconditions:

security_boundary:
demonstrated_impact:
incident_response_required:

owner:
priority_decision:
remediation_type:
remediation_artifact:
deployment_state:

retest_status:
retest_target:
retest_evidence:

disclosure_plan:
disclosure_status:

closure_decision:
closed_at:
residual_risk:
lessons_or_regression_test:

Latvijas modelis jau satur vairākus svarīgus dzīves cikla elementus

Latvijas Nacionālās kiberdrošības likuma 39. pants nosaka, ka ziņotājs ievainojamības ziņojumu iesniedz nekavējoties, bet ne vēlāk kā piecu darbdienu laikā, un definē ziņojuma minimumu.7

Kompetentā institūcija:

apstiprina saņemšanu;
pārbauda reportā ietverto informāciju;
informē ziņotāju par informācijas pamatotību;
informē par remediation rezultātu.7

pants pievieno:

remediation termiņu;
iespēju to noteiktos apstākļos pagarināt;
atbalstu saziņā;
pēckontroli;
multi-party un pārrobežu koordināciju.7

Tas nozīmē, ka likuma modelis pats par sevi nav tikai “send report”.

Tajā jau ir dzīves cikla elementi.

Organizācijas uzdevums ir tos pārvērst reālā engineering workflow.

Secinājums

CVD nav vulnerability inbox.

Tas ir mehānisms, kas pārvērš ārēju drošības signālu par pārbaudītu organizācijas rīcību.

Labs process spēj atbildēt uz visiem šiem jautājumiem:

Vai mēs reportu saņēmām?

Vai mēs sapratām, ko tas apgalvo?

Vai spējam to reproducēt?

Vai notikusi reāla ekspluatācija?

Kam pieder remediation?

Ko tieši labojam — root cause, simptomu vai tikai exposure?

Vai fix ir izlaists tur, kur vulnerability reāli eksistēja?

Vai kāds to retestēja?

Vai disclosure ir koordinēta?

Vai closure ir pierādāma?

CVD kļūst nobriedis nevis tad, kad organizācija var pateikt:

“Mums ir security@ adrese.”

Bet tad, kad tā var paņemt jebkuru aizvērtu case un pēc mēnešiem pierādīt:

report → validation → owner → remediation → deployment → retest → closure.

Tieši tā ir atšķirība starp vulnerability disclosure kanālu un vulnerability disclosure sistēmu.

Biežāk uzdotie jautājumi

Vai CVD un vulnerability management ir viens un tas pats?

Nē. CVD koordinē ārēji vai citādi ziņotu ievainojamību saņemšanu, validāciju, saziņu un disclosure. Vulnerability management parasti aptver plašāku iekšējo ievainojamību inventāru un prioritizāciju. Abiem procesiem jāsavienojas remediation posmā.

Vai reports jāaizver, tiklīdz developers saka, ka fix ir gatavs?

Nē. Fix ready un verified closed ir atšķirīgi stāvokļi. Jāpārbauda, ka paredzētais labojums ir sasniedzis faktiski skarto vidi vai release un ka security condition vairs nav reproducējama.

Vai retestu obligāti jāveic tam pašam pētniekam?

Nē. To var veikt PSIRT, iekšējā security komanda, QA, cits pilnvarots testers vai sākotnējais finder. Būtiski ir tas, lai retests būtu pietiekami neatkarīgs no pieņēmuma “mēs uzrakstījām patch, tātad viss salabots” un pārbaudītu sākotnējo security boundary.

Vai 90 dienas ir universāls CVD disclosure termiņš?

Nē. Latvijas NKDL 90 dienu termiņš attiecas uz noteikto remediation procesu subjektiem, ar iespēju noteiktos apstākļos pagarināt līdz 180 dienām.7 Tas nav universāls noteikums, ka katra vulnerability jāpublisko tieši 90. dienā.

Ko darīt, ja finding izrādās jau ekspluatēts?

CVD case jāsaglabā, bet vienlaikus jāaktivizē incident-response process. Vulnerability remediation un kompromitācijas izmeklēšana ir saistītas, bet atšķirīgas plūsmas.

Kad multi-party koordinācija kļūst nepieciešama?

Ja viena vulnerability skar vairākus vendorus, shared component, OSS projektu, cloud/SaaS piegādātāju vai vairākas valstis. FIRST iesaka šādos gadījumos izmantot koordinējošu struktūru un iepriekš veidot upstream/downstream komunikācijas kanālus.5

Avotu statuss

Avoti un Latvijas juridiskais statuss pārbaudīti 2026. gada 25. septembrī. Šajā rakstā izmantotā state-machine nomenklatūra, VERIFIED_CLOSED kritēriji un minimālais case record ir autora praktisks procesa modelis, ne ISO, FIRST, NIST vai CERT.LV oficiāla statusu vārdnīca.

Šis raksts ir CVD un vulnerability-handling procesa analīze, nevis individuāls juridisks padoms.