Software bill of materials (SBOM)

The offline installation tarball ships a software bill of materials in CycloneDX 1.6 JSON format, for license review and vulnerability tracking. The online .deb package doesn't include an SBOM.

Where to find it

The SBOM files are in the sbom/ directory at the root of the tarball. After you extract the tarball, they're in /opt/netfoundry/self-hosted/sbom/:

File	Covers
container-images.cdx.json	Every container image in the bundle, and the OS and application packages inside each image
packages.cdx.json	Everything else in the bundle: Debian packages, Helm charts, and standalone binaries such as K3s, kubectl, and Helm

Document structure

• Root component: metadata.component is the NetFoundry Self-Hosted release (netfoundry-self-hosted) at the bundle's version, with NetFoundry Inc. as the supplier.
• Dependency graph: in container-images.cdx.json, each image is a container component that lists its packages under dependsOn, and the release lists every image. In packages.cdx.json, the release lists its packages directly.
• Licenses: license values are SPDX identifiers or SPDX expressions where one can be determined. Ambiguous strings, such as a bare GPL or BSD, are kept as license.name rather than guessed.
• No file entries: components are software packages only. Individual files aren't listed.

License coverage

License data for Go, npm, Maven, and PyPI components is looked up from deps.dev when the bundle is built, because the compiled metadata in the images doesn't carry it. With that lookup, roughly 90% of components carry a license. A bundle built without it (a build host with no internet access) covers far fewer. A component with no licenses field had no license information available when the bundle was built. It doesn't mean the component is unlicensed.