Responsible Disclosure: A Coordinated Vulnerability Workflow

Responsible disclosure fails in the inbox, not in the policy. A public address matters, but the result depends on who validates the report, who owns the fix, and who can make a disclosure decision on time.

Organizations often publish a page, route mail to a security list, and call the program finished. Then a report arrives with a working proof against a product owned by another group. Legal asks for certainty, engineering wants more detail, support does not know what it can tell customers, and the researcher hears silence.

A sound program treats every credible report as a case with an owner, clock, evidence record, repair path, and planned public outcome. This guide covers policy design, security.txt, intake fields, response targets, safe validation, coordination, disclosure, and the reporting deadlines about to apply in the European Union.

What is responsible disclosure?

Responsible disclosure is the private reporting of a security weakness so the affected organization can investigate, repair, and inform users before technical details become public. Many practitioners prefer the term coordinated vulnerability disclosure. It describes the work without making one party the judge of whether another behaved responsibly.

Coordination can involve a finder, reporter, product vendor, open source maintainer, downstream supplier, deployer, CVE Numbering Authority, and an independent coordinator. The CERT guide to coordinated vulnerability disclosure defines the process as gathering information, sharing it among relevant parties, and disclosing the vulnerability and mitigation to stakeholders, including the public.

This is one part of the larger vulnerability publication chain. The CVEs and vulnerability intelligence pillar guide explains how an ID, record, vendor advisory, database enrichment, and local action relate after coordination produces a public case.

Why is discoverability still so poor?

A policy that cannot be found is close to no policy at all. Research published in January 2026 examined 491 consumer Internet of Things manufacturers. The 2025 vulnerability disclosure usage study found that 34 manufacturers, 6.92 percent, used a conventional /security page. Forty four of 491 published security.txt. Seventy one, 14.46 percent, provided a PGP key.

Bug bounty use was also 44 of 491 manufacturers, or 8.96 percent. A bounty and a disclosure policy are different commitments. A policy says how good faith reports are authorized and handled. A bounty adds payment rules for eligible findings. Do not promise money unless the program has a budget, severity method, duplicate rules, and someone authorized to approve payment.

The study also found policies buried in legal compliance sections and security.txt files that contained only an email address. Both create friction. A researcher should be able to find scope, safe harbor, testing limits, a secure contact, expected communication, and public disclosure terms without guessing.

What should a security.txt file contain?

RFC 9116 defines a machine readable file at /.well-known/security.txt. The official security.txt specification requires at least one Contact field and exactly one Expires field. Web contacts, policy links, canonical locations, and encryption key locations must use URIs. Serve the file over HTTPS as UTF-8 plain text.

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Encryption: https://example.com/security/pgp-key.txt
Policy: https://example.com/security/policy
Canonical: https://example.com/.well-known/security.txt
Preferred-Languages: en
Expires: 2027-08-27T00:00:00Z

The example follows the RFC grammar and keeps expiry less than one year from this article's date. Put a calendar owner on renewal. A stale file can send sensitive reports to a departed employee or dead form, which is worse than an obvious absence because it creates false confidence.

What belongs in a responsible disclosure policy?

Define scope with domains, products, versions, and explicit exclusions. State which testing is authorized and which behavior is prohibited, such as denial of service, persistence, social engineering, physical access, or viewing more data than needed to prove impact. Include good faith safe harbor language that counsel has reviewed for the jurisdictions where the organization operates.

Say what a useful report contains: product and version, affected endpoint or component, required permissions, reproduction steps, observed result, expected result, impact, and a minimal proof. Explain how the company will protect reporter identity and accidentally accessed data. Give a secure channel for reports that include exploit code or sensitive evidence.

Set communication expectations without making promises the team cannot meet. An operator target might be an automated receipt in minutes, human acknowledgment within one business day, an initial validation decision in five business days, and a weekly update while a confirmed case remains open. Those are operating targets, not a universal standard. Measure them and change staffing when the queue proves they are fiction.

How should a disclosure intake queue work?

Create the case before debating severity. Record receipt time, reporter contact preference, affected product, report version, attachments, stated disclosure date, and every message. Assign an intake owner and a technical owner separately. The intake owner keeps the clock and communication moving. The technical owner validates and drives the product decision.

Check scope and safety first. If the report includes customer data, restrict access and tell the reporter to stop collection. Reproduce in a controlled environment. Preserve the exact build, configuration, identity, request, response, and expected security boundary. A scanner result alone is not a proof. A destructive demonstration on production should not be required.

Triage economics are plain. Suppose a program receives 25 reports a month and the first review takes 40 minutes. That is about 16.7 hours. If poor routing adds 15 minutes of ownership search to every case, the mailbox burns another 6.25 hours before validation starts. A rotating intake owner and product directory are cheaper than paying every engineer to rediscover the route.

How do you coordinate validation, repair, and publication?

Confirm what the report proves and what remains unknown. Decide whether the issue is new, a duplicate, accepted behavior, or a valid weakness. For a valid case, identify every supported version, shared component, upstream maintainer, and downstream product that may need notice. Multiparty cases need a coordinator because bilateral email chains lose status and expose embargoed details.

Reserve a CVE when the issue meets program rules and a responsible authority is available. Draft the advisory while the fix is being built. The draft forces early answers about affected versions, prerequisites, impact, mitigation, fixed builds, update path, acknowledgment, and publication time. The CVE meaning guide explains which public record facts belong beside that vendor detail.

Test the fix against the original proof, normal product behavior, upgrade paths, and supported branches. Retest the public package, image, or service after release. Closing a development ticket proves code moved. It does not prove customers can obtain the repair or that the vulnerable state disappeared.

Is 90 days the required disclosure timeline?

No universal 90 day law governs every case. CERT guidance describes 45 to 90 days as the normal range and treats a declared timeline as the start of a negotiation, not a hard deadline. Active exploitation, a failed embargo, safety impact, many downstream vendors, or a repair that needs physical replacement can justify a different plan.

Agree on a target date early and document extensions. Updates should name completed work, current blocker, next decision, owner, and date. "Engineering is looking" is not a status. If the vendor stops responding, a neutral coordinator such as CERT/CC can help reach parties and plan publication.

The publication itself should align the vendor advisory, CVE Record, packages, detection guidance, customer communication, and researcher writeup when possible. The zero day response guide covers the faster operating path when exploitation or public knowledge removes the normal embargo window.

What changes on September 11, 2026?

European Union Cyber Resilience Act reporting obligations begin on September 11, 2026. The European Commission's July 2026 CRA reporting guidance says manufacturers must submit an early warning within 24 hours after becoming aware of an actively exploited vulnerability in a product with digital elements, followed by a full notification within 72 hours. A final vulnerability report is due no later than 14 days after a corrective measure becomes available.

The Single Reporting Platform is intended to carry the report to the relevant CSIRT and ENISA. That legal clock is not the same as a researcher's publication deadline, and a CVE alone does not prove active exploitation in the manufacturer's product. Product makers should have counsel map scope and duties. Operators still need one evidence record that connects awareness time, exploitation evidence, affected product, notifications, repair, and public communication.

This is the recent development many older disclosure templates omit. A policy owned only by the security team is not enough when a 24 hour regulatory clock may involve product, legal, executive, CSIRT, and customer decisions. Run a tabletop before the deadline.

Which disclosure metrics expose weak operations?

• Time to human acknowledgment, measured from the original receipt.
• Time to validation decision, split by product and report type.
• Open confirmed cases by age, owner, and planned disclosure date.
• Time from fix availability to customer notification and verified deployment.
• Cases with missed updates, stale contacts, or no named technical owner.

Do not reward a low report count. It can mean the product is safe, or it can mean researchers cannot find a contact and have stopped trying. Pair volume with discoverability checks, test submissions, response time, valid report rate, and repeat weakness classes.

The vendor security advisory guide covers the public artifact that should emerge from this workflow. Intake and publication belong in one case system so the final notice can be traced back to validation and repair evidence.

Frequently asked questions about responsible disclosure

Is responsible disclosure the same as a bug bounty?

No. A disclosure policy explains authorized testing and report handling. A bug bounty adds payment terms for eligible findings. An organization can run a disclosure program without paying bounties.

Should a policy promise that the organization will never take legal action?

The policy should provide clear safe harbor for good faith activity that follows its rules. Counsel should draft language that fits applicable law. Do not publish a vague promise that conflicts with other terms.

What if a vendor does not respond to a vulnerability report?

Keep dated contact records, try published security channels, and engage a coordinator when impact or affected parties justify it. Do not increase testing on production to force attention.

Does every valid disclosure need a CVE?

No. CVE assignment depends on program rules, product distribution, scope, and authority decisions. A valid flaw in a private service can require urgent repair and customer notice without receiving a CVE ID.

The executive takeaway

Test your disclosure channel this week with a harmless sample report. Confirm a human receives it, assigns a product owner, protects the evidence, starts the clock, and can draft a customer notice from the same case. Then run a 24 hour CRA exercise. A polished policy cannot rescue a broken handoff.