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.
What a filesystem-based SBOM actually describes
A filesystem-based SBOM describes what is present on a running or mounted system, not just what was declared at build time. That distinction matters because the authoritative inventory is the installed filesystem state, including software added after image creation, drift from the original build, and packages that never appeared in a registry.
This approach is especially useful for virtual machines, golden images, disk snapshots, forensic mounts and older hosts where the live software set is the real production environment. It can therefore reveal components that image-only discovery would miss, which is why filesystem inspection is often treated as a practical complement to image-based and package-manifest SBOM generation.
Why filesystem inspection changes the SBOM result
Image-based SBOMs tell you what was intended for delivery, while filesystem-based SBOMs tell you what is actually installed. That difference becomes material when images are patched after deployment, when local administrators add software, or when legacy systems are restored from disks and backups rather than from modern container registries.
Filesystem-based generation also helps when software is fragmented across package managers, copied binaries, scripts, libraries and vendor directories. A mature inventory process should expect that not every dependency will be visible in one manifest, so filesystem inspection improves coverage by walking the actual files and correlating them with package metadata, hashes and known component databases.
Where filesystem-based SBOMs are most useful
The strongest use cases are environments with weak or absent build provenance, including unmanaged servers, virtual machines, long-lived appliances, bare-metal hosts and offline images. In those settings, the filesystem is often the only dependable source for understanding what is deployed.
Filesystem-based SBOMs are also useful for incident response and software assurance work. They let teams compare the installed state against expected baselines, vendor advisories and vulnerability data, which helps identify unexpected components, orphaned libraries and stale dependencies that may not appear in source repositories or container manifests.
For broader SBOM practice, the filesystem approach fits naturally alongside the SBOM Guide, especially when readers need to understand how SBOMs are generated, consumed and correlated with vulnerability data.
What a good filesystem-based SBOM should capture
A useful filesystem-based SBOM should do more than list package names. It should preserve enough component detail to support matching, deduplication and later risk analysis, including versions where available, file paths, component relationships and evidence that ties a discovered file to a known software package.
Quality also depends on how well the generator handles ambiguity. Multiple files may belong to the same component, some software may be statically linked, and some files may be vendor bundles or manually copied artifacts. If those cases are not handled carefully, the SBOM can overcount components, miss hidden dependencies or attach the wrong identity to a binary.
Filesystem discovery is therefore a content-extraction problem as much as a supply-chain problem. The better the scanner can recognise packages, artifacts and embedded dependencies, the more reliable the SBOM will be for downstream vulnerability correlation and compliance reporting.
How filesystem-based SBOMs fit into supply-chain security
Filesystem-based SBOMs close a common gap in software supply-chain visibility, which is why they pair naturally with open source assurance workflows. They help answer not only what was built, but what actually reached an operational host after installation, updates and manual change.
That makes them a useful control for environments that need to reconcile production reality with delivery records. They also support better vulnerability triage because teams can compare installed components against advisory data, de-duplicate inherited dependencies and identify components that were never captured in the original release artifact. For a broader view of open source assurance and dependency risk, the Open Source Security Guide provides the surrounding context for SCA, SBOMs and dependency management.
When the installed state is the thing that matters, filesystem-based SBOMs provide the most honest inventory of the environment. They are not a replacement for build-time SBOMs, but they are often the one that best reflects operational risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, CIS Controls v8, NIST SP 800-53 Rev 5, OWASP ASVS and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Filesystem SBOMs support artifact provenance and installed-state verification in software supply chains. |
| Recommendation — Use provenance checks to reconcile installed filesystem components with trusted build and delivery records. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Filesystem SBOMs strengthen software inventory and vulnerability visibility for deployed software assets. |
| Recommendation — Inventory deployed software continuously so filesystem-discovered components feed your vulnerability and asset management. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | A filesystem-based SBOM is a component inventory method for installed software on live or mounted systems. |
| Recommendation — Maintain an accurate component inventory by reconciling filesystem-discovered software with authoritative asset records. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Filesystem-based SBOMs improve dependency visibility needed for secure architecture and software assurance. |
| Recommendation — Track dependencies at runtime and installation time so architectural review uses the actual deployed software set. | ||
| OWASP SAMM | Software Assurance Maturity Model | SBOM generation is a software assurance practice that matures dependency visibility across delivery and operations. |
| Recommendation — Build SBOM generation into your delivery process so deployed software can be verified against known dependencies. | ||
Related resources from NHI Mgmt Group
- Guide: AI Supply Chain Security and AI-BOM Guide
- How do teams know if SBOM-based prioritisation is working?
- What fails when embedded products lack SBOM-based visibility?
- Why do CI-based SBOM workflows break down in large repositories?
- Why do Git based applications create unusual attack paths when they mix repository metadata with the underlying filesystem?