Filesystem-based SBOM

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.

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?