Asset, Data, and Dependency Inventory

The illustrative refund console from the previous chapter appears in the service catalog as one application owned by Support Engineering. That record is accurate. It is also dangerously incomplete.

A refund begins at a browser, crosses an identity provider and an API gateway, enters the console service, places work on a queue, and reaches a payment processor through a worker. The service reads customer and transaction data, writes audit events, and exports reports to object storage. Its container inherits packages from a base image built by another team. A disabled operator account may still hold a live session. During an incident, each of those facts changes what responders must contain, search, revoke, patch, or restore.

Inventory is the work of making that connected system visible before urgency demands it.

A name is the beginning of the record

An asset is not managed until the team can name its owner, exposure, data, identities, dependencies, telemetry, and recovery expectations. A catalog entry answers “What do we call it?” Security work asks what can reach it, what it can reach, what happens if it is compromised, and who can act when those answers change.

Start with a stable identifier, not a display name alone. Connect the refund console to its repository, deployment, cloud resources, service-catalog entry, and operational dashboards. Names change; identifiers and links allow a scanner finding, an alert, and an incident ticket to converge on the same system.

Then record the people and decisions around it. The engineering owner maintains the service. The operations owner carries alerts and recovery. The data owner governs customer and transaction use. The escalation path must reach a person who can respond. “Payments” is useful routing information, but it is not sufficient if three teams use that name and none owns the production workload.

Criticality and exposure need concrete meanings. Record the business operation that fails, the tolerable interruption, and important downstream effects. Describe every public, partner, internal, private, and administrative path rather than choosing the most reassuring label. A console may be “internal” to customers while remaining reachable from any employee device through the corporate identity provider.

Follow the system, not the organization chart

A useful taxonomy prevents teams from stopping at deployable services. Follow the refund operation outward and several asset classes appear:

• the browser application, API, worker, scheduled reconciliation job, and their workloads;
• the customer database, cache, queue, dead-letter queue, report bucket, logs, backups, and analytics copies;
• operator accounts, service identities, roles, groups, OAuth applications, API keys, signing keys, and emergency credentials;
• gateways, load balancers, ingress rules, private links, firewall rules, peering, and administrative network paths;
• repositories, build runners, registries, deployment jobs, container images, base images, operating systems, and runtime packages;
• payment, identity, messaging, support, cloud, and other third-party services.

AI-enabled systems extend the same map. Include hosted models, fine-tunes, prompt templates, retrieval stores, tool permissions, provider accounts, prompt and output logs, and evaluation datasets. A model name without the data and tools around it is no more useful than a service name without its database and identity.

Apply the taxonomy to production, staging, development, test, and disaster-recovery environments whenever they connect to real identities, data, secrets, or delivery paths. A forgotten staging deployment with production data and a public hostname belongs in the attack surface even if the release process calls it non-production.

Build one response-ready record

The first pass for the console might look like this:

Asset: refund-console / service-catalog:svc-1842
Environment: production, eu-west
Engineering owner: Support Engineering
Operations owner: Commerce on-call
Escalation: commerce-incident
Purpose and criticality: issue and reverse refunds; four-hour recovery target
Exposure: employee browser -> identity proxy -> public gateway -> console API
Data: customer identifiers, transaction metadata, refund reason, operator audit trail
Human identity: workforce SSO; refund-operator and refund-supervisor roles
Workload identity: console-api -> queue; refund-worker -> payments provider
Dependencies: workforce IdP, gateway, customer DB, refund queue, worker,
  payments provider, audit pipeline, report bucket, container image
Telemetry: gateway access, authentication, refund decision, queue, worker,
  provider response, admin change; links and retention recorded
Recovery: redeploy from signed image; restore configuration and queue safely;
  reconcile provider state before replay
Last verified: 2026-07-18 by deployment and runtime discovery, owner reviewed

This is a working record, not a universal schema. A mobile client needs signing and distribution facts. A database needs replicas, snapshots, access roles, and restore evidence. A build runner needs trust level, repository reach, network access, and credential scope. Preserve the questions—ownership, exposure, data, identity, dependency, telemetry, recovery, and verification—while allowing asset-specific detail.

The last line is essential. “Last updated” may describe a nightly import that copied stale tags. “Last verified” names the mechanism and the accountable reviewer. Without it, the record gradually becomes folklore.

Trace data until it disappears

The asset record says that the console handles customer identifiers and transaction metadata. The data inventory must say more: where each group originates, which system owns authoritative updates, which stores and copies receive it, who and what can access it, and when it should disappear.

Trace a refund reason through the primary database, cache, queue payload, dead-letter queue, audit event, report export, support ticket, analytics table, backup, and local debugging path. Record its classification at each material copy, including credentials, secrets, personal or regulated data, customer-confidential data, security telemetry, and model training or evaluation data. Connect retention and deletion triggers to the stores that must enforce them. Record use restrictions such as support access, analytics, sharing, regional processing, debugging, and AI use.

The most dangerous copy is often not the primary database. It may be a verbose log visible to a broad engineering group, a spreadsheet export with no expiry, a replay queue retaining full payloads, a prompt trace held by a provider, or a backup no one can search during a deletion request. Chapter 6 will turn classification into protection requirements. This inventory supplies the complete set of copies to which those requirements must apply.

Make dependencies answerable under pressure

When a vulnerable package or compromised vendor is announced, the first operational question is not “Does this name occur anywhere?” It is “Where is the affected component running, what can reach it, what authority does it hold, what data does it touch, and how do we remove or contain it?”

Link open-source packages, container and base images, operating systems, language runtimes, cloud services, SaaS integrations, AI models and APIs, build tools, plugins, registries, and runners to the assets that use them. For each important edge, retain version or configuration, runtime presence, exposure, privilege, data access, update owner, normal update mechanism, and emergency removal path.

The refund worker’s image, for example, inherits a cryptographic library from a shared base image. The software bill of materials establishes that the package is present. The connected record reveals that the worker is not internet-facing, can read a refund queue, holds payment-provider authority, and is replaced through the base-image pipeline. Those facts determine urgency, containment, testing, and ownership. Presence alone cannot do that.

Third-party dependencies need the same rigor. Record the service owner, account and integration scope, data exchanged, administrative delegation, authentication, logs, contractual exit or export constraints, and a way to disable the integration. “Vendor managed” does not remove the dependency from the system; it changes the controls available to the team.

Let machines discover; require owners to explain

The delivery and operating environment already knows much of the inventory. Infrastructure as code can reveal declared resources, networks, storage, and policies. Cloud inventory can reveal what is actually running, including public exposure, identities, regions, and drift. Repositories and build systems know code owners, dependencies, branch protections, images, registries, and deployment jobs. Runtime observation finds active services, ports, calls, containers, and jobs. Identity and secret systems reveal privileged assignments, stale accounts, credential age, rotation, and consumers. Vulnerability tools and software bills of materials connect packages to artifacts. DNS, certificate transparency, and external scanning can suggest public hosts and forgotten endpoints.

No single source is authoritative for the whole record. Declared infrastructure misses manual resources. Cloud discovery sees a bucket but not why the business needs it. Network observation may miss rarely used recovery paths. Repository metadata finds a library that is built but not loaded at runtime. An external scanner sees a hostname but not whether it should exist.

Treat discoveries as claims to reconcile:

1. Create or update a suspected record with source and observation time.
2. Link matching identifiers rather than guessing from similar names.
3. Ask the owner to supply purpose, criticality, data use, recovery, and exception context.
4. Compare declared, built, deployed, and observed state.
5. Alert on unexplained additions, missing required fields, conflicting facts, and records that have not been verified within their review interval.
6. Retire a record only after the asset is gone, its identities and secrets are revoked, retained data is handled, and required evidence is preserved.

Fully manual inventory decays. Fully automatic inventory produces confident lists without accountable meaning. The control is the reconciliation between them.

Triage what discovery exposes

An unknown asset is a security condition, not evidence of misconduct. Establish ownership and reduce exposure before debating how it escaped the catalog.

For an unowned service, assign a temporary operational owner, determine criticality, and set a deadline for a permanent ownership or retirement decision. For an unexpected external API, identify callers, authentication, data, logs, and business purpose; restrict or shut it down if no one can justify it. If a forgotten environment contains real data or accepts public traffic, remove the exposure, rotate reachable secrets, and examine access before returning it to service.

Treat an orphaned credential as authority without accountability: disable it when unused, or rotate it and bind its consumers, owner, scope, and expiry when still required. Restrict an undocumented export, backup, log stream, analytics table, or prompt trace while the owner establishes classification, access, retention, and deletion. An untracked model or agent also requires tool scopes, provider retention, logging, and approval to be made explicit. Where a real asset has no security telemetry, add the minimum events needed for response or record a bounded exception with an owner and expiry.

Containment should preserve evidence. Deleting an unknown workload immediately may erase the only path to understanding whether it was exposed or abused. Quarantine, snapshot, or otherwise preserve what incident responders need when compromise is plausible.

Keep the outside view small and sharp

Maintain a focused register of internet- and partner-reachable surfaces even when the richer asset graph exists. Responders and reviewers need a fast outside-in view: host or endpoint, owner, purpose, authentication, data, network controls, rate and abuse controls, relevant logs, and the date and evidence of the last review.

The refund console’s public gateway belongs here despite requiring workforce authentication. So do webhook receivers, administrator consoles, file-transfer endpoints, VPN gateways, mail services, model endpoints, and public object stores. Reconcile DNS, certificates, gateways, cloud addresses, content-delivery configuration, and externally observed services against the register. A new observation should produce a named investigation; a retired entry should disappear from both the register and the reachable network.

Public does not automatically mean unsafe. Forgotten, unowned, unexpectedly unauthenticated, or unlogged exposure is unsafe because no one can defend the assumptions around it.

The release question

Treat inventory as release-critical when a system handles sensitive, regulated, confidential, credential, or security-telemetry data; faces the internet or a partner; changes access, money, entitlement, infrastructure, model behavior, or customer state; holds privileged cloud, database, identity, or delivery permissions; or is required for incident response and recovery.

Before release, a reviewer should be able to start from the asset and reach:

• a named owner and escalation path;
• every public, partner, internal, private, and administrative exposure;
• the highest data classification and the important stores, copies, flows, and deletion paths;
• human, workload, vendor, and emergency identities with their authority;
• upstream, downstream, software, image, build, cloud, SaaS, and AI dependencies;
• security events, their location and retention, and the response path they support;
• a rebuild or restore expectation tested against stateful dependencies;
• evidence of how and when the record was last verified.

The refund console is no longer one opaque box in a catalog. It is a traversable set of claims that design reviewers can challenge, vulnerability teams can query, responders can follow, and owners can correct. Chapter 6 can now classify its data without guessing which copies exist.

An incomplete record does not merely leave a blank field. It places a hidden assumption inside every security decision that follows.