Inventory your public websites before the next CVE

The emergency patch notice says a WordPress, PHP, framework, or web-server flaw is being exploited. The first question should be “Where do we run it?” If the answer begins with a group chat and three people checking old bookmarks, the vulnerability process started too late.

A public website inventory is not just the main marketing domain. It includes campaign sites, client portals, old subdomains, redirect hosts, development environments accidentally left public, status pages, acquired brands, vendor-managed landing pages, and administrative interfaces exposed to the internet.

NIST Cybersecurity Framework 2.0 places asset management inside the Identify function, and CISA says asset visibility supports configuration, lifecycle, and vulnerability-remediation work. CISA’s asset-visibility directive applies to federal agencies, but the operational lesson travels well: you cannot manage a public service you cannot locate.

1. Start with authoritative business records

Do not begin by scanning the whole internet. Begin with systems the organization already owns and export what they know:

• Domain registrar accounts and renewal invoices
• Authoritative DNS providers and complete zone exports
• CDN, WAF, reverse-proxy, and load-balancer configurations
• Hosting panels, VPS accounts, cloud subscriptions, and static-site platforms
• Certificate-management systems and issued-certificate records
• Source-control organizations, deployment pipelines, and infrastructure-as-code repositories
• Accounting records for hosting, agencies, plugins, certificates, and domain renewals
• Marketing platforms, support portals, and SaaS products using custom domains

Collect records from acquired companies and previous providers too. A domain may be absent from the current registrar because another employee, developer, or agency registered it years ago.

Avoid treating the DNS zone as the complete inventory. A host can be reached through a vendor address without a friendly record, and an old domain can redirect before anyone recognizes the application behind it.

2. Normalize one record per public service

A spreadsheet is acceptable if it has an owner and review process. A small asset system is better when the list grows. At minimum, record:

Field	What to capture
Public name	Domain or hostname users reach
Purpose	Marketing, portal, redirect, API, admin, development
Business owner	Person accountable for whether it should exist
Technical owner	Internal team, MSP, developer, or named vendor
Platform	CMS/framework and known version where available
Dependencies	DNS, registrar, CDN/WAF, host, database, identity, email
Data class	Public-only, credentials, customer data, payments, regulated data
Operations	Patch, backup, logging, monitoring, and certificate owner
Lifecycle	Production, temporary, migration, or planned retirement
Verification	Last checked date, method, and result

“The web developer handles it” is not a technical owner unless the inventory names the company, contact path, contract, and division of responsibility. Hosted does not automatically mean patched, backed up, or monitored.

3. Safely validate what is actually reachable

For each known hostname, perform a normal browser or HTTP request from an authorized environment. Record the response status, redirects, certificate names and expiration, login exposure, and obvious ownership clues. Compare the result with DNS, hosting, and deployment records.

Use technology-detection results as leads, not truth. Generator tags disappear, proxies hide origins, and custom themes make an old CMS look new. Confirm versions in the administrative console, package lockfile, deployment manifest, or hosting panel where possible.

Only perform port scanning, directory discovery, or vulnerability scanning against assets you are authorized to test, within an agreed scope and rate. The inventory project is not permission to run intrusive tools against a vendor or a hostname that merely resembles the company name.

Flag these findings immediately:

• A public service with no business or technical owner
• A login or administration page without documented access controls
• An unsupported CMS, runtime, plugin, theme, or operating system
• A development or staging site containing production data
• A certificate, domain, or hosting account controlled by a former employee
• A site with no patching, monitoring, logging, or recovery path

4. Reconcile the inventory from both directions

Every public hostname should map to a business record, and every registrar, DNS, hosting, CDN, and certificate record should map back to an inventory entry. Investigate unmatched items rather than deleting them during the meeting.

Then compare identified platforms with vendor advisories and CISA’s Known Exploited Vulnerabilities Catalog. The catalog is a prioritization source for vulnerabilities known to be exploited; it is not a complete vulnerability scanner. When a relevant WordPress issue appears, use a documented workflow like the one in our WordPress CVE patch guide.

Link major public dependencies into the broader environment documentation. A one-page network diagram will not hold every web component, but it should show where public services cross into identity, databases, internal networks, and external providers.

5. Retire forgotten sites carefully

An unknown host is not automatically safe to delete. Before changing DNS or canceling a service:

1. Check recent traffic, DNS, WAF, authentication, and application logs.
2. Search code, documentation, monitoring, email templates, and third-party integrations for the hostname.
3. Identify data-retention, export, backup, and legal requirements.
4. Obtain business-owner approval and create a rollback window.
5. Preserve required content and configuration, then disable the application or origin.
6. Replace it with an intentional response or redirect where appropriate.
7. Monitor for broken dependencies before deleting infrastructure.

Keep control of domains the organization still needs for brand protection, email safety, or legacy links even after the old website is gone. Retirement may mean removing the vulnerable application while retaining the domain and a minimal managed endpoint.

6. Make discovery part of normal change

Reconcile the inventory on a recurring, risk-based schedule and after acquisitions, migrations, new campaigns, provider changes, and employee or agency offboarding. Require a new public service to have an owner, patch path, logging, monitoring, backup decision, and retirement date before launch.

During a critical advisory, filter the inventory by product and version, contact the named owner, record the mitigation, and verify from the public side. That is much faster than rediscovering the estate during every incident.

Bottom line

Build the public website inventory from registrar, DNS, hosting, CDN, certificate, code, and financial records; then safely validate what responds. Give every service a business owner, technical owner, patch path, and lifecycle state. The useful outcome is not a perfect spreadsheet. It is the ability to answer “Are we exposed, who owns it, and what happens next?” while the patch window is still open.