No way to reach the company that has your data

If someone outside your company finds a security problem with your product tomorrow, a leaked API key in a public repo, a database that answers to the open internet, a subdomain still pointing at a service you shut down last year, how would they tell you? For a lot of small B2B SaaS companies, the honest answer is: they wouldn't be able to. There's no security contact, no working support address for anything that isn't a sales inquiry, and no legal or business address a researcher could use as a fallback.

That gap doesn't cause the vulnerability. It decides what happens after someone finds it. A researcher who can't reach you quietly moves on, sits on the finding, or posts it publicly to get your attention, which is the worst version of every option for you and for the customers whose data is sitting in your systems.

What we found

We ran a passive, public-data-only scan across a sample of US B2B SaaS companies with 5 to 50 employees (N = 1090, aggregate generated 2026-09-24, monthly refresh). We looked only at what's publicly visible: DNS records, published contact pages, security.txt files, and similar. Nothing was probed, logged in to, or tested against; this is not a penetration test. Results are k-anonymised and no individual company is named or identifiable in this data.

47.6% of the population (n = 519) had no working disclosure contact at all: no security.txt, no security@ or equivalent alias that resolves, and no other published route a researcher or a partner's security team could use to report a problem.

What it looks like in practice

Picture a hypothetical small SaaS company whose only public contact is a "Contact Us" form on the marketing site, routed to a shared sales inbox. A researcher finds that a staging environment is reachable from the internet with a default admin login still active. They try the contact form. It goes into a queue with demo requests and partnership pitches, unread by anyone who could act on it. The researcher has no other path in: no security@ address, no security.txt, no listed phone number tied to engineering or IT.

From there the researcher has three options, and none of them are good for the company: wait and hope someone notices, escalate publicly on social media to force attention, or walk away and let the exposure sit. Every one of those outcomes costs the company more time, more reputational exposure, or both, compared to a five minute email exchange that a working contact address would have made possible.

Where to start

• Publish a security.txt file at /.well-known/security.txt with a real, monitored contact address and, if you have one, a PGP key. It takes an afternoon and it's the first thing a researcher looks for.
• Set up security@yourdomain.com (or route an existing alias to it) and make sure someone actually reads it, not just a shared inbox that gets skimmed once a week.
• Put a real point of contact somewhere a security researcher or a partner's procurement team would look: your footer, your trust or security page, or your terms of service.
• Check what a stranger sees when they look at your company from the outside. You can run our free checker at https://orangestealth.com/check to see whether your domain has a visible disclosure route today, at no cost.
• If you want a fuller picture beyond disclosure contacts, our External Security Posture Assessment reviews what's publicly discoverable about your domain, passively and externally, and flags the gaps in one report instead of piecemeal checks.

None of this requires a security team. It requires deciding that if someone finds a problem with your product, they should be able to reach a person who can fix it, before it becomes a bigger story than the bug itself.