Ask most security teams what assets they have and you'll get a confident answer. Ask for the actual list and you'll find it's six months old, stored in a spreadsheet, and excludes everything that was deployed after the last "asset audit." For vulnerability management, an incomplete inventory doesn't just create gaps — it creates false confidence. You're not measuring "what's unpatched in my environment." You're measuring "what's unpatched in the subset of my environment that I know about."
In a static on-premises data center with 200 physical servers, maintaining a current inventory is a solved problem. In a hybrid environment that spans AWS auto-scaling groups, Azure AKS clusters, on-prem vCenter, and three acquisitions worth of legacy infrastructure, it's not. The inventory problem is one of the least glamorous parts of vulnerability management and one of the most consequential.
Why Ephemeral Resources Break Traditional Inventory
The core challenge of cloud-native inventory is that the asset count changes continuously. An ECS service running in AWS might be backed by 3 container instances at 2 AM and 18 at 2 PM. Auto-scaling groups launch and terminate instances based on demand metrics. Lambda functions run for seconds and disappear. Kubernetes pods are scheduled, crashed, and rescheduled multiple times per day. A point-in-time asset scan — the standard approach for on-premises environments — captures a snapshot that's stale within minutes.
For vulnerability management, the implication is that your scanner's asset list can't be populated from a weekly nmap sweep or an CMDB export. It needs to be populated from cloud provider APIs that reflect the current state of your infrastructure in real time. AWS Resource Groups Tagging API, Azure Resource Graph, and GCP Asset Inventory all expose queryable interfaces to the current resource state — including when resources were created, their current status, and their configuration attributes. PatchGuard polls these APIs on a configurable interval (default 30 minutes) to maintain a live inventory that auto-populates the patch queue as new assets appear.
Auto-Scaling Groups and the Patching Timing Problem
Auto-scaling groups (ASGs) create a specific timing challenge: if you patch a running EC2 instance that's part of an ASG, and that instance is later terminated and replaced by the ASG, the replacement will launch from the original AMI — unpatched. The correct patching strategy for ASG-managed instances is to patch the launch template, not the running instances. Update the AMI reference in the ASG launch template, then cycle the instances by terminating the old ones and letting the ASG replace them with instances launched from the patched template.
This is a workflow that most traditional patch management tools don't support, because they were designed for static infrastructure. They find the running instance, connect to it, run the package update, and mark the asset patched. Three days later when the ASG replaces that instance, the new one is unpatched again — and the scanner will rediscover the finding, creating a recurring cycle of patching that never actually closes the vulnerability at the source.
PatchGuard's AWS integration detects when a finding is on an ASG-managed instance and routes the patch action through launch template update rather than in-place patching. The fix is applied once at the infrastructure level and propagates to all current and future instances in the group. The same logic applies to ECS task definitions, EKS node groups, and other managed compute resources that don't benefit from in-place patching.
Container Images as a Separate Inventory Problem
Container images are a distinct inventory category from the hosts that run them. An EC2 instance running a Docker container has two separate vulnerability surfaces: the host OS (patched through node-level patching) and the container image (patched by rebuilding the image with an updated base). These two surfaces are tracked separately and remediated by different processes — yet most scanner output conflates them, showing both as findings on "the EC2 instance."
Maintaining a container image inventory means knowing: which images are currently running in your environment, which registry and tag each running container is sourced from, and when each image was last rebuilt. In practice, this requires querying the Kubernetes API or ECS API for running task/pod definitions and cross-referencing the image digest against your container registry. The image digest is critical — a tag like "myapp:latest" can point to different image content over time. Only the digest is stable.
Organizations that patch container base images without tracking which applications use them often discover they've patched the image but not redeployed the application — the running containers still use the old image because the deployment wasn't triggered. An inventory system that tracks the relationship between image version, running container, and last deployment timestamp catches this pattern.
Shadow IT and Unmanaged Assets
Shadow IT is the inventory problem that has no clean technical solution. A developer who spins up an EC2 instance in a personal AWS account to run a test database, then forgets about it, is creating an unmanaged asset outside any IAM role or tagging policy. A business unit that deploys a vendor-managed SaaS application without involving IT has added a data-processing asset to the organization's attack surface without adding it to any inventory system.
The technical mitigations for shadow cloud IT start with restricting who can create cloud resources through IAM Service Control Policies (SCPs) in AWS Organizations or Azure Policy. If only approved accounts with centrally-managed roles can launch EC2 instances or create Azure VMs, the unauthorized-launch problem is contained at the organizational level. For SaaS shadow IT, browser-based CASB (Cloud Access Security Broker) tools can detect unapproved SaaS usage from network traffic patterns, though this requires routing traffic through the CASB proxy.
Neither approach eliminates shadow IT completely. The realistic goal is reduction and detection: minimize new unauthorized assets through policy controls, detect those that exist through asset discovery scanning, and remediate them through a defined process (shutdown, bring under management, or document as accepted risk). The inventory is never perfect — the practical question is how quickly you detect gaps and how systematically you close them.
On-Premises Inventory in a Cloud-Native World
Most organizations managing hybrid environments have a larger on-premises footprint than they'd prefer to admit. Legacy applications with long migration timelines, manufacturing OT systems that can't be cloud-hosted, data residency requirements that prevent some workloads from leaving specific facilities — these aren't going away on any near-term roadmap. The on-prem inventory problem is solvable but requires different tooling than cloud-native inventory.
For on-prem infrastructure, network-based discovery (nmap sweeps, SNMP polling, Nessus credentialed scans) combined with agent-based inventory (Qualys agent, Tenable agent, or PatchGuard's lightweight SSH-based scanner) provides the most complete view. The challenge is coverage — maintaining accurate network range definitions for all subnets, ensuring discovery scans reach isolated VLANs and air-gapped segments, and reconciling the discovered asset list against what IT operations believes should be in each segment.
PatchGuard's on-prem connector uses agentless SSH-based discovery for Linux hosts and WinRM for Windows Server, with an optional lightweight agent for hosts in isolated networks that don't permit inbound SSH from the scanner. The connector maintains a persistent connection through a tunnel rather than requiring inbound firewall rules, which resolves the most common blocking issue for on-prem scanner deployment in environments with restrictive network security policies.
Building Inventory You Can Actually Act On
A complete inventory is only valuable if it's actionable. The critical attributes for patch management are: the asset's current installed packages and versions (to match against CVE findings), the asset's business criticality (to weight remediation priority), the asset's network exposure (to assess impact of exploitation), the owning team (to route remediation actions), and the asset's relationship to other assets in the stack (to sequence dependent patches correctly).
Most organizations have some of this data somewhere — in AWS tags, in ServiceNow CMDB records, in Confluence documentation — but it's fragmented across systems with no unified view. The inventory consolidation problem is as much a data normalization problem as a discovery problem. When PatchGuard connects to a new environment, the initial setup process maps the existing tag schemes, CMDB field names, and team ownership models to PatchGuard's internal asset model, producing a unified inventory with consistent criticality and ownership data regardless of where the asset lives.
The test of a good inventory system is simple: can you answer "which assets are affected by this CVE, who owns them, and when were they last scanned" in under 30 seconds? If the answer requires querying three different systems and reconciling the results manually, your inventory isn't serving your patch program — it's adding friction to it.