When a vulnerability advisory lands, the first question is not the CVSS score. It is: "Do we run this product? On which machines? Is any of it reachable from the internet?" If answering takes a round of chat messages and two or three days, you have lost the patching race before it starts. The reason is rarely technical. Usually the company has no trustworthy, maintained asset inventory, and nobody regularly looks at what the company exposes from the outside.

This guide is for IT staff and managers who receive advisories but cannot quickly tell what is affected. It explains why inventory comes first and which fields to record, how attackers find your systems from the outside, how a forgotten DNS record can become someone else's website, what Taiwan's rules require, and how to keep the inventory current and connected to patching. For ranking vulnerabilities and setting deadlines, read it together with Patch Management: How to Prioritize When You Can't Fix Everything.

Why inventory comes first, and what to record

The first two controls in CIS Critical Security Controls v8.1 are Inventory and Control of Enterprise Assets and Inventory and Control of Software Assets. Within them, maintaining an asset inventory (1.1), addressing unauthorized assets (1.2), maintaining a software inventory (2.1) and ensuring software is still supported (2.2) are all marked as applying to all three Implementation Groups, IG1, IG2 and IG3[1]. CISA's Binding Operational Directive BOD 23-01 puts it plainly: continuous and comprehensive asset visibility is a basic pre-condition for any organization to manage cybersecurity risk effectively[2]. The logic is simple: a host that is not on the list does not get scanned, does not get patched, and nobody notices when it is compromised.

The minimum to record for each asset

CIS requires the hardware inventory to record each asset's network address (if static), hardware address, machine name, asset owner and department, and whether it has been approved to connect to the network. It covers assets connected physically, virtually and remotely and those in cloud environments, and even assets that regularly connect to the network but are not under the enterprise's control[1]. The software inventory records the title, publisher, initial install or use date and business purpose, and where appropriate the URL, app store, version, deployment mechanism, decommission date and number of licenses[1].

The CIS fields focus on finding the machine. To answer an advisory's questions on the spot, add:

  • Owner and purpose: the system's business owner (not only the IT contact) and the business process it supports.
  • Criticality: you can borrow Annex 9 of Taiwan's Regulations Governing the Classification of Cyber Security Responsibility Levels, which rates a system low, medium or high on confidentiality, integrity, availability and legal compliance, and takes the highest of the four as the system's level[3].
  • Version and support dates: operating system, firmware and major software versions, plus the vendor's end-of-support date.
  • Exposure and environment: whether it is reachable from the internet, and whether it is production or test. CISA's BOD 26-04, issued in June 2026, requires federal agencies to continuously identify every asset reachable from outside the agency network and tag each one with its organization, environment (prod/dev), exposure (public/internal) and asset type[4].

How often to review

CIS v8.1 sets these frequencies: review and update the hardware and software inventories at least every six months; address unauthorized assets weekly; run an active discovery tool at least daily; check monthly that software on the list is still supported; and review unauthorized software monthly[1]. Six months is the floor for manual review. Automated comparison should run every day: export data from AD, EDR, MDM, DHCP, cloud accounts and firewalls, compare it with the inventory, and chase whatever does not match.

The external attack surface: seeing yourself as an attacker does

BOD 26-04 defines "publicly exposed" as any agency-owned or agency-managed IT resource accessible to unauthenticated or untrusted entities via public networks such as the internet, regardless of its physical or logical location[4]. The last clause is the important one: what sits in the cloud or is hosted by a vendor is still part of your attack surface. For a typical company, the external attack surface includes:

  • Hosts and services on the company's public IP addresses: VPN, mail, websites, remote desktop, device management interfaces. Why management interfaces should not face the internet is covered in Hardening Checklist for VPNs, Firewalls and Other Edge Devices.
  • Every domain and subdomain the company owns, including DNS records that point to external services.
  • Cloud resources: virtual machines, object storage, public APIs and container services, often set up by project teams on their own.
  • Forgotten sites: test servers, old system versions, campaign sites, event registration pages, and projects whose partnerships have ended.
  • SaaS tenants: company accounts and admin consoles in Microsoft 365, Google Workspace, CRM and file-sharing services; for configuration baselines see Microsoft 365 and Google Workspace Security Baseline.
  • Third-party-hosted assets: outsourced systems still hosted by the developer, campaign sites built by marketing agencies, and hosted services running under the company's domain.

How attackers find you

All three of the sources below are public. An attacker does not need to break into anything to assemble a list of your external assets:

  • DNS: starting from the company domain, query DNS records and guess common subdomain names. In explaining subdomain takeover, Microsoft notes that attackers use commonly available methods and tools to find subdomains pointing to deleted resources[5].
  • Certificate Transparency (CT) logs: a certificate ties a domain to a public key, and certificates are deposited in public, append-only logs that anyone can query to see which certificates were included and when; browsers such as Chrome and Safari help enforce CT[6]. In other words, once a public certificate has been issued for test.example.com.tw, that name can be looked up. crt.sh is one public certificate search site[7].
  • Internet search engines: Shodan describes itself as a search engine for internet-connected devices. It queries devices directly connected to the internet for publicly available information, and most of its data comes from banners, the metadata of software running on a device, such as the server software and the options it supports[8]. One use case Shodan gives is a new vulnerability coming out and wanting to see how many hosts it could affect[8].

Look at yourself first, and set a rhythm

Shodan lists keeping an eye on all of a company's internet-facing devices as one of its uses[8], and defenders can do exactly that:

  1. List every domain the company holds (including subsidiaries, brands and campaign domains), plus the registrar and DNS hosting accounts, and export each domain's DNS records.
  2. Search CT logs for your domains to find hostnames missing from the inventory, then subscribe to a CT monitor so you are notified whenever a certificate for your domains is logged[6].
  3. Look up your IP ranges and domains in internet search engines to see which services and versions the outside world sees.
  4. Run an external port and service scan of your own public IP addresses, only against ranges you own or are authorized to test, and compare the results with the inventory.
  5. Find an owner for every item that does not match, and decide whether to add it to the inventory, shut it down or move it back inside.

How often? BOD 23-01, issued on 3 October 2022, required US federal civilian agencies by 3 April 2023 to perform automated asset discovery every 7 days, covering at least the agency's entire IPv4 space, and to initiate vulnerability enumeration across all discovered assets, including laptops and other roaming devices, every 14 days, using privileged credentials where possible[2]. BOD 26-04, issued in June 2026, still uses the time an agency enumerates a vulnerability under BOD 23-01 as one of the starting points for its remediation deadlines[4]. Both directives bind only US federal civilian agencies and have no force for Taiwanese companies, but "discover assets weekly, scan for vulnerabilities every two weeks" is a practical rhythm to borrow. For choosing and procuring scans and penetration tests, see Vulnerability Scanning, Penetration Testing and Red Teaming.

Dangling DNS and subdomain takeover

One of the most common findings of an external inventory is a DNS record pointing to a resource that no longer exists. Microsoft's example is concrete: you create a web resource in Azure with a name such as app-contogreat-dev-001.azurewebsites.net and add a CNAME in your DNS zone that points greatapp.contoso.com at it; when the project ends the resource is deleted but the CNAME is not, and the record becomes a "dangling DNS" entry[5]. Once attackers find it, they only need to create a resource with the same name in their own subscription, and traffic sent to your subdomain reaches a site they control; CNAME records are especially vulnerable[5].

The consequences Microsoft lists include[5]:

  • Loss of control over the subdomain's content: it can host malicious content, damaging the brand and trust.
  • Cookie harvesting: many web apps expose session cookies to all subdomains, so an attacker can build a convincing page on the hijacked subdomain to collect them. Attackers can also obtain a valid SSL certificate for the hijacked subdomain, so a certificate does not prove the site is yours.
  • Phishing: authentic-looking subdomains are used in phishing; if an MX record is left dangling, attackers may even receive mail sent to that subdomain.
  • Follow-on attacks: escalation into XSS, CSRF, CORS bypass and similar attacks.

What Microsoft recommends[5]:

  • Put "remove DNS entry" on the checklist for decommissioning a service, and add delete locks to resources with custom DNS entries as a reminder that the DNS mapping must be removed before the resource is deleted.
  • Review DNS records regularly to confirm every subdomain points to a resource that still exists and that you own.
  • Maintain a service catalog of public endpoints and application owners, and regularly export resource endpoint information from the cloud platform.
  • Use the platform's domain verification: Azure App Service's asuid TXT record, for example, stops other subscriptions from validating and taking over your custom domain, and Azure DNS alias records tie a DNS record's lifecycle to the resource so the record no longer points to it once it is deleted, though only a few services are supported.
  • When you find a dangling record, delete it or point it at a resource you own, investigate whether it was abused, and find out why it was not removed at decommissioning.

Microsoft's documentation uses Azure as the example, but any setup where a custom domain points at a cloud or hosted service is worth checking the same way.

What Taiwan's rules require

Cyber Security Management Act: maintenance plans must include a system inventory

Under the Enforcement Rules of the Cyber Security Management Act as amended on 5 January 2026, Article 9 requires the cyber security maintenance plans that government agencies and specific non-government agencies draw up under the Act to include "an inventory of information and communication systems, identifying core systems and related assets"[9]. For which companies count as specific non-government agencies, see Taiwan's Cyber Security Management Act: who must comply and what they must do.

Under the Regulations Governing the Classification of Cyber Security Responsibility Levels as amended on 7 January 2026, Article 11 requires government agencies and specific non-government agencies to classify the systems they develop in-house or through contractors according to Annex 9 and apply the Annex 10 baseline controls[3]. The obligations for levels A, B and C (Annexes 1 to 6, one each for government agencies and specific non-government agencies) go further: after classification and controls are in place, the classification and baseline must be reviewed for adequacy at least once a year[3]. Levels A and B must complete this within one year of first designation or a level change; level C must finish classification within one year and the controls within two; the same applies when a system is added or its classification changes[3]. These six annexes also define vulnerability management as combining information asset management with vulnerability management to support asset inventory and risk assessment[3]. The obligations for level D (Annex 7) and level E (Annex 8) do not list a deadline or annual review for this item[3].

TWSE Cybersecurity Control Guidelines for Listed Companies

TWSE revised the Cybersecurity Control Guidelines for Listed and OTC Companies in November 2026; the comparison table is dated 9 November 2026 (ROC year 115)[10]. The articles in the new text that bear on inventory:

  • Article 11: "Periodically inventory information and communication systems and establish an information asset register for core systems to identify the value of those information assets." Unchanged in this revision[11].
  • Article 16 (new): identify the third-party software, services, libraries or other components that systems use, and preferably require suppliers by contract to report security vulnerabilities proactively and provide patches within a set time[10].
  • Article 17: core systems must undergo vulnerability scans, penetration tests and other testing with findings remediated; the new text adds that internet-facing systems should, based on risk assessment, undergo appropriate tests chosen from the list[10].
  • Article 29: establish security procedures for reusing and disposing of equipment so that sensitive data is reliably deleted; this is the former Article 28, renumbered without change[10].

Under Article 44, unless laws or TWSE and TPEx rules provide otherwise, companies may adopt the guidelines as appropriate to their industry, size and cyber risk[10]. Still, "we can't say which systems we have" is hard to defend in any audit.

Keeping the inventory alive: process and patching

Who owns it, and where it lives

The inventory needs one overall owner (usually IT) to maintain its format, completeness and reconciliation process, but each asset's owner should be the business owner of the system that uses it; IT cannot answer "do we still need this?" on a business unit's behalf. A CMDB or a shared spreadsheet both work. What matters is that there is only one, that it can be exported, and that it includes non-host assets such as registrar, DNS hosting, cloud subscription and SaaS admin accounts.

How new assets get in

  • Procurement: purchase requests must state the owner, purpose and whether the asset faces the internet; register it before acceptance.
  • Cloud: new accounts, subscriptions and projects go through IT, and resource lists are exported regularly through the cloud platform's API for comparison.
  • Domains and websites: one point of contact handles domain registration and DNS changes; campaign sites are registered before launch, with an end date.
  • Outsourcing: ask vendors which third-party software and components their systems use, and require them by contract to report vulnerabilities proactively and patch within a set time, which is the direction of Article 16 of the TWSE guidelines[10]; for wider supply-chain risk, see Supply Chain Attacks.

How assets are retired

  • DNS first, resource second: remove the DNS record before deleting the cloud resource[5]; withdraw related inbound firewall rules and NAT mappings at the same time.
  • Revoke access: disable service accounts and API keys, and revoke certificates no longer in use.
  • Update the inventory: mark the asset decommissioned with the date; the CIS software inventory has a decommission date field for this[1].
  • Wipe data: delete sensitive data according to procedure before equipment is scrapped or reused, matching Article 29 of the TWSE guidelines[10].

Connecting it to advisories and patching

CISA calls the KEV catalog the authoritative source of vulnerabilities exploited in the wild and advises organizations to use it as an input to their vulnerability management prioritization; each entry names the vendor or project and the product, and the catalog can be downloaded as CSV or JSON[12]. If the inventory has consistent vendor, product and version fields, you can compare new KEV entries against it automatically every day and move any hit on an internet-facing system straight to the top priority tier; for tiers and deadlines see patch prioritization, and for what the scores mean see Reading Vulnerability IDs and Scores: CVE, CVSS, EPSS and KEV. The same matching works for this site's advisories. The inventory also defines the scope for vulnerability scans and security health checks: without it, you can only scan the machines someone remembers. If you lack the staff for a first external inventory, consider a vulnerability assessment.

A few metrics are worth reporting to management monthly: the share of discovered assets that are in the inventory, the number of internet-facing assets without an owner, the number of unsupported software products still in use, and the number of dangling DNS records found and removed.

Action checklist

  • This week, list every company domain, registrar, DNS hosting service and cloud account, and assign an owner to each.
  • Look up your domains and IP addresses in CT logs and internet search engines, find hosts missing from the inventory, and track down an owner for each.
  • Check every CNAME and MX record that points to an external service, and delete or fix any that point to resources that no longer exist.
  • Add owner, purpose, criticality, version, end-of-support date, internet exposure and production/test fields to the inventory.
  • Write "remove the DNS record before deleting the resource" into the system decommissioning checklist.
  • Require procurement, new cloud accounts, domain registrations and campaign sites to be registered in the inventory first.
  • Set a rhythm: automated discovery daily or weekly, external vulnerability scans at least every two weeks, manual inventory review at least every six months.
  • Compare KEV and this site's advisories with the inventory every day and subscribe to alerts; handle hits on internet-facing systems according to your patch tiers.
  • Organizations covered by the Act: confirm records of system classification and the annual review. Listed companies: check Articles 11, 16, 17 and 29 of the TWSE guidelines.