Coordinated Vulnerability Disclosure in Practice: From Report to Verified Closure

How an external vulnerability report becomes a validated finding, owned remediation, retested security state and auditable closure.

Zigmārs AncveirsTechnology Leader in FinTech & RegTech · Cybersecurity & Ethical HackingPublished: 26 September 2026Reviewed: 26 September 202615 min

Introduction

Many organisations begin vulnerability disclosure with an email address:

security@example.com

That is useful.

It is not a CVD process.

A real coordinated vulnerability disclosure process begins when somebody outside the organisation submits a technical claim that must be transformed into a validated, owned, remediated and verifiably closed security issue.

The minimum lifecycle looks something like this:

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

The diagram is simple.

The operating system behind it is not.

A report can be lost.

A triager can misunderstand the target.

The issue can fail to reproduce.

Engineering can patch one symptom rather than the root cause.

A fix can exist in source control while never reaching production.

A researcher can retest the wrong version.

A ticket can be marked resolved even though the security boundary is still broken.

That is why CVD should be designed as a stateful lifecycle with exit criteria, not as an inbox.

ISO 29147 and ISO 30111 describe two sides of the same system

ISO/IEC 29147:2018 focuses on vulnerability disclosure: receiving reports, disclosure policies, communication and publication of vulnerability information.1

ISO/IEC 30111:2019 focuses on vulnerability handling: processing and remediating reported potential vulnerabilities in products and services.2

ISO's public catalogue says ISO/IEC 29147:2018 was reviewed and confirmed in 2024 and ISO/IEC 30111:2019 in 2025; both remain current as of September 2026, although each is scheduled for revision.1 2

Operationally, the split is useful:

CVD fails when the two sides are disconnected.

A polished disclosure page does not create resilience if the internal organisation cannot reproduce, own and fix what arrives.

external side:
reporter ↔ coordinator/vendor
          ISO 29147

internal side:
vendor/PSIRT ↔ engineering/product/release
          ISO 30111

1. Intake: do not lose the report

The first job is not to decide whether the researcher is trustworthy or whether the vulnerability is critical.

It is simpler:

capture the report in a trackable system and assign a case identifier.

Useful intake controls include:

one discoverable reporting route;
a structured form or clear minimum report requirements;
secure transfer for sensitive evidence;
automatic or rapid acknowledgement;
a case ID;
immutable receipt time;
reporter contact or an anonymity path;
a defined escalation path for signs of active compromise.

NIST SP 800-216 recommends formalising the receipt, assessment and management of vulnerability reports rather than treating them as unstructured correspondence.3

FIRST's multi-party coordination guidance also recommends maintaining current security contacts and acknowledging receipt of communications.5

Acknowledgement does not mean:

vulnerability confirmed.

It means:

the report has entered a managed process.

Exit criterion

A case should not leave RECEIVED until:

it has a case ID;
receipt time is recorded;
the target can be identified or clarification has been requested;
an initial process owner exists.

2. Acknowledgement is an operational control

A good acknowledgement can be short.

It should tell the reporter:

the report was received;
the case identifier;
whether more information is needed;
the next expected step;
how communication will continue.

FIRST recommends regular communication with the finder, including updates when expected disclosure timing changes.5

Silence creates predictable coordination failure:

Acknowledgement is therefore not customer-service polish.

It reduces coordination entropy.

reporter sees no response
→ assumes no action
→ escalates
→ contacts additional people
→ duplicates appear
→ publication risk increases

3. Triage: identify what kind of case this is

Initial triage is broader than severity scoring.

It should answer questions such as:

Is the target ours or within our responsibility?
Is the affected product/version supported?
Is there enough evidence to analyse?
Is it a duplicate?
Is it a security issue, hardening suggestion or intended behaviour?
Is there evidence of real-world exploitation?
Should incident response be engaged?
Does a third-party component or multiple vendors appear involved?
Who is the technical owner?

NIST SP 800-216 recommends considering apparent exploitability, exposure and technical impact when prioritising incoming reports, with contextualisation for the affected environment.4

Two distinctions matter:

triage priority is not the same thing as final risk, and

severity is not the same thing as validity.

An incomplete report may belong in:

NEEDS_INFORMATION

rather than:

INVALID.

Between triage and reproduction, authorization is a gate

Receiving a vulnerability report creates a coordination task. It does not, by itself, give the recipient or its tooling authority to send new active requests to the affected system.

Before active reproduction, the workflow should resolve the affected asset and owner, product or version, current scope or authority, duplicate status and the evidence already supplied. Passive evidence can be normalised without interacting with the target. Active reproduction should begin only when a programme, contract, asset owner or other applicable authority permits the specific action and the current policy allows it.

If authority is unknown or conflicting, the safe state is no active network action. That keeps four models separate: coordinating a disclosure, participating in a bug bounty, performing a commissioned penetration test and carrying out internal security testing.

A useful operational chain is:

report → scope and authority resolution → evidence normalisation → triage → authorised reproduction → validation

Automation can help with discovery and evidence handling, but it must not silently turn a disclosure inbox into an unrestricted scanner. Public testing workflows likewise start by setting scope before mapping and testing the attack surface.9 10

4. Reproduction: the recipient should verify the security condition

Where reasonably possible, an external report should be reproduced.

The question is:

In a controlled environment, on the relevant version and under the stated preconditions, does the claimed security boundary actually fail?

That may involve:

repeating an HTTP request;
two controlled accounts;
a specific build;
a matching configuration;
a crash reproducer;
a test harness;
log or telemetry review.

FIRST's PSIRT Services Framework treats vulnerability reproduction as a dedicated function used to validate reports and understand the conditions leading to the vulnerable state.6

Latvia's CERT.LV platform similarly requires enough information to identify the affected resource and a PoC demonstrating how the vulnerability can be exercised against that specific resource.8

“Cannot reproduce” is not automatically “invalid”

A failed first reproduction can have many causes:

version mismatch;
WAF/CDN behaviour;
regional deployment difference;
feature flags;
race conditions;
researcher-account state;
an untracked fix;
incomplete evidence.

CANNOT_REPRODUCE is therefore a process state, not necessarily a final truth claim.

5. Add an incident-response override

CVD and incident response are different processes.

They must still connect.

If reproduction or telemetry shows that the vulnerability:

has already been exploited;
was used to obtain data;
established persistence;
is part of an active campaign;
is associated with compromised credentials;

the case should not remain only a remediation ticket.

A practical fork is:

The CVD case does not need to disappear.

Two workstreams can continue:

CVD manages the vulnerability, researcher communication and disclosure;
incident response investigates compromise, containment, eradication and notification obligations.

A mature CVD workflow knows when it has discovered an incident.

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

6. Every validated finding needs an owner

“Security knows about it” is not ownership.

A validated case needs one accountable remediation owner, for example:

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

Many people may contribute.

One person or role should remain accountable for:

What will take this finding from validated to verified closure?

Third-party vulnerabilities make this more difficult.

Your organisation may not be able to write the upstream patch.

It still owns its own treatment decision:

deploy workaround;
reduce exposure;
disable a feature;
add a compensating control;
update the dependency;
escalate to vendor;
accept residual risk.

Ownership cannot be outsourced merely because code ownership is external.

7. Remediation timelines are not universal risk scores

CVD needs time expectations.

Those expectations should not flatten risk.

Latvia's National Cybersecurity Law requires covered entities to take necessary remediation action within the period set by the competent institution, no later than 90 days after receiving the information. For objective reasons, the period can be extended, but not beyond 180 days from submission of the vulnerability report.7

CERT.LV's current platform rules likewise use up to 90 days as the general remediation reference, taking vulnerability complexity and criticality into account.8

That does not mean:

A critical actively exploited issue may wait 90 days.

It also does not mean:

Day 90 is automatically public-disclosure day.

Internal treatment may need hours or days where:

exploitation is active;
a public PoC exists;
the attack surface is internet-exposed;
impact is severe;
compensating controls are absent.

For the prioritisation problem, see From Vulnerability Backlogs to Defensible Decisions.

8. Remediation needs precise semantics

A case can be treated through:

code fix;
configuration change;
dependency update;
access-control change;
feature disablement;
architecture change;
compensating control;
workaround;
retirement of the affected system.

Those are not equivalent.

A useful vocabulary is:

fix — removes the underlying vulnerable condition;

mitigation — reduces exploitability or impact;

workaround — temporary operational action;

risk acceptance — explicit decision not to fix at this time.

FIRST's PSIRT framework includes remedy planning, remedy validation and communication about when remedies become available to stakeholders.6

A commit is not a deployed fix

If the patch exists in Git but:

no release exists;
the release is not distributed;
SaaS production has not been updated;
the vulnerable component remains active;

the practical exposure still exists.

CVD closure should reflect the real delivery model.

9. Retest the security boundary, not the developer's statement

Retest is not:

The developer says it is fixed.

It is not necessarily:

The scanner no longer reports it.

A useful retest re-evaluates the original security claim against the state that is supposed to be remediated.

For example:

original finding

User A can read an object belonging to User B.

retest

On the remediated version, User A can no longer access User B's object using the original path and material variants; server-side authorisation returns the expected result.

The original finder can be especially useful at this stage.

CERT.LV's current platform rules explicitly require researchers to respond to questions and to confirm the fact of remediation.8

That is an important lifecycle signal.

The reporter is not necessarily finished when the report is accepted.

10. A retest can discover partial remediation

At least four outcomes are possible:

They should not all map to RESOLVED.

Suppose one IDOR endpoint is patched with a local condition while several other endpoints retain the same broken backend authorisation model.

The original PoC no longer works.

The root cause remains.

A retest therefore needs to test the security property, not merely the exact string used in the original exploit.

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

11. Disclosure and remediation are coordinated but separate decisions

Public disclosure may serve several purposes:

tell users an update is available;
provide mitigations;
communicate CVE/EUVD identifiers;
recognise the finder;
document the security change;
help downstream vendors assess exposure.

FIRST's multi-party guidelines recommend coordinated timelines, ongoing communication and, absent evidence of earlier public disclosure or active exploitation, a reasonable embargo period for vendors to investigate and develop fixes.5

Under Latvia's CERT.LV platform rules, the reporter and resource owner agree the scope of information to be disclosed, CERT.LV reviews content before publication, and full publication requires the parties' agreement.8

The distinctions are important:

remediation deadline is not automatically a disclosure deadline, and

disclosure is not the same thing as closure.

A security advisory can be public while downstream users remain vulnerable.

12. Multi-party vulnerability coordination needs a different workflow

The simplest case is:

Modern supply chains look more like:

FIRST explicitly notes that open source, third-party software, bug-bounty proliferation and complex supply chains have made bilateral researcher-to-vendor coordination insufficient for many cases.5

A multi-party case may require:

a lead coordinator;
stakeholder mapping;
version/dependency mapping;
harmonised disclosure timing;
protected early notice to downstream parties;
embargo discipline;
remediation status per affected product.

In these cases “who is the vendor?” is not a scalar.

It is a graph.

researcher ↔ vendor

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

13. Closure should require evidence

I would use the following minimum test for VERIFIED_CLOSED.

The case is closed only when:

affected asset/product and versions are identified;
root cause or the exact vulnerable security condition is documented;
remediation or mitigation has an accountable owner;
the intended remedy has reached the actual affected environment or releasable product;
retest checks the original security boundary;
material known variants have been considered;
any incident-response issue has been transferred and tracked appropriately;
disclosure/advisory decision is documented;
reporter/coordinator has received the appropriate outcome communication;
minimum audit evidence is preserved.

If only the first four are true, I would call the state:

REMEDIATION_IMPLEMENTED

not:

VERIFIED_CLOSED.

That nomenclature is my process model, not an ISO status vocabulary.

“Resolved” needs internal evidence

CERT.LV's current platform rules require the resource owner to maintain case status in line with processing: a received report is moved to Open, and once the vulnerability is remediated, to Resolved.8

Behind that external status, an organisation should preserve more detail:

The goal is not bureaucracy.

It is reconstructability.

remediation:
  type: root_cause_fix | mitigation | workaround | risk_acceptance
  artifact:
  deployed_to:
  deployed_at:

retest:
  performed:
  performed_by:
  target_version:
  original_path_blocked:
  variants_checked:
  result:

closure:
  owner:
  decision_at:
  disclosure_status:
  residual_risk:

CVD should not absorb every adjacent process

A mature CVD function also knows what it does not own.

These processes should exchange evidence.

They should not become one giant ticket queue.

CVD should not absorb every adjacent process
Situation	Primary process
externally reported potential vulnerability	CVD
evidence of active compromise	incident response
known CVE affecting an internal asset	vulnerability management
contracted security assessment	penetration-test remediation workflow
bounty-payment dispute	programme reward/dispute process
possible personal-data breach	privacy/breach assessment
shared-component multi-vendor issue	multi-party vulnerability coordination

A practical CVD state machine

An organisation can begin with something this simple:

Parallel incident path:

Multi-party path:

The exact status names do not matter.

The semantics do.

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

What to measure

A CVD programme should not be measured only by:

How many reports did we receive?

More useful measures include:

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;
reporter response latency;
percentage closed with verified retest;
cases escalated to incident response;
stale cases without an owner.

Metrics can also be gamed.

An organisation optimising only for time to close may become better at closing tickets rather than fixing vulnerabilities.

A minimum CVD case record

I would preserve at least:

The practical test is simple.

Six months later, can somebody reconstruct:

What was reported, what did we verify, what did we change, and what proved that the security problem was actually closed?

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:

Latvia's statutory model already contains lifecycle elements

Latvia's National Cybersecurity Law is a useful concrete implementation example.

Section 39 requires a vulnerability report to be submitted without delay and no later than five working days after discovery, and defines minimum report content.7

The competent institution then:

acknowledges the report;
verifies the submitted information;
informs the reporter whether the information is substantiated;
informs the reporter about the remediation outcome.7

Section 40 adds:

remediation timing;
limited extension of the remediation period;
support for communication;
follow-up control;
multi-entity coordination;
cross-border coordination.7

That is not merely a “send us an email” model.

It already contains lifecycle mechanics.

The organisational challenge is to connect them to engineering, product ownership, incident response and release management.

Conclusion

CVD is not a vulnerability inbox.

It is the mechanism that converts an external security signal into verified organisational action.

A mature programme can answer every one of these questions:

Did we receive the report?

Did we understand the claim?

Can we reproduce it?

Was the vulnerability already exploited?

Who owns remediation?

Are we fixing the root cause, the symptom or only reducing exposure?

Did the remedy reach the affected environment?

Did somebody retest it?

Was disclosure coordinated?

Can closure be proven?

CVD becomes mature not when an organisation can say:

We have a security@ address.

It becomes mature when any closed case can be reconstructed months later as:

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

That is the difference between a vulnerability-reporting channel and a vulnerability-disclosure system.

Frequently asked questions

Are CVD and vulnerability management the same thing?

No. CVD focuses on receiving, validating and coordinating externally or otherwise reported vulnerabilities and disclosure. Vulnerability management generally covers a broader internal inventory of known weaknesses and prioritisation. They meet in remediation.

Should a report be closed when a developer says the patch is ready?

No. Fix ready and verified closed are different states. The remedy should reach the affected delivery environment and the relevant security condition should be retested.

Must the original researcher perform the retest?

No. Retest can be done by PSIRT, internal security, QA, another authorised tester or the original finder. What matters is that the result is verified against the security property rather than assumed from the existence of a patch.

Is 90 days a universal CVD disclosure deadline?

No. Latvia's 90-day statutory period concerns remediation for covered entities, with a limited extension mechanism up to 180 days.7 It is not a universal rule requiring publication on day 90.

What if the reported vulnerability has already been exploited?

Keep the CVD case, but also trigger incident response. Vulnerability remediation and compromise investigation are linked but distinct workstreams.

When is multi-party coordination needed?

When one vulnerability affects several vendors, a shared component, an open-source project, a cloud/SaaS provider or multiple jurisdictions. FIRST recommends coordinated stakeholder communication and a lead coordination function in such cases.5

Source status

Sources and Latvian legal status checked on 25 September 2026. The state-machine labels, VERIFIED_CLOSED criteria and minimum case record proposed here are the author's operational model, not an official status taxonomy of ISO, FIRST, NIST or CERT.LV.

This article analyses CVD and vulnerability-handling operations. It is not individual legal advice.