December 2023 saw the launch of SBOMit, a project that helps enhance the reliability and integrity of SBOMs (Software Bills of Materials). It does so by including, along with SBOMs, a series of in-toto attestations that are produced while the software is being created. SBOMit is hosted under the OpenSSF Security Tooling Working Group.
But why are these attestations important for SBOMs and how do they work? This blog post explores these topics through a deep dive into SBOMit and attestations.
SBOMs and Attestations
SBOMs (Software Bills of Materials) are used to provide a list of components that make up a software package, just like nutritional information labels on food and beverages. While SBOMs can be stored using various formats, and the SBOMs themselves can be signed to ensure they can’t be tampered with, SBOMs still often suffer from inaccuracy. This is because of the creation process: a single SBOM may not completely track all components that went into the creation of a particular piece of software.
To use the nutrition label analogy, the challenge is similar to ensuring that what’s listed on “Nutrition Facts” doesn’t leave out any hidden ingredients or misstate what is in your food or beverage. The only way to have certainty over what’s in your food is to monitor the food processing and manufacturing process.This is what SBOMit does: only for the software production process..
Put simply, the SBOMit specification is a method for attesting components that make up an SBOM, and these attestations are generated at the time the supply chain was generated. This verification information uses in-toto attestations, which can be validated by another party to give a high degree of assurance about the software and that the generated SBOM is accurate.
What would these in-toto attestations look like? They can cover various parts of the software supply chain, ranging from which version control system was used, the process of building or unit testing, or license compliance checks. In-toto attestations are also authenticated by the project owner’s signature as well as private keys for other entities that perform the attestations.
For instance, to validate the compilation step for software used in an SBOM, an in-toto attestation may include the secure hashes of files in a version control system used for compilation; the secure hashes of compiled files; and a signature endorsed by the compiler’s private key.
The SBOMit Specification
The SBOMit specification further explains how these in-toto attestations can be used to construct an SBOMit document. To do so, SBOMit documents contain Software Inventory Templates (SITs). An SIT is an SBOM that is additionally signed by a key that indicates which actor in the software production process generated it.
At its core, an SBOMit document contains (1) an in-toto layout, which specifies details about keys for each SIT and the SIT generation process and (2) in-toto metadata, which contains additional details and attestations about the document, such as sub-layouts. A document can also include SBOM mutations, which include additional SBOM information beyond what can be strictly verified; and addendums, which represent changes to the previous document sections to preserve historical information about the document.
Once an SBOMit document is produced, clients can perform extensive verification of the document in order to get a high degree of assurance about the software’s integrity. For example, a client could verify that the steps described in the document indeed took place; ensure the identity of who performed a particular step by inspecting link metadata; or ensure that all the steps indeed led to the final SBOM described by the SBOMit document.
Future Roadmap
SBOMit is still in its early stages, and the SBOMit Roadmap describes goals for the future. In the near term, the team plans to establish a diverse community of various stakeholders to help drive the specification forward and develop tooling to implement the SBOMit specification; focus on widespread end user adoption by collaborating with partners across various sectors and with regulatory bodies; and, finally, developing and enhancing a clear SBOMit specification that is secure and easy to use and integrate.
The SBOMit Specification is available on GitHub and the team invites contributions or feedback to strengthen it! We encourage you to get involved, whether by opening an issue or joining the weekly meetings. Your participation can help us make SBOMs more trusted, and software more secure, for everyone!