There’s a deep asymmetry between software users and software vendors, especially around security. Vendors decide what gets patched, how fast it ships, and what quietly slides to next quarter. Users get almost none of that visibility, and even less power to change the outcome.
Security researchers help narrow that gap. We find a vulnerability, report it, and work with the vendor toward a fix. The vulnerability disclosure process isn’t always straightforward, but I’ve found most researchers and most vendors come to it in good faith.
The challenge starts with vulnerability reports that don’t fit neatly in that process.
Some bugs don’t fit
If you report a remote code execution (RCE), SQL injection, or cross-site scripting (XSS) vulnerability, the path is well worn. There’s a code owner to route it to, the vendor’s security team can open a ticket that says “fix this,” and they can often pull logs to show how often the bug is getting exploited in the wild. The vulnerability is legible to the people who triage it.
Then there’s the other bucket, the one I think of as the intersection of broken user expectations and platform behavior. These are the default settings, the documentation, and the UI choices that quietly make a product less secure or less private than a reasonable person would assume. There’s no clean exploit primitive and no single code owner, and often no log that proves anyone’s been burned yet.
A bug bounty or VDP program isn’t built for that. The rules that keep out bad-faith noise also filter out good-faith findings that don’t look like a classic vuln, because it isn’t immediately obvious that the behavior can be exploited, or that it leaves anyone less safe. Fixing it usually isn’t a one-line patch either; it pulls in technical writing, UI and UX, and product strategy, none of which tend to sit close to the team reading inbound security mail. Eventually the finding gets closed, everyone moves on, and the insecure “feature” remains unfixed.
What “Won’t Fix” looks like
I’ve run into this a few times, most recently in a report to Google. We found that when you delete a Google API key (the same keys that can access Google Gemini), it remains valid for up to 23 minutes. That’s in spite of the key no longer existing in your GCP console and a dialogue box that says “it can no longer be used to make API requests”. For developers who accidentally leak a credential on GitHub, deleting the key is the standard fix, and it’s supposed to be instant. It isn’t. For those 23 minutes, an attacker who already grabbed the key can keep using it while the console swears it’s gone.
We reported it, and Google closed it as “Won’t Fix,” the same dead end HackerOne programs file under “Informative.” The position, as we understood it, was that propagation delay is a known property of an eventually consistent system, not a security issue (read: working as intended). Google documents that its IAM API is eventually consistent, but it never says so for API keys, and it never squares that delay with the sentence the console shows when you click delete. That gap between what the product tells the user and what it actually does is the whole problem.
Sizing the impact only gets you so far
What’s worked best for me in these cases is sizing the impact. If you enumerate the scale and make it concrete, a report that looks like a curiosity starts to look like a bug worth fixing. Sometimes that’s enough, and sometimes, like here, it still gets closed.
The finding was sound. It just never reached anyone at Google positioned to act on it, and I’m convinced the right person would have accepted it on the spot. That’s the part that’s frustrating.
When a report gets closed like that, responsible disclosure leaves a researcher exactly one move: publish.
Publishing isn’t about a black eye
Publishing research isn’t about embarrassing a vendor, even if it feels that way from their side. You put the facts out in the open and let the community decide whether the vendor made the right call. If the tech press picks it up, the finding gets in front of more people, including the ones who can actually act on it.
We pitched this story to a few outlets and it got solid coverage: The Register, Dark Reading, and TechCrunch.
It reached the right people at Google. They reopened the report, and it’s now a P0, which was not the outcome I expected when we published. The press amplified a voice that was, underneath it all, advocating for the security and privacy of users.
The objection I can’t fully answer
I’ve spent this whole piece arguing for going public, so I’ll be the first to say where it breaks down. Press coverage is a bad way to decide what a security team fixes first. A journalist can get it wrong, a researcher can overstate impact, and a vendor that feels publicly cornered might bump the loudest finding ahead of bugs that are quietly far more dangerous.
I don’t have a clean rebuttal. But it only goes so far, because of the question underneath it: how else does a finding like this one get seen at all? The formal process had no slot for it. The press filled the vacuum.
The fix lives on the vendor’s side: build proper intake for the findings that don’t look like classic vulnerabilities, so that getting one taken seriously doesn’t depend on whether a reporter happens to bite.
Where this leaves us
The revocation window was always the small version of the story. The bigger one is a whole class of findings where the defaults, the UI, and the documentation are all “working as intended”, yet still leave the user less secure and their activity less private than they believe. Vendors don’t have much incentive to surface that cost.
The disclosure process is imperfect. Publishing (and sharing our findings with journalists) remains one of the few reliable ways a researcher can push a “closed” security report back in favor of the user. It won’t ever replace a process that actually works, but it can take one researcher’s report and make it loud enough that ignoring the problem costs more than fixing it. Until vendors build something better, that’s the lever we have.
___________
About:
Joe Leon is a security researcher at Aikido Security. Before Aikido, Joe led security research at Truffle Security and ran application security assessments at an offensive security consulting firm. Joe has taught multiple red team courses at BlackHat USA and spoken at OWASP Global, Nahamcon, x33fcon, and Wild West Hackin’ Fest. Joe holds an MS in Cybersecurity Risk and Strategy from NYU.
