A researcher finds a flaw in your system. They did not go looking for trouble. They noticed something wrong, poked at it out of curiosity or habit, and now they are staring at a decision that should be simple: tell the company, so it can be fixed. In practice, that decision is rarely simple at all.
Doing the responsible thing, reporting what they found, can expose a researcher to legal threats, account bans, or an awkward silence that never resolves into a thank you. Staying quiet costs them nothing. That asymmetry is the paradox at the center of vulnerability disclosure, and it explains why some of the most useful information about your security posture never reaches you at all.
This piece looks at why that asymmetry exists, what it costs organizations that never resolve it, and how a properly built disclosure program closes the distance between finding a flaw and fixing it.
The Asymmetry Between Reporting and Staying Silent
Responsible disclosure sounds like a settled concept: a researcher finds a bug, reports it privately, gives the organization time to patch it, and only then discusses it publicly if at all. In practice, "responsible" describes the researcher's behavior, not the organization's reaction, and the two do not always line up.
A researcher who reports a bug has no guarantee of how it will be received. Some companies respond with gratitude and a fix. Others respond with a cease-and-desist letter, a threat to involve law enforcement, or silence that drags on for months while the vulnerability stays open. The researcher cannot know in advance which kind of company they are dealing with, and by the time they find out, they have already handed over information that could just as easily be used against them.
That uncertainty changes behavior in a way that has nothing to do with skill or intent. A qualitative study of security researchers published in the Journal of Cybersecurity found that legal uncertainty is one of the most significant obstacles to researchers engaging in coordinated disclosure at all, not because researchers lack the expertise to report responsibly, but because the legal and social response to that report is unpredictable.
What "Illegal Access" Actually Covers, and Who It Was Written For
The deeper problem is structural. Most cybercrime statutes were drafted to punish people who break into systems to steal, damage, or extort, not to distinguish between that intent and a researcher who accesses a system without permission in order to warn the owner about it.
In the Philippines, the Cybercrime Prevention Act of 2012 illustrates this precisely. Under its illegal access provision, unauthorized access to a computer system is an offense even if no damage is caused, and intent to access is sufficient on its own, carrying penalties of six to twelve years imprisonment or fines starting at two hundred thousand pesos. The law does carve out an exemption for legitimate purposes such as ethical hacking, but that exemption applies specifically to access done with consent. A researcher who stumbles onto a flaw on their own, without a prior arrangement authorizing them to look, is not automatically covered by that carve-out just because their intentions were good.
This is not unique to the Philippines. Researchers describe the same tension under broader anti-hacking statutes elsewhere, where the line between "authorized testing" and "unauthorized access" depends entirely on whether the organization granted permission before the researcher went looking, not on what the researcher intended to do with what they found. One documented account describes a researcher who discovered a stockpile-worthy vulnerability and faced a genuine ethical dilemma over whether to report it at all, weighing the risk of legal exposure against the value of doing the right thing. The law, as written in most jurisdictions, gives that researcher very little reason to choose disclosure.
Regulators are beginning to notice the gap this creates, even if they are approaching it from the reporting side rather than the researcher's side. Under the European Union's Cyber Resilience Act, which begins enforcing reporting obligations in September 2026, manufacturers will have just 24 hours to file an early warning once they learn a vulnerability in their product is being actively exploited, with fines reaching fifteen million euros or 2.5 percent of global turnover for noncompliance. The law does not require a coordinated disclosure policy outright, but a mandate that tight only works if an organization already has a channel built to catch the report the moment it arrives. Waiting until a regulator asks for one is not a plan.
A Missing Channel Is Not the Same as No Vulnerabilities
Even when the legal risk is manageable, a researcher still needs somewhere to send the report. Most organizations do not make that obvious.
Among consumer technology manufacturers tracked in an eight-year longitudinal study by the IoT Security Foundation, only 40.53 percent provided a public way for a researcher to contact them about a security issue as of the most recent report, up from 35.59 percent the year before. That improvement is real, but it means close to six in ten of the manufacturers studied still gave a researcher no clear channel to use.
The absence of a channel does not stop researchers from finding bugs. It stops them from telling anyone. In HackerOne's Hacker-Powered Security research, the lack of a clear vulnerability disclosure channel was the single most common reason hackers gave for not reporting a vulnerability they had found. Not fear of prosecution first, not lack of a bounty first: simply not knowing where the report was supposed to go, or whether anyone on the other end would take it seriously.
What that looks like in practice is well documented. Security researcher Eddie Zhang once found the same kind of exposed cloud storage bucket, containing sensitive data, at two different organizations within weeks of each other. The first had a published security contact, and responded within 24 hours, on a Saturday, thanking him for the report and inviting him to document the finding publicly once it was fixed. The second had no security contact at all, so Zhang messaged the CEO and CIO on LinkedIn. The CIO dismissed the report and blocked him. The CEO never responded. Weeks later, after Zhang escalated through a national cybersecurity agency and a well-known breach notification service, the exposed data was still sitting there, unresolved. The vulnerability was comparable in both cases. The only real difference was whether a channel existed for someone to use.
What Organizations Lose by Never Hearing From Researchers
Organizations sometimes treat the absence of vulnerability reports as good news. It is frequently the opposite.
The same HackerOne research found that 52 percent of security professionals would rather leave a vulnerability undiscovered than engage with an outside hacker to find it, and 60 percent said they did not fully trust hackers in the first place. That instinct is understandable on a gut level and costly in practice. A vulnerability that is never reported to you does not stop existing. It simply waits for whoever finds it next, and that person is under no obligation to have your organization's interests in mind.
There is also a market actively competing for that researcher's attention. Exploit brokers built entirely around buying vulnerabilities from researchers who would rather not deal with an unresponsive company have paid as much as 1.5 million dollars for a single iOS exploit, and 2.5 million dollars for an Android one, spending in the range of one to three million dollars a month on acquisitions at their peak. A legitimate bug bounty payout for a comparable finding rarely comes close to that figure, which means the financial incentive alone does not explain why most researchers still choose to disclose responsibly. What it does mean is that an organization offering no legitimate channel is not competing against apathy. It is competing against a market that pays well for exactly the silence a bad experience produces.
This is where the researcher's dilemma and the organization's blind spot reinforce each other. A researcher facing legal ambiguity and no clear reporting channel has little incentive to come forward. An organization that never built a channel or a legal safety net never sees the report that would have told them exactly where they were exposed. Both sides lose, and the vulnerability itself is the only party that benefits from the standoff.
Safe Harbor: The Clause That Changes the Calculation
A structured vulnerability disclosure program exists to answer, in advance, every question that currently makes a researcher hesitate. Where do I send this? Will I be thanked or threatened? Is what I am about to describe going to be used against me.
A properly built program answers each of those questions before a researcher ever needs to ask. It names a clear intake channel, so there is no ambiguity about where a report goes or who reads it. It defines scope, so a researcher knows what they are and are not authorized to test. And critically, it includes safe harbor language, an explicit commitment from the organization not to pursue legal action against a researcher who reports in good faith and stays within the defined rules. That commitment is what converts the legal gray area described earlier into a lit, marked path.
Secuna Response is built around exactly that structure: a defined intake process, expert triage so reports are validated before they reach your team, and a framework that gives researchers the clarity they need to report responsibly instead of quietly walking away. For organizations operating in the Philippines, that structure also does double duty as evidence of due diligence, the kind of documented, good-faith security process regulators and auditors look for when something does go wrong.
Whether Your Organization Has Made This Decision Yet
If your organization has no public way for a researcher to report a vulnerability, the honest question is not whether anyone has found a flaw in your systems. Someone likely has. The question is whether they had anywhere to send it, and whether they had a reason to trust that doing so would not backfire on them.
Every organization ends up on one side or the other of the story described earlier. Either you are the company that responds within a day and thanks the person who just saved you months of exposure, or you are the one that leaves a researcher messaging your CEO on LinkedIn because there was nowhere else to go. Nobody chooses the second outcome on purpose. It happens by default, to organizations that never got around to building the first one.
Building that channel does not require guessing at legal language or hoping researchers will figure out your intentions on their own. It requires a program that states the rules plainly enough that a researcher does not have to gamble on your reaction before they decide to help you.
Conclusion
The paradox of disclosure is not that researchers are unwilling to do the right thing. It is that organizations have made doing the right thing feel like a risk the researcher has to absorb alone. Every unclear policy, missing contact channel, and vague legal threat pushes another finding back into silence, where it stops being useful to anyone except whoever finds it next with worse intentions.
A disclosure program does not just collect reports. It removes the reason a researcher had to hesitate in the first place.
Secuna Response gives organizations a structured, legally sound way to receive vulnerability reports, so the researchers who find your flaws have a clear, safe path to tell you, and your team gets the validated findings before anyone else does.
To learn more, reach out to our team at [email protected] or explore our services at secuna.io.
Sources: Hunting for Vulnerabilities: Call for European Protection of Security Researchers, Journal of Cybersecurity · Cybercrime Prevention Act (RA 10175) in the Philippines: Key Offenses, Penalties, and Remedies, Respicio & Co. · The Legal Risks That Chill Good-Faith Security Research, Lawfare · EU Cyber Resilience Act: Preparing for Vulnerability and Incident Reporting, Hogan Lovells · The State of Vulnerability Disclosure in Global Consumer IoT, IoT Security Foundation · A Tale of 2 Vulnerability Disclosures, Project Black · Half of Security Professionals Choose Cybersecurity Risk Over Working with Ethical Hackers, HackerOne · Zerodium, Wikipedia