Modern software packages are more secure than they have ever been, thanks to advancements in cybersecurity practices. However, they also face the most advanced threats, making them just as vulnerable as they’re secure. Supply chain attacks like Solarwinds and severe vulnerabilities like Log4Shell are among the latest threats faced by software systems today. Software supply chain attacks like these are dynamic in their effect and more difficult to navigate because they exploit vulnerabilities in systems that are beyond your direct control.
However, the first step in combating software supply chain attacks like these is to have clear knowledge of the packages, dependencies, and components included in your software. This is why generating a Software Bill of Material (SBOM) for your build is important. It not only enhances the visibility of vulnerabilities in the software supply chain—an SBOM has also become important for compliance purposes. SBOM generation has been mandated by a recent executive order issued by the U.S. federal government to enhance cybersecurity and guarantee the authenticity of third-party components used in software packages.
According to a Gartner prediction, 60% of organizations that are in charge of developing critical infrastructure software will require standardized SBOMs by 2025. Creating an SBOM begins with selecting a tool that aligns with your organization’s standards and goals, determining the phases of the software build lifecycle during which to apply the SBOM, confirming that it adheres to the format, and performing a vulnerability scan. Generating an SBOM is a delicate and complicated process. This article will cover when SBOM generation is necessary and how to generate it for your software.
When to Generate a Software Bill of Materials
Generating a Software Bill of Materials (SBOM) is essential in securing your software builds as well as your entire software supply chain. SBOM generation can be integrated into various stages of the build process for your software. You can generate a Bill of Materials using the source code during build time, during runtime, or while doing forensics on the software. Of all these, experts recommend generating an SBOM during the build time. That’s because build-time SBOM generators are more accurate and generate a more complete list of dependencies. However, since this is not always practical, the SBOM can be generated at any other time during the DevOps lifecycle.
It is worth noting that the type of SBOM generation tool to use depends on what stage in the DevOps lifecycle the SBOM documentation is being generated. The following are the different stages at which SBOMs can be generated during the build lifecycle. Each period has different advantages and trade-offs. It’s best to understand the target audience and use case for the SBOM data you’re generating and choose an approach that delivers the best result for you.
At the source code stage
By examining the artifacts and any associated sources such as manifests, metadata, and lock files, source or binary tools will generate a Software Bill of Materials at the source code stage. At this stage, you can either do a software component analysis or a binary analysis of your software.
An SCA (software component analysis) tool is designed to analyze a piece of software and its manifest files to determine its components. Binary analysis tools, on the other hand, analyze the software metadata and build artifact information to generate an SBOM. Examples of analysis tools used at this stage include CycloneDX, It-Depends, Fossa, AppSonar, Cybellum, Black Duck, and Fortress.
You can use a vulnerability analyzer together with an SBOM generated at the source code stage to receive early vulnerability warnings in the software that is being built. However, there are limitations to SBOMs generated at this stage. For one, they’re not complete, as ones generated during build-with-dependency information are often missing. Additionally, they may include information about components that were not used in the final deployed product.
During build-time
Creating the SBOM at build-time with a tool that taps into the build system has the most exact knowledge of what goes into a binary, including transitive and unpinned dependencies. This is supported by the NTIA study on software suppliers’ SBOM production and provision.
The NTIA recommends creating an SBOM for each new component release. This means creating a fresh SBOM each time you update or release a new version of your software Suppliers are also required to create fresh SBOMs whenever they discover a mistake in the previous one or learn new information about their software components that were not previously documented.
Generating your SBOM during Build-time involves using a plugin that works with the native environment you’re building your software with. Most development environments have plugins that integrate with the dependency management system to generate an SBOM automatically. Examples of build-time SBOM generators include SPDX, the CycloneDX Maven plugin, and OWASP’s Dependency-Track-Check.
Although Build-time SBOM generators are the most comprehensive and accurate, they’re more difficult to set up compared to other methods. Also, this method does not work for some build systems, and you cannot use this method for legacy products.
Generating SBOM during runtime
An SBOM generator that works during runtime is designed to capture the libraries that the software, app server, or plugins use during runtime. This type of generator also details all the services called by the software as well as the ports and active libraries it accesses. However, this method of generating SBOMs is not widely available. Also, there’s no clear workflow for merging the data generated using this method with the original SBOM documentation. Jbom and ThreatMapper are examples of runtime SBOM generators.
How to Generate a Software Bill of Materials: A Step-by-Step Guide
Generating a Software Bill of Materials manually is time-consuming and tedious for developers. Listing all the components of a software program this way is mostly impractical. However, numerous SBOM generation tools are now available that simplify this process. How to go about this depends on your organization’s standards and when you want to generate your SBOM during the development lifecycle.
By integrating SBOM workflows into software build pipelines, you can automate the SBOM process. The Scribe platform is one such tool that simplifies how you create your Software Bill of Materials. Scribe allows you to manage and share your SBOM from one place. This way, you can validate the integrity of your software components and track vulnerabilities in the software pipeline seamlessly. This section is a step-by-step guide for generating software bills of materials with Scribe.
Step 1: Register and log in to Scribe Trust Hub.
Before you start, you should know that the Scribe platform has a web interface—Scribe Trust Hub—that is accessible from your browser. The Scribe evidence collector, however, runs only on Linux and Mac devices. To generate an integrity report and SBOM with Scribe, you must have permission to modify your project’s build script and add the relevant code snippet needed to connect your project to Scribe. Bear in mind that while Scribe can generate SBOMs for projects written in any programming language that generates a container image, the current release only works for Node.js projects.
The first step for integrating Scribe into your project is to register on Scribe Trust Hub. Once you have registered and logged in, navigate to the “Products” tab and click on Setup. Scribe has a demo product on this page, which you can interact with to get the hang of the platform and how it works.
Step 2: Integrate Scribe Trust Hub
The next step is to connect Scribe to the Continuous Integration Pipeline of your project. This automates the SBOM generation process. Generally, you can add code snippets from Scribe Trust Hub into two points on your CI pipeline. You can place the code at the source code checkout or the final built image. The first option is recommended but not compulsory, while the second is mandatory.
Scribe’s CI setup currently only works for Jenkins over Kubernetes and GitHub Actions. The process of integrating Scribe for these CI setups is similar. You’ll need to get the following credentials on your Scribe Hub Product setup page to get started:
- Product key
- Client ID
- Client secret
The product key varies from one product to the other, while the client credentials are unique to your account.
Setting up CI integration for Jenkins
To set up CI integrations for Jenkins, you can add the code snippet to call “Gensbom” (Scribe Trust Hubs’ tool for collecting evidence and generating SBOMs) at the checkout point and/or after creating a Docker image.
Start by adding the credentials above to your build environment according to the unique instructions for Jenkins. Next, add the code snippet to your pipeline according to the instructions here.
Setting up CI integration for GitHub Actions
The process of setting up CI integration for GitHub Actions is similar to that of Jenkins. The main idea is to call Scribe’s evidence collector and SBOM generator known as “Gensbom”. To get started, follow the GitHub instructions to add product setup credentials and the code snippet to the pipeline according to the instructions here
Integrating Scribe Trust Hub with Other CI Systems
Although Scribe only offers native support for Jenkins and GitHub actions, you may also be able to use it for other CI systems. To start, download the “Gensbom” tool from your Unix-based command line interface. Next, add your product, and client credentials, then call Scribe gensbom from your build script either at Checkout or after the final built image.
Step 3: Generating the Software Bill of Materials
The gensbom CLI tool by Scribe generates the Software Bill of Materials (SBOM) for Docker and Open Containers Images (OCI). This tool only runs on Mac or Linux systems. The final SBOM generated by Scribe is in CycloneDX JSON format, which is one of the standard machines and human-readable formats recognized for SBOMs. The open container images can be extracted from Docker, a local disc or a remote registry, as the case may be.
Although there are default settings for the name, directory, and path of the image from which the SBOM is generated, it is possible to change these default settings accordingly if you want.
Step 4: Export SBOM
Scribe Trust Hub also allows you to export and share your Software Bill of Materials seamlessly as part of the validation process of your software. The SBOM is generated in CycloneDX JSON reporting format and details all the open-source dependencies of the analyzed Docker image. Once the SBOM has been generated, you can export it with one click. You’ll find the “Export SBOM” button in the top right corner of the report. Click it to export your Software Bills of Materials.
Conclusion
Generating a Software Bill of Materials is becoming an increasingly vital step to securing your software supply chain and for compliance purposes as well. Regardless of your reasons for generating an SBOM, you’ll find Scribe Trust Hub an easy-to-use and flexible way to automate the SBOM generation workflow for each of your software builds.