Summary. Many organisations have no working way to receive a vulnerability report. The obvious addresses often bounce, and general contact forms rarely reach anyone who can act on a security issue. RFC 2142 has reserved security@ for this since 1997, and RFC 9116 now defines /.well-known/security.txt as a machine-readable place to publish a contact, a key, and a disclosure policy. Every organisation that wants reports to reach someone should set these up and give them a real owner.
Background
2011 saw a steady stream of security disclosures on well-known websites, many of them for vulnerability classes (SQL injection, file inclusion, stored XSS) that have been textbook material for over a decade. Commentators often blamed developer time pressure. In my experience the more common root cause is organizational: many companies don't prioritize security highly enough to staff a security engineer or information security officer, and most don't publish a direct, working contact for reporting vulnerabilities.
Trying to reach a company through the obvious addresses, such as security@, abuse@, or webmaster@, frequently bounces outright. Going through the general contact form or an address like info@ usually doesn't fare much better, since whoever handles that inbox rarely has a path to forward a vulnerability report internally.
RFC 2142, then and now
RFC 2142 already specified reserved mailbox names for exactly this purpose back in 1997, including security@ for "reporting security problems." It's worth every organization setting up the handful of addresses relevant to it and giving them a real owner.
Today there's a more specific, machine-readable answer to the same problem: RFC 9116 defines /.well-known/security.txt, a standard location for a contact address, PGP key, and disclosure policy. Any site that wants responsible disclosure reports to actually reach someone should publish one. It solves the exact problem this post was written about in 2011.