Topic starter
24/10/2026 8:48 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Anchore: “What your SBOM inventory misses if it only covers containers”.
By the numbers:
- Nearly 85% of all containers will still be running inside VMs through 2028, according to Anchore.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Container-only SBOM programmes leave major gaps whenever production systems still live on virtual machines or legacy servers.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/10/2026 11:13 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SBOM inventory gaps persist when programs ignore virtual machines