Five Government Agencies Tell Software Makers: Open a Front Door for Bug Reporters
CISA and four allied agencies have published a joint guide urging tech companies to set up formal programmes so security researchers can safely report flaws before criminals find them first.
Key points
- CISA published joint guidance on coordinated vulnerability disclosure in 2025 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 called coordinated disclosure "foundational to building a secure software ecosystem."
- AI-assisted tools are finding security flaws faster than most security teams can manually review them, according to Tuskira CEO Piyush Sharma.
Security researchers spend their days hunting for weaknesses in software and websites. When they find one, many want to tell the company so it can be fixed. The problem: companies often have no clear reporting channel, no named contact, no written rules, no promise the researcher won't 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 with 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 is titled "Establishing a Coordinated Vulnerability Disclosure Program to Work With Security Researchers." Its core message: set up a formal, public process or watch criminals quietly exploit flaws researchers would have reported for free. We first covered this class of joint guidance when CISA and NSA published their bug-hunter playbook on 15 July.
A coordinated vulnerability disclosure programme, or CVD programme, is a published rulebook. It tells researchers where to send a report, what testing the company permits, and how long it expects to take before releasing a fix. Without one, 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 findings publicly out of frustration, handing a road map to anyone paying attention.
Piyush Sharma, co-founder and CEO of Tuskira, told reporters the guidance addresses something both sides need. Researchers need to know where to send a report. Security teams need defined ownership once it arrives.
Andrew Costis, engineering manager of the Adversary Research Team at AttackIQ, made a point worth underlining. Receiving a report is the easy part. The harder work is determining 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 scan codebases and surface potential weaknesses at a speed no human team matches. Sharma warned that the flood of findings is already outpacing most organisations' ability to review them manually. His advice: don't treat every reported flaw as equally urgent. Work out whether it creates a real path into critical systems, and whether existing controls can slow an attacker while a permanent fix is prepared.
Costis added a check many teams skip. Patching a system and closing the ticket isn't the same as confirming the attack route is blocked. Both steps matter, and our earlier piece on security debt growing faster than companies can fix it spells out why that backlog compounds quickly.
Should you worry about your own software?
Check whether vendors you rely on publish a vulnerability disclosure policy, sometimes listed as a "responsible disclosure" or "security research" page. A vendor that publishes one is signalling it takes flaw reports seriously. One that doesn't may be slower to fix problems you'll never hear about until it's too late.
