When the U.S. Cybersecurity and Infrastructure Security Agency (CISA) published new guidance on coordinated vulnerability disclosure programs in late 2024, it admitted its own reporting channels had failed a security researcher. Guillaume Valadon discovered a vulnerability in CISA's systems but faced a convoluted reporting path because the agency's disclosure process "were not well defined."
This isn't just a theoretical case study. It's a documented failure from the organization that sets cybersecurity standards for federal agencies. Let's break down what went wrong and what your compliance team needs to fix before you're in the same position.
What Happened
A security researcher identified a vulnerability in CISA's infrastructure and attempted to report it through official channels. The reporting path proved complicated enough that CISA later acknowledged the process had broken down. The agency responded by publishing formal guidance on building coordinated vulnerability disclosure (CVD) programs, incorporating lessons from its own failure.
The guidance now recommends that organizations acknowledge security researcher outreach within two to three business days and emphasizes the need for clear, accessible reporting channels.
Timeline
While CISA hasn't published a detailed timeline of Valadon's specific case, the sequence of events follows a familiar pattern:
- Researcher discovers vulnerability.
- Researcher attempts to report through official channels.
- Reporting path proves unclear or inaccessible.
- Researcher faces delays or confusion about proper contact.
- Agency acknowledges the reporting failure.
- Agency publishes guidance incorporating lessons learned.
The critical failure point sits between steps 2 and 3. Once a researcher hits friction in the reporting process, you've lost control of the timeline. They might go public, give up, or try alternative channels that bypass your incident response team entirely.
Which Controls Failed
No defined security.txt file: CISA's systems lacked the machine-readable disclosure policy specified in RFC 9116. This standard provides a simple way for researchers to find your security contact, preferred languages, and disclosure policy. Without it, researchers resort to guessing: info@, security@, abuse@, or hunting through your website footer.
Unclear escalation path: When initial contact points failed, the researcher had no documented backup channel. Your disclosure process needs multiple layers: primary contact, secondary escalation, and a public fallback if both fail.
Missing acknowledgment SLA: CISA's new guidance recommends two to three business days for initial acknowledgment. Their own incident suggests they had no documented response timeframe, leaving the researcher uncertain whether their report had been received.
Inadequate researcher communication: The agency's admission that channels "were not well defined" points to a broader failure: no one had documented and tested the researcher experience. Your security team might know how to report internally, but external researchers face a different path.
What Standards Require
ISO/IEC 27001:2022 Control 5.24 (Incident Response Planning) requires organizations to establish and document procedures for responding to information security incidents. A coordinated vulnerability disclosure program is a subset of incident response. If you can't receive vulnerability reports reliably, you're not meeting this control.
NIST Cybersecurity Framework v2.0 function DE.CM-8 calls for vulnerability scans to be performed. But detection is only half the equation. The Respond (RS) function requires processes for response planning and communications. A broken disclosure channel means you're failing RS.CO-2: incidents are reported consistent with established criteria.
SOC 2 Type II Common Criteria CC7.3 requires that the entity identifies, develops, and implements activities to respond to identified security incidents. Your disclosure program is part of this response capability. If your auditor asks how external researchers report vulnerabilities and you can't produce a clear answer, that's a finding.
PCI DSS v4.0.1 Requirement 6.3.2 mandates that security vulnerabilities are identified and addressed. You can't address what you don't know about. If researchers can't report findings because your process is unclear, you're creating gaps in your vulnerability management program.
Lessons and Action Items
Deploy security.txt today: Create a .well-known/security.txt file on your web properties. Include your security email, a link to your disclosure policy, and preferred languages. This takes 30 minutes and eliminates the most common reporting friction. RFC 9116 provides the specification.
Document your researcher journey: Have someone outside your security team attempt to report a test vulnerability. Time how long it takes them to find the right contact. If it takes more than two minutes or requires more than two clicks, simplify the path.
Set acknowledgment SLAs: Commit to acknowledging reports within two to three business days, as CISA now recommends. This doesn't mean you need a full analysis, just confirmation that you received the report and are investigating. Add this SLA to your incident response playbook.
Create escalation tiers: Your primary security contact might be on vacation or overwhelmed. Document a secondary contact and a public fallback (like a security@ alias that routes to multiple team members). Test these quarterly.
Train your SOC and helpdesk: External vulnerability reports often hit your general support channels first. Your tier-1 support needs a clear escalation path and template responses. "I'll forward this to our security team and you'll hear back within three business days" is sufficient.
Review annually: CISA learned from its failure and published guidance. Your disclosure program should improve the same way. After each vulnerability report, document what worked and what didn't. If researchers are using LinkedIn messages instead of your official channel, that's a signal your official channel isn't working.
The irony here is sharp: the agency responsible for coordinating vulnerability disclosure across federal systems couldn't handle a disclosure to its own infrastructure. But that transparency matters more than the failure. If CISA can acknowledge its process broke down, your organization can do the same. The question is whether you'll wait for a public failure or fix the gaps now.
