Step 2: Internal SBOMs

As organizations navigate the complexities of securing their software supply chain, the creation of a Software Bill of Materials (SBOM) for in-house applications and libraries is a critical step. This chapter offers a practical guide for generating your internal SBOMs.

Practical Guide to Generating Your First SBOM

Choose the Right Tool

Numerous tools are available for generating SBOMs, ranging from open-source tools to commercial solutions offering additional features and support. Selecting the right tool depends on your organization's specific needs. We recommend using a tool that is capable of generating SBOM files in either the CycloneDX or SPDX formats.

Navigate to Coverage and Compatibility for more information regarding SBOM Observer compatibility.

Non-exhaustive list of SCA Tools with SBOM Capabilities

Tool NameSource
TrivyTrivy
SyftSyft
Black Duck (by Synopsys)Synopsys
JFrog XrayJFrog
Mend (formerly WhiteSource)Mend
Code Insight (by Revenera)Revenera

These tools offer capabilities for generating SBOMs, which are crucial for tracking and managing open-source components in software projects.

Identify the Scope

Building on Step 1, where you created an inventory of critical assets, start with software of high priority or high risk, this will offer immediate advantages and act as a valuable learning exercise for broadening the scope later on.

Generate the SBOM

Using the chosen tool, scan the identified applications and libraries to generate the SBOM. This process involves analyzing the software components and their dependencies to create a detailed inventory. Ensure that the tool is configured to produce SBOMs in the desired format, such as SPDX, CycloneDX.

One of the challenges when producing an SBOM is to decide at what stage of the SDLC you are to generate the SBOM. Is it when you release a new version of your application? Or do you want to keep track of all feature branches as well?

When to create an SBOM

We recommend to at least create an SBOM for each release that you push to production. Whenever another entity, internal or external, can consume the application or library you should have the ability to show an SBOM.

We also recommend creating an SBOM in the Build step if you have the possibility. See below video with some good pointers from Google as to why they think you should produce an SBOM during the build step and not from sources or from already built artifacts.

Above: Lessons Learned from Generating 100M SBOMs: Google’s Approach to SBOM Compliance

Using Trivy to create an SBOM

Creating an SBOM does not have to be difficult. Using free open source tools such as Trivy that is available as a Docker container, you can quickly generate an SBOM from your application source code or your own docker container.

To scan your application if you have it published as a Docker container:

# mkdir output

# docker run -v ./output:/output aquasec/trivy image -q --scanners vuln --format cyclonedx --output /output/result.cdx <DOCKER-IMAGE:TAG>

To scan your application from local file system ./:

# docker run -v ./output:/output -v ./:/input aquasec/trivy fs --scanners vuln --format cyclonedx --output /output/result.cdx /input

Review and Validate

After generating the SBOM, review it for completeness and accuracy. Validate that all components, their versions, and licenses are correctly listed. This step may involve cross-referencing with other documentation or consulting with development teams to confirm the details.

Importing the SBOM into SBOM Observer makes such a comparison an easy task.

Upload the newly generated SBOM under Attestation -> Upload Attestation

Integrate and Automate

Integrate SBOM generation into your software development lifecycle (SDLC) to automate the process for future developments. Automation ensures that SBOMs are consistently updated and maintained across all software projects, enhancing ongoing supply chain security efforts.

Read more on how to Integrating SBOM Observer with CI/CD Pipelines here.

Next Step

Continue to step 3 - External SBOMs for a discussion on how to manage 3rd party ICT risk and other external services and products using externally sourced SBOMs.