Generate Complete SBOMs
SBOM Adoption Strengthens License Compliance and Application Security
At its core, a Software Bill-of-Materials (SBOM) serves as a comprehensive, machine-readable inventory detailing the software components within an application, a system, or software stack. Analogous to a bill of materials in traditional manufacturing, an SBOM offers transparency and visibility into the software supply chain, facilitating robust software governance and risk management practices.
What components should be included in an SBOM?
Just like your food has a list of the ingredients it contains, a SBOM should list all third party and proprietary components in your software. To paraphrase from the NTIA’s document, Framing Software Component Transparency: Establishing a Common Software Bill of Material (SBOM):
In order to represent a complete bill of materials that creates sufficient transparency for software asset management and vulnerability management by the consumer, a SBOM must enumerate third-party software dependencies (both open source and proprietary) incorporated into the supplier product, as well as installed dependencies required at runtime.
For instance, if a supplier download manager installs software drivers, libraries, or runtime dependencies along with the supplier’s application, a complete SBOM for that product would include third-party dependencies within the compiled binary as well as software installed by the download manager.
In short, if a supplier product installs a third-party dependency on the consumer’s system, either as a constituent component of the product or as an installed enabling capability, it should be enumerated in the SBOM in order to provide requisite transparency for software asset management and vulnerability management.
In other words, an SBOM begins when a development team selects a software component for inclusion in their applications. These components can be publicly available open source software (OSS), commercial off the shelf (COTS) libraries from a 3rd party, internal shared common code modules, etc. Each of the included components is one element of the SBOM for the software being developed. The collection of all the elements makes up the full SBOM.
What information about the components are necessary?
As a base, your SBOM should contain the minimum elements for a SBOM as defined by the NTIA. You should also consider regulatory and industry requirements, such as the FDA requiring additional elements including support level, support end date, and known security vulnerabilities for commercial components.
Once again, again focus on the outcome. What governmental or industry regulation are you, or your clients (whoever needs to use and action your SBOM), needing to comply with?
SBOMs are not one-size-fits-all
Consider a scenario where you offer the same application in SaaS and on-prem models. What differences exist between the core application, its third-party components, and the instrumentation (backups, observability, performance management) that support a SaaS environment? If you only produced a single SBOM, the information in the second category would be irrelevant to those running On Premise.
This is one of the trickier aspects of SBOM production. Always consider the end goal when choosing the components to put into a SBOM. In this scenario where you produce both SaaS and on-premise versions of your software – how could the SBOM for your internal team be different than one for a client?
The supply chain for a SaaS application includes the entire stack, not just the application itself as required for the on-prem version. In this case, you may end up generating two SBOMs:
- One for the On-Prem version, generated when customer-hosted installer packages are cut. This SBOM only includes what is in the installer package—the On-Prem application and its dependencies.
- And a second for any build targeting a release candidate, tag, or branch. This is a superset of the first SBOM, with the additional components supporting the SaaS version.
Why produce two SBOMs? Think about it this way – you might use #1 for customer-facing artifacts and #2 to drive security and SOC-2 compliance. This view gives development and security teams a holistic view of risk, streamlines customer security reviews, and helps prioritize ongoing security improvements.
Generating SBOMs with FossID
Ingest SBOMs
The first step is to prepare the codebase you want to scan. What information ends up in your SBOM largely depends on your intended audience – is your SBOM for an external or internal audience? Are you producing a SBOM for a software deployed on-prem or a SaaS variant of the same software?
Scan & Code
In FossID Workbench, you start by creating a Project and a Scan for that project. Depending on your application repository structure, Projects generally represent individual components, services, or entire applications, and scans represent branches or release versions.
Identify Open Source Components
In this step you’ll add the managed and unmanaged open source components in your codebase to your Software Bill of Materials. Once the scan completes, you’ll review the matches FossID found in your codebase to open source components harvested in the FossID Knowledge Base.
Identify Proprietary and Commercial Components
Once all open source components are identified, review the files in the No Matches tab to identify any commercial or proprietary components in the same way as the open source ones.
Generate SBOM Reports
After all components are Identified, review the Identified tab to see the list of components that make up your SBOM and feel good that you’re ready to export your SBOM.
Fine-Tune Component and License Data
Depending on the requirements of the audience receiving your SBOM, you may choose to include or omit certain information about your components and their licenses.
Scan Incrementally for Up-to-Date SBOMs
Once you have your first SBOM, you’ll likely need to produce SBOMs of the same codebase on an ongoing basis. Typically, an SBOM is associated with a single release of software, and each new released version of code requires a new SBOM.
Automate Scanning in CI/CD
Consolidate Supplier SBOMs into Yours
Key Takeaways
Effectively implementing SBOMs can be challenging, but intelligent use of SBOMs can speed up risk management workflows rather than slow them down. In the end, SBOMs are a tool that can help you improve your security posture, increase development and release velocity, and streamline compliance processes and customer security reviews.
For any team looking to realize DevSecOps and ensure the resilience of their software supply chain, this is no small feat. But FossID can help with the technology, expertise, and insight from those that have been on this journey.
Key Capabilities
To successfully manage Software Bill-of-Materials (SBOMs) confidently and efficiently, look for the following capabilities.
SBOM Management
Ingest supplier SBOMs, consolidate and export NTIA-compliant SBOMs so you can easily meet regulatory security requirements.
Comprehensive OSS Database
CI/CD Integration
Related Resources
Talk to a Software Supply Chain Ninja
Book a discovery call with one of our experts to discuss your business needs and how our tools and services can help.