How should security teams structure a responsible vulnerability disclosure process for AI products and open-source packages?

A strong disclosure process gives researchers a clear path to report issues, sets expectations for validation and response, and defines when public disclosure can happen. Security teams should publish a dedicated reporting channel, request reproducible details and proof of concept evidence, acknowledge reports promptly, and coordinate remediation before any wider release of vulnerability information.

Designing a disclosure process that works for AI products and open-source code

A responsible disclosure process has to do more than accept email reports. For AI products, the process should recognise model behaviour issues, prompt-injection paths, data leakage, unsafe tool use, and supply-chain weaknesses in dependencies or packages. For open-source packages, it also needs to handle maintainer coordination, patch timing, and the reality that fixes may need to land across multiple downstream distributions. The process is strongest when researchers can tell quickly whether a report is in scope, how it will be triaged, and when public disclosure is appropriate. See the EU Cyber Resilience Act for the broader direction of travel on product security obligations.

Security teams should define the process around the asset being reported, not the channel alone. That means separate intake logic for AI system failures, package vulnerabilities, and supply-chain concerns, even if they share the same reporting mailbox. If a team treats all findings as generic bugs, it can miss issues that only become visible when a model, an agent, a plugin, or a package manager is exercised in a realistic workflow. In practice, many security teams encounter disclosure breakdowns only after a report crosses organisational boundaries, rather than through deliberate coordination planning.

What a practical disclosure workflow should contain

The most useful workflow is explicit, time-bound, and easy to follow. It should tell reporters what to include, what the team will do next, and how escalation works if the report affects active users or upstream dependencies. For AI products, the intake form should request enough detail to reproduce the issue without forcing researchers to expose unnecessary sensitive data. For packages, it should ask for version ranges, build context, affected platforms, and whether the issue affects transitive dependencies. When teams publish an intake template, they reduce back-and-forth and improve triage quality.

A good workflow usually has five parts:

A dedicated intake path with a clear scope statement, severity expectations, and a fallback route if the primary channel fails.
An acknowledgement step with a target response window, so the reporter knows the issue has been received and assigned.
A triage step that confirms reproducibility, impact, and whether the report maps to a product defect, a configuration weakness, or an exploitable chain.
A remediation and coordination step that sets expectations for patching, validation, and communication with maintainers or downstream consumers.
A disclosure decision step that defines when a public advisory, coordinated release, or embargo lift can happen.

For open-source packages, this process benefits from alignment with package maintainers and distribution channels, because the first fix is not always the final fix. For AI products, the workflow should also cover model-specific remediation options such as prompt hardening, tool restrictions, policy updates, or retraining where appropriate. Guidance from the CIS Controls v8 is useful where the disclosure process depends on secure configuration, asset visibility, and timely remediation tracking.

The process breaks down when the organisation cannot reproduce reports, cannot identify ownership quickly, or lets disclosure timing drift because legal, product, and engineering teams are not aligned.

Where AI products and packages create different disclosure edge cases

Tighter disclosure rules often increase coordination overhead, so teams need to balance researcher trust against the need to prevent premature exposure. The trade-off is especially visible when the issue involves an AI system with external tools or a package that is embedded in many other products. A single report may require model, application, and dependency owners to act together, which is slower but more realistic than expecting one team to own every consequence.

There is also a real consensus gap around what counts as a disclosable AI vulnerability versus a product-quality issue. Some teams treat harmful outputs, jailbreaks, and prompt injection as security issues only when they create unauthorised access or data exposure, while others handle them more broadly as part of AI assurance. That difference matters because it changes who triages the report, what evidence is required, and whether the issue is eligible for coordinated disclosure. Open-source packages create a different edge case: a flaw may be low-risk in isolation but high-risk when it is a dependency in widely deployed systems. In those cases, scope decisions should reflect downstream exposure, not just the package’s direct behaviour.

Teams should also be careful not to over-automate the response. Automated ticketing can help, but final severity, disclosure timing, and public language need human review, especially when the report affects multiple stakeholders or may trigger a broader ecosystem fix. Many disclosure failures happen when teams optimise for speed without first agreeing who has the authority to widen the response.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack surface, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and EU Cyber Resilience Act define the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	17 — Incident Response Management	Disclosure workflows rely on defined reporting, triage, and response handling.
	15 — Service Provider Management	Open-source and upstream coordination resemble third-party dependency handling.
	16 — Application Software Security	AI products and packages need secure flaw intake, validation, and remediation paths.
Recommendation — Align disclosure intake and escalation to incident response ownership and response timing. Track upstream maintainers and downstream dependents as part of coordinated disclosure. Route validated flaws into software security remediation and patch verification.
NIST CSF 2.0	RS.CO-2 — Incident Reporting	Responsible disclosure depends on clear reporting channels and response communication.
	RS.AN-3 — Analysis of Event Severity	Teams must triage report severity before deciding disclosure timing.
	RC.CO-3 — Public Relations and Reputation Recovery	Public disclosure timing and messaging need coordinated communication control.
Recommendation — Establish a reporting path that records, routes, and acknowledges vulnerability submissions. Triage each report to determine severity, scope, and required response speed. Coordinate advisory language and release timing before public disclosure.
MITRE ATT&CK	T1595 — Active Scanning	Researchers often validate findings by testing exposed behaviour or interfaces.
Recommendation — Use observed validation activity to improve exposure review and test coverage.
EU Cyber Resilience Act	Article 13 — Reporting Obligations	Product vulnerability disclosure and reporting obligations are directly relevant to AI and software products.
Recommendation — Build disclosure handling to support timely reporting and coordinated corrective action.

Practitioner Guidance

What to prioritise: Define scope, ownership, and response timing before publication. If reporters cannot tell whether an issue belongs in the AI, package, or supply-chain lane, the process will produce misrouted reports and delayed fixes.

What to verify: Confirm that the team can reproduce reports without asking for unnecessary sensitive data, and that every report has an owner, a severity decision, and a disclosure status. If any of those three are missing, the process is not operationally complete.

Decision rule: Treat AI-specific behaviour issues differently when they create confidentiality, integrity, or unsafe-action risk; treat package issues differently when the affected version may exist in many downstream builds. The same disclosure template should not force both into one triage path.

What practitioners underestimate: Coordinated disclosure often fails at the handoff between technical triage and public communication, not at intake. The best process is the one that can move from report to fix to advisory without ambiguity over who speaks, who approves, and who can extend an embargo.

Practitioner takeaway: A responsible disclosure process is less about receiving reports and more about proving that the organisation can classify, validate, fix, and communicate on a predictable timeline.