From Report to Remediation: Scope Meets the CVD Lifecycle

This chapter follows an AI vulnerability report after it enters a disclosure process. The focus is the transition from a claim about behavior to a reduction in risk: how a vendor validates the report, prioritizes it, chooses a response, informs affected parties, and learns whether the response worked. That lifecycle shows why eligibility is not the same decision as remediation, and why a report about a probabilistic model needs more than a single surprising output before anyone can act.

A policy that ends at “submit here” treats the most important part of vulnerability response as someone else’s problem. Coordinated Vulnerability Disclosure, or CVD, is broader. The CERT guide describes it as a process of discovery, reporting, validation and triage, remediation, public awareness, and deployment. These phases may recur or occur out of order, but each transition moves information, responsibility, and risk between people or teams.

A report changes state as evidence and ownership move

Discovery begins when someone notices a condition that may violate a security policy. In an AI system, the observation could be a model response, an unexpected tool call, a data exposure, or a behavior that appears only under a particular sequence of inputs and context. Discovery alone does not establish a vulnerability. It creates an information problem: someone knows about a possible weakness, while the vendor and affected users may not.

Reporting turns that observation into a claim another party can evaluate. A useful report identifies the relevant product or service, the behavior and preconditions, the security property or material harm at issue, the evidence observed, and the limits of the test. For a probabilistic system, it may also explain how often the behavior occurred or what conditions made it more likely. The aim is not to force the researcher to prove the vendor’s entire root cause. It is to preserve enough context that the receiving team can reproduce, investigate, or safely ask for more information.

The transition to validation is where “the model did something odd” becomes a testable case. The vendor must determine whether the reported conditions exist, whether the behavior is part of the product, and whether the claimed impact follows. Reproduction may require the same model version, retrieval context, account state, tool permissions, or conversation sequence. If the vendor cannot reproduce the behavior, that result is not automatically proof that the report is wrong. The team may be missing a precondition, the behavior may be intermittent, or the system may have changed. But without a credible evidence path, the vendor cannot responsibly prioritize remediation.

Validation should also check the impact rather than only the output. A model can generate a prohibited sentence without crossing an authorization boundary. An agent can produce an ordinary-looking answer while retrieving information that the requester should not see. A useful triage process asks what the behavior permits, who can trigger it, what asset or person is affected, and how much of that effect was actually demonstrated.