Sanchit Sahay

Earlier this month, I had the opportunity to present a talk at the SBOMit meeting taking place at KubeCon + CNCF in Atlanta.

For the uninitiated, SBOMit is a an Open Source Security Foundation project that aims to improve the information that an SBOM (Software Bill of Materials) contains, through the use of in-toto attestations.

Briefly motivating the problem, SBOMs are often used as a provenance tool meant to include information about the packages that were either directly or indirectly used when building a software package.

However, most of these tools fall short in several ways. For one, they usually rely only on manifest files and output artifacts to detect these ingredients. These are often unreliable because something as simple as a stale lockfile or ambiguous requirements can lead to inaccurate versions being attached to your SBOM. This runs into even more complicated issues if you are using a multi-language environment such as maturin, where it's possible that the SBOM completely ignores packages that aren't directly listed in a manifest.

These tools often also need to be tailor-built for individual environments. For e.g. you'd need separate codepaths for detecting a Cargo.toml and requirements.txt file.

Moreover, since these tools are meant to be used as a provenance tool, it is imperative that these be independently verifiable and be susceptible to tampering. While this is achievable using existing tools, they're often not a first-class feature.

SBOMit tries to fix some of these problems through the use of in-toto through attestations that provide a more granular detail of the packages and files that were used during the build stage, and can make it easier to detect untoward behavior through the use of policies and layouts.

Instead of relying solely on manifests, we observe the build process as well.

SBOMit isn't meant to be a SBOM generation tool, but rather it is an effort to augment existing SBOM tools with the additional information and security that in-toto provides.

For our presentation, we demoed our tool which was a modified version of syft that took as an additional the attestations generated through witness.

We also further added support for network attestations to witness making it possible to record information about where the packages were pulled from, and if the build process made suspicious network calls. This helps in cases where typosquatting or dependency confusion is a viable vector of attack.

Check out our presentation here!