From Asset Register to Security Control: Lessons from Re-architecting a Legacy ITAM Integration into

seungchulkim · 11m ago

From Asset Register to Security Control: Lessons from Re-architecting a Legacy ITAM Integration into CMDB

Tags: CMDB, ITAM, IntegrationHub, IRE, Import Set, Software Asset Management, Vulnerability Response

Context

Over the past several months I led the design and build of an integration that moved a large enterprise client's in-house ITAM (tens of thousands of servers and tens of millions of software and OS package records) into ServiceNow CMDB. Client details are anonymized.

The stated objective was data migration. The objective that actually mattered was defensible EOL/EOS visibility, because that is now what security and audit teams ask the CMDB for first.

This note covers why that shift matters, how we structured the integration, and the decisions I would recommend to teams planning something similar.

1. Why EOL/EOS visibility is now a security requirement

EOL tracking used to be an asset hygiene topic. Over the last 18 months it has become a threat-driven and regulatory one.

Threat data. VulnCheck's 2026 analysis of exploited network edge device vulnerabilities found that 42.5% of those exploited in 2025 affected end-of-life or likely end-of-life products, rising to 65% for vulnerabilities exploited by botnets.
US federal. CISA's BOD 26-02 (February 2026) requires agencies to inventory end-of-support edge devices, remove them within 12–18 months, and establish continuous lifecycle management within 24 months. CISA has stated it intends the directive to set a standard beyond federal agencies.
Payments. PCI DSS v4.0.1 Requirement 12.3.4, mandatory since 31 March 2025, requires an annual review of hardware and software in use, including vendor EOL announcements and a remediation plan.
Korea. The government's cross-ministry cybersecurity plan (October 2025) launched a vulnerability review of roughly 1,600 critical IT systems and a shift to on-site ISMS audits. IT asset identification has been added to the mandatory security disclosure, and the 2026 ISMS-P reform introduces a pre-audit check on internet-facing asset identification and patch management.

The implication for CMDB owners: an EOL report is only as defensible as the asset inventory and software normalization underneath it. If the CI is duplicated, orphaned or mis-identified, or if the software name cannot be matched to a product, the EOL date is either wrong or missing, and an auditor will find it.

2. Target architecture

We separated the pipeline into layers that can be operated and reloaded independently.

Layer Component Design choice

Source	Legacy ITAM (system of record)	Hosts as a daily full snapshot; SW installs as insert/delete events; OS packages as bulk files
Ingestion	Import Set staging (Host / SW / OS package)	Source pushes via REST (OAuth). Staging schema agreed with the source owner up front
Ingestion	Change detection	Row-level hash; unchanged rows are skipped before transform
Identify & reconcile	IRE	Source key mapped to correlation ID; no hostname fallback
Identify & reconcile	Reconciliation rules	Discovered attribute values take precedence over ITAM-registered values
CMDB	Server CI, software package / instance	Display name set to the standard product; raw name retained
Lifecycle intelligence	Normalization rules → standard product → lifecycle	Rule table rather than script; endoflife.date as the external reference; OS packages inherit host OS dates
Governance	Scheduled lifecycle job	Absent from today's snapshot → Retired; reappears → reinstated

3. Six design decisions that shaped data quality

Area Alternative considered Decision Rationale

Integration pattern	Scheduled pull from source DB	Push to Import Set via REST	Clear ownership boundary; staging can be reloaded without touching the CMDB
Change detection	Source-side delta flags	Full daily snapshot + row hash	Delta flags drift over time; hashing keeps processing cost proportional to actual change
CI identification	Match on hostname	Source key only; create if unmatched	Hostname reuse silently merges different assets and corrupts history
Decommissioning	Manual retirement	Absence-based retire, automatic reinstatement	Orphan CIs inflate scope for licensing and vulnerability reporting
Data ownership	Last writer wins	Discovered attributes override ITAM	Measured values are more reliable than registered values
CI type scope	Create NIC / IP CIs from ITAM	Server CIs only; network left to Discovery	Avoid creating CIs from a source that is not authoritative for them

One additional point that is easy to miss: some OOB cleanup jobs assume they own the records they touch. We found platform logic removing software installs that the integration had loaded. We scoped integration-sourced records out of those jobs and let the source's own delete events drive removal.

4. EOL coverage: the problem was normalization, not lifecycle data

At the start, EOL/EOS coverage across installed software was around 10%. The instinct was to look for a better lifecycle data source. The root cause was upstream.

Root causes

Name variance. The same product arrived under many free-text names (e.g. Apache httpd 2.4.x (custom), httpd-2.4, APACHE HTTP SERVER; examples illustrative).
Inconsistent version strings. Build numbers and vendor suffixes prevented matching to a release cycle.
OS components without their own lifecycle. OS packages had no product-level EOL record.
Script-embedded rules. Normalization logic lived in code that operators could not maintain.

Remediation

Rule-table normalization. Raw name → standard product + version, with the raw value preserved for audit.
Suggest-and-approve workflow. Operators were not going to maintain regular expressions. The platform proposes candidate rules and operators approve them with a preview.
OS inheritance. OS packages inherit the EOL/EOS dates of the host operating system.
External lifecycle reference. endoflife.date, kept independent of licence-dependent content.

KPI definition. We count only catalog matches and OS-inherited dates as covered. Inferred matches are tracked but excluded, so the number holds up in audit.

5. Recommendations

Lock the staging schema with the source owner before building transforms. It is the hardest artefact to change later and the clearest line of accountability.
Prefer full snapshots with hash-based change detection where volumes allow. Retirement becomes a deterministic rule rather than a reconciliation exercise.
Define identification and decommissioning rules before field mappings. In my experience, most CMDB defects trace back to identity, not attribute mapping.
Run software normalization as an operating process, not a one-off script. Assign ownership and an approval step; this is what drives EOL coverage.
Keep the core data model independent of licence-dependent tables until the commercial decision is final, and design for both outcomes.
Optimize for operability over abstraction. We built shared UI components across several pages and later reverted them, because self-contained pages were easier for the run team to maintain.

Open questions for the community

How are you handling retirement for CIs fed by a non-discovery source: absence-based, event-based, or manual?
Has anyone run software normalization as an approval workflow at scale, and how did you keep the rule backlog manageable?
For those subject to PCI DSS 12.3.4 or similar, what evidence from CMDB has your assessor accepted?

Happy to discuss implementation details in the comments.