Five Government Agencies Tell Software Makers: Open a Front Door for Bug Reporters

Key points

• CISA published joint guidance on coordinated vulnerability disclosure on an unspecified 2025 date alongside the NSA, JPCERT/CC, NCSC-NL, and NCSC-UK.
• The guide tells software makers and online service providers to publish a clear written policy explaining how researchers can report security flaws and what happens next.
• CISA's acting executive assistant director Chris Butera said coordinated disclosure is "foundational to building a secure software ecosystem."
• AI-assisted tools are now finding security flaws faster than most company security teams can review them, according to cybersecurity firm Tuskira.

Security researchers spend their days hunting for weaknesses in software, hardware, and websites. When they find one, many genuinely want to tell the company so it can be fixed. The problem: companies often have no clear way for researchers to report what they found, no named contact, no written rules, no promise the researcher will not face legal trouble for looking.

That gap is what five government agencies are now trying to close.

CISA, the US Cybersecurity and Infrastructure Security Agency, published a joint guide this year alongside the US National Security Agency, Japan's computer emergency response team JPCERT/CC, the Dutch National Cyber Security Centre, and the UK's National Cyber Security Centre. The document, reported earlier by CSO Online, is titled "Establishing a Coordinated Vulnerability Disclosure Program to Work With Security Researchers." Its core message is simple: set up a formal, public process or risk having flaws quietly exploited by criminals who find them first.

A coordinated vulnerability disclosure programme, or CVD programme, is essentially a published rulebook. It tells researchers where to send a report, what kind of testing the company permits, and how long it expects to take before releasing a fix. Without that rulebook, researchers often have no safe way in.

How does this protect ordinary customers?

It protects them because a flaw reported through a formal channel gets fixed before criminals can use it. When no such channel exists, researchers sometimes publish their findings publicly out of frustration, which hands a road map to every criminal paying attention.

Piyush Sharma, chief executive of cybersecurity firm Tuskira, told reporters the guidance addresses something both sides of a disclosure need. Researchers need to know where to send a report. Security teams need to know who owns the problem once it arrives.

Andrew Costis, engineering manager of the Adversary Research Team at security firm AttackIQ, made a point worth underlining. Receiving a report is the easy part. The hard work is working out what access a flaw would actually give an attacker, and how quickly a fix needs to land.

Volume is a growing pressure. AI tools can now scan codebases and find potential weaknesses at a speed no human team can match. Sharma warned that the flood of findings is already outpacing most organisations' ability to review them manually. His advice: do not treat every reported flaw as equally urgent. Work out whether a flaw creates a real path into critical systems, and whether existing security controls can slow an attacker down while a permanent fix is prepared.

Costis added a check that many teams skip. Patching a system and closing the ticket is not the same as confirming the attack route is actually blocked. Both steps matter.

What software users and customers should do

If you use software from a vendor, check whether that vendor publishes a vulnerability disclosure policy, sometimes listed on their website as a "responsible disclosure" or "security research" page. Companies that publish one are signalling they take flaw reports seriously. Companies that do not may be slower to fix problems you never hear about.