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,