CISA integrates its vulnerability disclosure lessons into new guidance

On Wednesday, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and four allied cyber authorities released a new guide instructing software vendors on how to establish a coordinated vulnerability disclosure (CVD) program. The timing of this release appears intentional, coming just six days after CISA published a blog post detailing its own failure to handle a security researcher’s report of a serious vulnerability.

The guidance emphasizes that suppliers should design a CVD program to “effectively and transparently collaborate with security researchers to report and remediate vulnerabilities.” To do this, vendors must publish a vulnerability disclosure policy on their website and clearly state that reporting is open to the public. They should also implement a security.txt file, as defined in RFC 9116, to make contact information easily accessible without requiring researchers to hunt for it. The agencies recommend setting the widest possible scope for testing, arguing that arbitrary boundaries restrict researchers but not attackers.

Suppliers should acknowledge a researcher’s outreach within two to three business days. One key recommendation draws directly from CISA’s own missteps: separate vulnerability disclosure and triage from existing customer support channels. Using those channels, the agencies warn, “may lead to overlooked and undervalued reports or accidental disclosure.”

The failure CISA described occurred on May 15, 2026, when an investigative reporter contacted the agency about internal AWS GovCloud keys and other sensitive data sitting in a public repository. The reporter had obtained the information from Guillaume Valadon, a GitGuardian researcher who continuously scans public code repositories. Valadon wrote that after sending nine notification emails without response, his report reached CISA “through an unnecessarily complicated path.”

CISA admitted its reporting channels “were not well defined,” forcing the researcher to try multiple avenues: emailing the contractor, submitting through CISA’s vulnerability disclosure platform (designed for community-wide vulnerabilities, not the agency itself), and ultimately involving a reporter. The agency says it is refining those channels and notes that organizations should publish reporting instructions in multiple, prominent places, even if they rely on security.txt.

CISA also acknowledged it lost valuable time because it lacked a GitHub or cloud incident-response playbook and had to create one mid-incident. Key rotation took longer than expected due to the complexity of CISA’s systems and its interconnections with federal and industry partners, prompting the agency to urge others to maintain mature, well-tested key-management capabilities.

Nearly every failure CISA described aligns with a recommendation in Tuesday’s guide. Additional recommendations include using safe-harbor language to assure researchers their good-faith work is authorized under anti-hacking statutes, avoiding blanket non-disclosure agreements and silent fixes, assigning CVE numbers for internally discovered vulnerabilities, and publishing advisories based on the Common Security Advisory Framework without a paywall.

Regulatory weight backs this advice. BOD 20-01 already requires federal civilian agencies to publish disclosure policies, and the EU Cyber Resilience Act extends that obligation to suppliers operating in the European Union.

Valadon’s assessment of CISA’s postmortem was generous: “Most organizations bury this kind of incident. CISA wrote it up, explained what worked, what did not, and invited the industry to learn from it.” He also noted that, to his knowledge, this is the first time a national cyber agency has publicly advocated for secrets scanning and for simplifying relations with researchers.