Establishing asset ownership in vulnerability reporting

Something I see people consistently struggle with in vulnerability reporting is being able to answer the question of ownership and "where to report my findings." It might seem obvious at first, but large organizations, cross-border reporting, mergers and acquisitions, and the simple fact that "not everyone knows where their stuff is in the first place" can make this a tough question.

Getting your findings to the right folks matters—a lot.

Here are some practical tips for establishing ownership and identifying the right coordinator.

Context

First, let's outline three important roles:

1. Coordinator: The entity or team tasked with ensuring security information gets where it needs to go.
2. Fixer: The entity or team responsible for triaging and remediating security issues.
3. Owner: The entity legally responsible for the asset, typically footing the bill and reaping the benefits.

Notice the order? It's intentional because that's usually how the conversation flows best. Frustration often occurs when finders accidentally invert this order, sending reports straight to owners without going through a coordinator first.

Note: This post focuses on dynamic, publicly-addressable systems. We'll tackle non-hosted assets in a future post.

Problem Overview

Finding the right owner or coordinator can be tricky. Organizations change hands, assets are often hosted by third parties, and it's easy to mistakenly contact the wrong party (like a cloud provider instead of the asset owner). A clear example of ownership makes this easier:

Example

Google owns Google Android, the Android development team fixes issues, and Google coordinates vulnerability reports. Because they're established, Google clearly communicates this—but what if the organization you're helping isn't as organized?

Counter-example

When the Sakura Samurai crew found vulnerabilities in several Indian Government entities, they located the VDP page for India's National Critical Information Infrastructure Protection Centre (NCIIPC). Presuming NCIIPC coordinated for all Indian government assets, they reported their findings there, leading to significant confusion.

Why this matters

Beyond resolving the issue, correctly identifying ownership also matters for your own safety as a researcher. A perceived parent organization could react very differently from the actual asset owner. Organizations set their own disclosure policies, and researchers should align reporting practices accordingly, looking for safe harbor policies and clear reporting paths.

Tips

Okay, so how do you figure out who owns an asset and where you should report a vulnerability?

Forward lookup

1. Is the owner obvious? Always ask yourself more than once. If you're certain, start here.
2. Check disclose.io (diodb) for a known contact point, or see if there's a security.txt file on their main domain.

Reverse lookup

If it's unclear, or you just want to double-check, try these steps in this priority:

1. Security.txt: This internet standard (RFC 9116) provides authoritative security contacts. Look for it at /.well-known/security.txt.
2. Whois lookup: Run a Whois search (via command-line or online lookup) on the FQDN to find contacts like security@ or abuse@.
3. Authoritative DNS: Identify who owns the DNS server handling the FQDN (tools like dig can help here).
4. crt.sh (Certificate Transparency): Check certificates at crt.sh to reveal organizational details.
5. Direct certificate inspection: Inspect SSL certificates directly served by the target to find owner details (e.g., the certificate issuer or company name).
6. Legal notices: Look at the site’s footer, privacy policy, or legal section—legal entity names here can clarify ownership.
7. ASN lookup: If there's no clear domain, perform an ASN lookup on the IP address to pinpoint the network owner.
8. Google it! Quick searches like "[Company] vulnerability disclosure policy" often reveal if they have established reporting channels or bug bounty programs.
9. Bug bounty platforms: Check platforms like Bugcrowd, HackerOne, Intigriti, or any of the platforms listed at platforms.disclose.io to see if the company runs a known disclosure or bounty program.
10. Contact Us page: If no dedicated contact is listed, use a general form to politely request the right security contact (without disclosing vulnerability details yet).

Caution: Avoid mistaking hosting providers (AWS, Azure, Cloudflare) for the asset's actual owner. Remember, a vulnerability in a hosted application should go to the app owner, not the hosting company.

Catch-all

1. Local CERT (Computer Emergency Response Team): Almost every country hosts a CERT. If nothing else works, they're your safety net. Search "[country] CERT vulnerability report" for the proper contact. Remember, this option means you won’t directly interact with the asset owner, so it's usually a last resort.

Quick Checklist

• Check for /.well-known/security.txt
• Search disclose.io (diodb)
• Perform a Whois lookup
• Review DNS and certificate details
• Scan site footers/legal sections
• Check bug bounty platforms
• Use general contact forms if needed
• Contact the local CERT as a last resort

Tracking down an asset's owner might take some detective work, but the effort is worth it.