TL;DR: SBOM programmes focused only on containers still miss legacy applications, regulated workloads and long-lived virtual servers, according to Anchore's analysis, leaving teams to answer vulnerability questions manually for much of their estate. A unified inventory that treats filesystem analysis and container images as equivalent assets is now a governance requirement, not a convenience.
At a glance
What this is: Anchore argues that container-only SBOM programmes leave a major visibility gap because virtual machines, legacy systems and other non-container assets often never enter the inventory.
Why it matters: IAM, NHI and security teams should read this as an inventory governance problem: if you cannot query every software asset quickly, you cannot govern vulnerability exposure or accountability consistently.
By the numbers:
- Nearly 85% of all containers will still be running inside VMs through 2028, according to Anchore.
Context
SBOM coverage is only useful when it reflects the actual software estate, not just the easiest part to scan. In mixed environments, container images, virtual machines, legacy applications and regulated systems can all carry the same vulnerability exposure while sitting in different inventory workflows.
The governance gap here is visibility, not packaging format. If the inventory model only covers containers, teams end up with fast answers for one slice of infrastructure and manual checks for the rest, which weakens vulnerability response, auditability and operational resilience across the broader estate.
Key questions
Q: Where does container-only SBOM coverage fail in practice?
A: It fails wherever the estate includes VMs, legacy applications or regulated workloads that do not appear in the container registry. In those environments, vulnerability scoping becomes manual, inconsistent and slow. The control failure is not SBOM generation itself, but incomplete asset coverage across the software estate.
Q: Why does incomplete endpoint inventory increase vulnerability management risk?
A: Because vulnerability findings only become actionable when they can be tied to a governed endpoint and then to the software installed there. If the asset is unmanaged or misidentified, the finding may be visible but still unremediable. That creates blind spots in prioritisation and weakens confidence in patch reporting.
Q: What are the signs that an SBOM programme is failing in practice?
A: An SBOM programme is failing when the inventory is stale, incomplete, or never queried against current risk. Skipping transitive dependencies hides real exposure, and generating SBOMs only once per project leaves them out of date as builds change. If the team cannot answer are we affected after a new CVE lands, the SBOM is not functioning as an operational control.
Q: Should organisations use one inventory for containers and virtual machines?
A: Yes, if they want consistent vulnerability response and defensible governance. Separate processes create uneven visibility, different scoping speeds and fragmented accountability. A unified inventory is the better operating model when the same software release can span images, filesystems and imported SBOMs.
Technical breakdown
Why container-only SBOMs miss mixed infrastructure
Container SBOM workflows matured first because images are immutable, layered and easy to source from a registry. Virtual machines and bare servers are different: there is no registry, the filesystem may be live, and assets often exist outside the software delivery path. That makes inventory completeness the core problem, not SBOM syntax. If the discovery model does not cover filesystems and disk images, it cannot produce a reliable picture of what is actually running.
Practical implication: Extend SBOM collection beyond images so legacy hosts and VMs enter the same inventory workflow as containers.
Filesystem analysis versus image-based analysis
A filesystem scan treats the operating system state on a VM as a first-class software asset, rather than assuming only containers matter. That matters because the dependency graph, installed packages and author attribution can be captured from the real runtime state instead of a packaged artefact alone. When teams generate SBOMs from mounted disks or live filesystems, they close the gap between what is deployed and what is visible to security tooling.
Practical implication: Use filesystem-based SBOM generation for VMs and golden images so runtime software does not stay outside the inventory.
Why SBOM format and metadata determine queryability
An SBOM is only operationally useful if it carries stable component identifiers, dependency relationships, authorship and timestamps. Without those fields, vulnerability triage becomes a manual matching exercise at the exact moment speed matters most. Standard formats such as CycloneDX and SPDX help, but the governance point is more important: the inventory must be structured enough to answer release-level questions across every asset type.
Practical implication: Validate that every SBOM includes enough metadata to support fast queries during incident response and vulnerability disclosure.
Threat narrative
Attacker objective: Exploit inventory blind spots so vulnerable systems remain unpatched or untriaged long enough to be abused.
- Entry occurs through the visibility gap itself, where virtual machines and legacy systems never make it into the SBOM inventory even though they remain in production.
- Escalation follows when a new CVE lands and teams can only answer exposure questions quickly for containers, forcing manual checks for everything else.
- Impact is delayed remediation, weaker auditability and slower vulnerability response across the oldest part of the estate.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Container-only SBOM programmes create inventory debt, not inventory maturity. A tool that sees only images gives teams a false sense of completeness while leaving VMs, legacy applications and regulated systems outside the governance boundary. The real problem is not format support but whether the organisation can produce a single answer for every software asset it runs. Practitioners should treat mixed estate visibility as a control objective, not an implementation detail.
The governance gap is release-level visibility across heterogeneous assets. Security teams often optimise for container workflows because they are easier to automate, then discover that the older half of the estate still needs manual correlation under pressure. That breaks vulnerability management and incident response at the same point every time: when a newly disclosed issue needs fast, defensible scoping. Practitioners should align inventory design with the actual deployment model, not the preferred one.
Filesystem-based SBOMs are a practical bridge between infrastructure reality and security process. They let teams inspect what is actually installed on a VM or disk image without booting or modifying the workload, which is materially different from container-only scanning. That matters in regulated, air-gapped and long-lived environments where the system of record is the running filesystem, not the image registry. Practitioners should make filesystem scanning part of the normal control set for mixed estates.
One inventory model must serve compliance, operations and response. The article’s deeper lesson is that the same control data should support vulnerability triage, audit evidence and release governance across both containers and virtual machines. If each estate has a different process, response speed becomes inconsistent by design. Practitioners should standardise on one queryable inventory for all deployment types rather than keeping parallel tracking systems.
Visibility gaps behave like a supply chain weakness once patch pressure rises. If a release cannot be queried quickly across every asset type, then the organisation cannot prove what is affected when a new issue emerges. That is especially relevant where infrastructure mixes modern containers with long-lived VMs, because the slower path becomes the attack surface. Practitioners should link inventory completeness to vulnerability SLA performance and operational accountability.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Inventory completeness is the real control variable in mixed estates. The practical problem is not whether teams can generate an SBOM for a container image, but whether the same release can be queried across VMs, legacy servers and imported third-party artefacts. That is where response speed, auditability and ownership either hold together or fall apart.
SBOM coverage now needs to follow the estate, not the preferred deployment model. As long as VMs and containers coexist, security programmes that treat only one of them as first-class will keep producing partial answers under pressure. The operational test is simple: can you scope a newly disclosed package across every asset type in one request?
For practitioners
- Extend SBOM collection to VM filesystems Treat virtual machine filesystems as first-class SBOM sources so legacy hosts and regulated workloads appear in the same inventory as containers.
- Scan mounted disk images read-only Use read-only mounting for disk images and generate SBOMs from the mounted filesystem so you can inspect offline or forensic images safely.
- Standardise app and version grouping Group container images, filesystem assets and external SBOM imports under one application version so exposure queries span the whole release.
- Require complete SBOM metadata Verify supplier, component name, version, unique identifiers, dependency relationships, author and timestamp before accepting an SBOM into inventory.
- Use one query path for vulnerability triage Make release scoping a single request across containers and VMs so newly disclosed vulnerabilities can be answered in minutes rather than by manual server checks.
Key takeaways
- Container-only SBOM programmes leave major gaps whenever production systems still live on virtual machines or legacy servers.
- The article’s key point is that a mixed estate needs one queryable inventory, not separate workflows for modern and older infrastructure.
- Practitioners should treat filesystem-based SBOM generation, complete metadata and unified release scoping as baseline governance controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0, SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-2 — Software Inventory | The article is fundamentally about incomplete software inventory across containers and VMs. |
| Recommendation — Inventory every VM, container image and imported SBOM under one governed software asset register. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | Unified asset visibility is the core control problem described in the article. |
| Recommendation — Extend asset inventory to include virtual machines and filesystem-based software evidence. | ||
| SLSA | L3 — Build Integrity | The article discusses SBOM provenance and software supply-chain evidence across deployment artefacts. |
| Recommendation — Tie SBOM generation to build provenance so release evidence stays queryable across asset types. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | The control directly addresses the need to know what components exist across the environment. |
| Recommendation — Apply CM-8 to keep VM and container components in one auditable inventory. | ||
Key terms
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- Filesystem-based SBOM: A filesystem-based SBOM is generated by inspecting the installed software and dependencies on a live or mounted filesystem rather than only on a container image. It is essential when virtual machines, disk images or legacy hosts contain production software that never passes through a registry.
- Inventory coverage gap: An inventory coverage gap is the difference between the assets an organisation believes it can see and the assets actually running in production. In security programmes, this gap turns routine vulnerability management into manual triage and weakens accountability during incidents.
- Repository Scoping: Repository scoping is the process of deciding which source code repositories are included in a security control or scan. It gives teams a way to limit coverage to the right assets, reduce noise, and make sure new repositories are governed according to policy rather than added by accident.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management for practitioners building stronger access and inventory controls. It is useful for security teams that need a clearer operating model for identity-linked systems and broader governance.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org