About SBOMit

What is SBOMit?

SBOMit is an open source tool that generates Enriched SBOMs by combining standard SBOM tooling with build-time attestations captured by Witness, a supply chain security framework built on the in-toto specification.

Where traditional SBOM tools scan software after the fact and guess at its composition, SBOMit observes the build as it happens — recording exactly what was downloaded, compiled, and linked — then uses that data to produce a complete, verifiable software component inventory.

The Problem: SBOMs Are Incomplete by Design

Most SBOMs are generated either before the build (from manifest/lockfiles) or after (by scanning the output artifact). Both approaches have fundamental blind spots:

Generated from manifests:

• Lockfiles are often stale and don’t reflect what was actually installed
• Version pinning in manifests may not match what the package resolver chose
• Transitive dependencies may be missing or wrong

Generated by post-build scanning:

• Scanning tools use heuristics to infer what happened — they are imperfect by design
• Native libraries and dynamically loaded files (.so, .dylib) are frequently missed
• Files unknown to the package manager are invisible to scanners
• Different scanners give wildly different results for the same artifact

Both approaches share a deeper problem: SBOMs generated outside the build process can be forged or tampered with after the fact, and they carry no cryptographic proof of how the software was actually produced.

Research: Dark Matter in Docker Hub Images

We analyzed the top 1,000 Debian-based images on Docker Hub. A significant percentage of files in many of those images are not attributable to any package manager — what we call “dark matter” files. Some images had 40–100% of their files unaccounted for.

This research surfaced real CVEs:

• CVE-2025-32754 (jenkins/ssh-agent) — SSH keys are generated at image build time, so all containers derived from the image share the same keys. An attacker can connect to a build container, read the build secret, and leave without a trace.
• CVE-2025-32111 (acme.sh) — a build secret was leaked during the build process. An attacker with this secret could replace a popular Let’s Encrypt client and perform man-in-the-middle attacks on a large portion of internet traffic.

Traditional SBOM tools miss these because the files and their origins are invisible at scan time. SBOMit captures them during the build, where they are observable.

How SBOMit Works

SBOMit is built on two components:

1. Witness — Build-Time Attestation

Witness wraps your build process and instruments each step, recording cryptographic attestations that answer:

• Who ran the step: process names, commands, environment
• What was accessed: every file read and written, packages downloaded, network calls made
• How inputs became outputs: SHA-256 hashes of all artifacts at each stage

Each build step produces a signed attestation collection in the in-toto ITE-6 format, covering attestation types including:

2. SBOMit — Enriched SBOM Generation

The sbomit tool reads Witness attestation files and:

1. Parses all attestation types to build a complete picture of the build
2. Runs language-specific package resolvers to map file paths back to package names and versions
3. Filters cache artifacts and de-duplicates package references
4. Emits a standard SBOM enriched with accurate, build-observed data

Install and run:

go install github.com/sbomit/sbomit@latest
sbomit generate <attestation-file> [flags]

What Enriched SBOMs Provide

Compared to a traditional SBOM generated by a tool like Syft alone:

Key benefits

• Accurate versions — captures what the package resolver actually installed, not what the lockfile says. Stale lockfiles are a common source of false positives and false negatives in vulnerability scanning. Example: a lockfile may pin urllib3==1.54.0 but the resolver installs 1.57.0 — SBOMit reports what was actually installed.
• File-to-package mapping — works across package managers, making SBOMit package-manager agnostic. You don’t need to maintain individualized SBOM pipelines for Android, Python, internal packages, etc.
• Native library detection — catches .so / .dylib files loaded at build time that scanners miss. For C/C++ projects where libraries may be vendored forks of forks, having file hashes makes it possible to detect if you are using a malicious version of e.g. libssl.
• Network provenance — records outbound connections during the build (src, dst, protocol). Helps detect dependency confusion attacks and unauthorized package registries. Also provides context behind each action taken during the build.
• Removes false positives — if a package appears in a lockfile but is not actually installed or used during the build, SBOMit will not report it.
• Adds false negatives — packages resolved at build time that are absent from the lockfile (transitive dependencies, dynamically pulled libraries) are captured and reported.
• Tamper-evident — all attestations are cryptographically signed; the chain of custody is verifiable from source to SBOM.
• Zero Trust alignment — supports SLSA principles and can be integrated into policy enforcement pipelines.

Supported Languages and Output Formats

Language-specific resolvers:

• Python (pip)
• Go (modules)
• Rust (cargo)
• JavaScript / pnpm

SBOM output formats:

• SPDX 2.2 and 2.3
• CycloneDX 1.4 and 1.5

Relationship to in-toto and Witness

SBOMit sits at the intersection of two established standards:

• in-toto — a framework for securing the software supply chain through signed attestations and verifiable policies (CNCF project)
• Witness — an in-toto implementation that instruments builds and produces ITE-6 attestations; donated to the CNCF in-toto ecosystem by TestifySec

SBOMit does not replace these — it consumes their output to generate compliance-ready SBOMs.

Project Status and Contributing

SBOMit is an early-stage but functional open source project under the Linux Foundation / OpenSSF umbrella, governed by a Technical Steering Committee.

Repositories:

• SBOMit/sbomit — the enrichment tool
• in-toto/witness — the attestation framework

Contributions, language resolver additions, and SBOM tool integrations are welcome. See the open issues for areas where help is most needed, including:

• Additional language/build tooling resolvers
• Guidance from the SBOM specification community on standardizing attestation-backed SBOMs
• Integration with SBOM tools to natively consume attestations