Parts 1 and 2 showed how hunters map a company’s attack surface. Attackers run the same recon against your company every day, mostly automated. This part is for the people defending it: how to run that recon on yourself first, and close what it finds.
1. Know what you own
You can’t protect a server nobody remembers. Most serious external findings we see are on assets the security team didn’t know existed: a staging site from two years ago, a marketing microsite on an agency’s hosting, a test bucket someone forgot to delete.
Start with an inventory, and give every entry an owner.
| Asset type | Where to find yours | Record for each |
|---|---|---|
| Domains | Your domain registrar accounts, certificate transparency logs (crt.sh) for every name ever issued a certificate | Owner, renewal date, which team uses it |
| Subdomains and DNS records | Your DNS provider’s zone files, plus a passive subdomain search like Part 1’s first stage | What it points to, whether it’s still in use |
| Public IP ranges | Your cloud accounts and hosting contracts | Which services run there |
| Cloud accounts | Billing records across AWS, Azure and GCP, including ones teams opened on their own | Owner, purpose, whether storage is public |
| Code repositories | Your GitHub or GitLab organisation, plus public repos created by staff | Whether secret scanning is on |
| Third-party services | SaaS sign-ups, agency-built sites, status pages, help desks | Who administers it, what data it holds |
| AI services | Self-hosted models, MCP servers, chatbot features | Whether authentication is required |
The owner column matters most. When an alert fires on an asset, someone has to know it’s theirs and decide whether it should exist at all.
2. Watch for change
An inventory is out of date the week after you finish it. Part 2 showed hunters running recon every few hours to catch new assets first. Run the same loop on yourself, and you see a new exposure before they do.
Set alerts on these events:
- A new certificate is issued for your domain. Certificate transparency logs are public, and free monitors (such as Cert Spotter or Facebook’s CT monitoring) email you when one appears. A certificate you didn’t expect means a new site, or someone impersonating you.
- A DNS record is added or changed. Most DNS providers log changes; send them to your team’s chat.
- A cloud resource becomes public. AWS, Azure and GCP each have built-in checks that flag public storage and open security groups.
- A secret is pushed to a repository. Turn on GitHub’s secret scanning and push protection for your organisation, so leaked keys are blocked before they land.
- A new host answers on your IP ranges. Run a weekly scan of your own ranges and compare it with last week’s.
Send every alert to the asset’s owner from your inventory, not to a shared inbox nobody reads.
3. Close the common exposures
Each recon technique in Parts 1 and 2 works because of a specific mistake on the defender’s side. Fix the mistake and that technique finds nothing.
| What recon finds | Why it happens | The fix |
|---|---|---|
| Forgotten staging and dev sites | Environments are created for a project and never removed | Put non-production sites behind SSO or a VPN; delete what’s unused |
| Dangling DNS records (subdomain takeover) | A cloud service is deleted but its DNS record stays | Remove DNS records in the same change that deletes the service |
| Origin server reachable around the CDN | The server accepts traffic from anywhere | Allow inbound web traffic only from your CDN’s published IP ranges |
Exposed .git, .env or backup files |
Files deployed to the web root by mistake | Deploy build output only; block dotfiles and backup extensions at the web server |
| Public source maps | Build tools publish them by default | Turn off source maps in production builds, or upload them only to your error tracker |
| Admin routes visible in JavaScript | The front end ships every route to every user | Split admin code into a separate bundle, and enforce access on the server for every route |
| Old API versions still answering | New versions ship but old ones are never retired | Keep a list of live API versions with retirement dates; old versions get the same access checks |
| Secrets in public repos and images | Keys committed by mistake | Rotate the key first, then remove it; turn on secret scanning and push protection |
| Public cloud storage | A bucket set public for a quick test | Block public access at the account level; allow exceptions only by review |
| Unauthenticated AI and MCP endpoints | Shipped as internal tools, then exposed | Require authentication on every model API and MCP server; never expose them directly to the internet |
Rotating a leaked key comes before deleting it from the repo. Once a secret has been public, assume someone copied it; deleting the commit doesn’t take it back.
4. Make it easy to report what you missed
No inventory is perfect. When a researcher finds something you missed, you want the report in your inbox, not posted publicly or sold. That takes three steps, in this order:
-
Publish security.txt. A small text file at
/.well-known/security.txttells researchers where to report. It takes ten minutes.Contact: mailto:security@example.com Expires: 2027-06-30T23:59:59Z Policy: https://example.com/security Preferred-Languages: en -
Publish a vulnerability disclosure policy (VDP). Say what’s in scope, how to report, how fast you’ll reply, and that you won’t take legal action against good-faith research. The open-source disclose.io templates are a good starting point.
-
Run a bug bounty program once your team can fix reports quickly. Start private, with a small group of invited researchers, before opening it to everyone.
The reply time matters as much as the policy. A researcher who waits weeks for an answer stops reporting to you.
5. A 30-day plan
You don’t need a large team to start. One engineer with a few hours a week can cover most of this in a month.
Week 1: inventory
- List every domain from your registrar accounts and certificate transparency logs
- Export DNS zones and mark each record as in use or unused
- Find every cloud account through billing records
Week 2: quick fixes
- Delete unused DNS records and environments
- Block public storage at the account level
- Turn on secret scanning and push protection
- Turn off production source maps
Week 3: monitoring
- Set up certificate transparency alerts
- Send DNS and cloud change alerts to asset owners
- Schedule a weekly scan of your own IP ranges
Week 4: reporting
- Publish security.txt
- Publish a disclosure policy
- Book an external test of everything the inventory found
The last step matters because you test your own assets with your own assumptions. Someone outside will look where you didn’t.
SecureDX runs attack surface reviews using the methods in this series: we map what you own, test it by hand, and help you set up monitoring and a disclosure program. Get in touch at securedx.in/contact.
Loading comments…