A vulnerability’s journey from private discovery to public knowledge is not instantaneous. It follows a structured, often negotiated, process known as Coordinated Vulnerability Disclosure (CVD). This timeline balances the public’s right to know against the vendor’s need for time to develop and deploy a fix, preventing adversaries from exploiting a known but unpatched flaw.
The Standard 90-Day Disclosure Model
While policies vary, the industry has largely coalesced around a 90-day disclosure timeline, a model popularized by Google’s Project Zero. This timeframe serves as a default expectation, providing a clear structure for both security researchers and system vendors. The goal is to create a predictable and fair process that incentivizes prompt remediation.
Phase 1: Discovery and Private Reporting (Day 0)
The clock starts the moment a researcher submits a detailed vulnerability report to the vendor through a designated secure channel (e.g., a security email alias or a bug bounty platform). A high-quality report is crucial and typically includes:
- A clear title and description of the vulnerability.
- The specific model, version, API endpoint, or software component affected.
- A step-by-step proof-of-concept (PoC) to reproduce the issue.
- An assessment of the potential impact (often aligned with CVSS metrics).
Phase 2: Triage, Validation, and Remediation (Day 1 – 60)
Upon receipt, the vendor’s security team begins the triage process. Their initial goals are to acknowledge receipt of the report, validate the finding by reproducing it, and assess its severity. Once validated, the report is passed to the relevant engineering or MLOps team to begin developing a fix. This is often the longest and most resource-intensive phase, especially for complex AI systems where a “patch” might involve model retraining, data sanitization, or architectural changes to inference pipelines.
Phase 3: Coordination and Public Disclosure (Day 60 – 90)
As the deadline approaches, the researcher and vendor coordinate on the details of the public disclosure. This includes agreeing on a publication date, finalizing the content of the security advisory, and ensuring a CVE identifier has been assigned. The goal is for the patch or mitigation to be available to users at the same time the vulnerability details are made public, minimizing the window of opportunity for attackers.
On Day 90, the timeline concludes. The vendor releases the patch, publishes a security advisory, and the CVE entry is made public. The researcher is then free to publish their findings, technical write-ups, and PoC code.
AI-Specific Timeline Complications
The standard 90-day model, designed for traditional software, faces significant challenges when applied to AI systems. As a red teamer, you must be aware of these complexities as they often lead to extensions and negotiations.
- Model Retraining Latency: A vulnerability rooted in a model’s training data (e.g., a backdoor or systemic bias) cannot be fixed with a simple code patch. It may require extensive data curation and a full retraining cycle, which can take weeks or even months, far exceeding the 90-day window.
- Supply Chain Complexity: A vulnerability in a popular open-source foundational model (e.g., Llama, Mistral) affects countless downstream applications. Coordinated disclosure requires notifying a vast ecosystem of developers who have fine-tuned or built upon the base model, a logistical challenge that can justify a longer timeline.
- The “Unpatchable” Nature of Prompts: Prompt injection vulnerabilities are notoriously difficult to “patch” at the model level without degrading performance. Mitigation often involves input sanitizers, output parsers, and application-level controls. This shifts the burden from the model provider to downstream developers, complicating the definition of “fixed.”
- Ethical and Safety Disclosures: Vulnerabilities that enable harmful, unethical, or dangerous outputs (e.g., generating malicious code or harmful content) may require a more nuanced disclosure process involving policy teams and safety experts, potentially altering the standard timeline.
Variations in Disclosure Policies
Not all organizations adhere strictly to a 90-day clock. Understanding these variations is key to effective collaboration.
| Policy / Organization | Standard Timeline | Grace Period / Extensions | Key Considerations |
|---|---|---|---|
| Google Project Zero | 90 days | Optional 14-day grace period if a patch is imminent. | Firm deadline. Disclosure occurs on Day 90 regardless of patch status. |
| Zero Day Initiative (ZDI) | 120 days | Extensions may be granted on a case-by-case basis. | Acts as a broker between researchers and vendors, managing the timeline. |
| Typical Vendor VDP | 90 days (goal) | Flexible; extensions are common for complex issues. | Focus is on successful remediation, often prioritizing patching over strict deadlines. |
| AI Model Provider (Hypothetical) | 90-180 days | Explicitly allows for extensions related to model retraining cycles. | Policy accounts for the unique challenges of fixing core model behavior versus code. |
Ultimately, the vulnerability disclosure timeline is a framework for collaboration, not a rigid law. For AI systems, flexibility, clear communication, and a shared understanding of the technical challenges are paramount to successfully navigating the path from discovery to remediation.