Automated SBOM Generation with Paketo Buildpacks
Generating a software bill of materials (SBOM) is gaining a lot of traction in the software development community. This is a result of the increasing sensitivity of the community to one of the downsides of architecting solutions with external dependencies. Even more so because of the inclusion of vulnerable open source dependencies. This weakness, known as software supply chain vulnerability, is an area of active research and response in the security community.
What Are SBOMs and Where Did They Come from?
Software development has had a tremendous amount of evolution. One of the key transformative characteristics is the use of extensions and external modules to complete a single component, defined by the popular term software reuse. Even greenfield projects today are a mix of external libraries and third-party components. Heuristically, a significant portion of these tend to be open source ones.
Additionally, software development happens in numerous iterations where it becomes quite impossible to keep track of “who sourced what component to use in which module.” This approach of creating large integrated code bases reduces transparency and limits the ability to identify risk greatly.
A means to communicate openly which components go into building a piece of software lies at the core of SBOMs. It borrows heavily from the hardware industry and extends the analogy well from software supply chains. If the software being built is assembled from components and their derivatives, it is only natural to want to maintain an auditable list of the items that went into building it. Transparency, vulnerability management and reduced risk are some of the immediate benefits from creating and maintaining SBOMs for your software projects.
Increasingly important is the application of these principles to container images. By nature, containers are not easy to examine or simple in their construction. Container images are made up of different layers, and each layer comes with its own set of dependencies.
What Do SBOMs Look Like?
It is possible to add metadata to these container images when they are created. Populating information into these metadata fields using the information generated during the build process is the fundamental principle behind generating SBOMs. It takes the form of flat files that can be queried, organized and used during audits.
Buildpacks have four typical stages in their life cycle. These are Detect, Analyze, Build and Export. It is the fourth stage that creates the final image including the bill of materials, but that happens with metadata collected and written to the file in the build stage. All the dependencies are read from a TOML file and used during the build process. The corresponding environment variables are used to generate the SBOM.
A snippet of the bin/build.sh script (from the Ruby buildpack) used during the build process:
|
1 2 3 4 5 6 7 |
# Adding the Bill of Materials cat >> "$layersdir/launch.toml" <<EOL [[bom]] name = "ruby" [bom.metadata] version = "$ruby_version" EOL |
The resulting SBOM would look like this:
|
1 2 3 4 5 6 |
{ "name": "ruby", "metadata": { "version": "2.5.0" } } |
Ensuring Standards Are Met
https://xkcd.com/927
It is a known fact that an open means for creating SBOMs like the one outlined above can result in a large number of competing formats. They will be generated depending on the convenience of each community that consumes the information in the bill of materials. Two open and fairly congruent standards are available for SBOMs. The common denominator for both of these is the classification as a Data Exchange format.
The first one is the CycloneDX format. It is designed for use in application security and the analysis of software supply chain components. The current version used is CycloneDX 1.3. CycloneDX is a vendor-neutral open source project that aims to provide a specification and corresponding implementation for a bill of materials format. The CycloneDX project reports adoption across thousands of organizations spanning several verticals.
The second common format is the SPDX. It stands for Software Package Data Exchange. It is also an open standard and is defined as one that focuses on BOM information that comprises licenses, copyright and security in addition to the software libraries in use. The Linux Foundation manages the SPDX specification and is now published as the ISO/IEC 5962:2021 standard.
How to Generate SBOMs Using Paketo
Here’s a link to a list that illustrates the SBOM created when using the Paketo Java Buildpack. Now, here are the steps that you should take to get them for your applications. In the tutorial that follows, we will use two tools:
-
The Pack CLI
This is a command-line tool that is maintained by the Buildpacks team. It is required in order to build the container image. Its use also extends to support other functionality, such as rebasing, inspecting, etc. Install using these instructions.
-
Paketo Buildpacks
Paketo is an implementation of the open Cloud Native Buildpacks standard. The Paketo project takes the CNB specification and provides production-ready buildpacks that can be used to build container images for applications written in a variety of languages/frameworks. There is no installation required. They will be pulled from a container registry as required.
Here’s a sample codebase from GitHub you can use for this tutorial. You’re encouraged to run this against your own application source code to take full advantage of the process.
|
1 2 |
git clone https://github.com/paketo-buildpacks/samples cd samples |
For the example Java application, here’s a command to run:
|
1 |
pack build java-foo java/maven --buildpack paketo-buildpacks/java |
The resulting image will be named java-foo, and you can inspect the image to see the full bill of materials generated automatically when using Paketo Buildpacks. Here’s the command to run:
|
1 |
pack inspect-image java-foo --bom | jq '.' |
This will show you a complete software bill of materials that is generated. The important takeaway here is that no additional effort is required to create these bills of materials when using Paketo Buildpacks. The implementation of the standard provides a means to gain this functionality at zero cost.
Irrespective of which format you choose, software bill of materials is vital to improving the security posture of any organization. It is an important step in the direction of more secure software.
