A Software Bill of Materials (SBOM) is a list of all the components, libraries, and modules that make
up a software, providing transparency into its composition. It describes various packages and dependencies that go into creating a software artifact.
Software products are composed of many different components, some of which might come from
third party sources. These third-party components and dependencies can have vulnerabilities, which
attackers can exploit, leading to security incident or breaches. Key threats include attackers inserting
malicious code, vulnerabilities in outdated components, and breaches by compromised suppliers. These issues can lead to data breaches, operational disruptions, and reputational damage. SBOM can help improve software security and protect against potential threats.
Effective Incident Response - SBOM can assist in speeding up by providing detailed information on dependencies.
Vulnerabilities identification and patch management - Using SBOM, organizations can quickly spot and address known vulnerabilities in the software by patching them.
Compliance - SBOM helps organizations to streamline adherence to security regulations, guidelines and best practices on software security by providing required transparency in software composition.
Many Governments around that world are now recommending SBOM like,
There are standards/specifications available to represent bills of material including SBOM. When it comes to SBOM, below are widely adopted standards,
SPDX - An open standard capable of representing systems with software components in as SBOMs (Software Bill of Materials) and other AI, data and security references supporting a range of risk management use cases.
CycloneDX - is a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction. CycloneDX is an Ecma International standard published as ECMA-424.
Various tools and libraries typically scan the container images, file systems and generate a Software Bill of Materials as per above specifications. Each tool supports parsing of files for various languages/platforms to extract details on dependencies.
Below are some of the open source tools available,
CycloneDX has repository that contains various tools like,
Cyclonedx-CLI - Cli for conversion, analysis, merging
Once SBOM is generated, one can use tools like Trivy to assess vulnerabilities, misconfigurations, secrets etc. Trivy can be used to scan Containers, File systems or sbom (SPDX or CycloneDX JSON only as of writing of this article).
Sample Report by Trivy
The above tools are typically integrated in Build (CI/CD) pipeline for automated SBOM Generation, vulnerabilities detection and reporting.
High level Adoption approach could be,
Initiation
Identify Critical Assets and Develop a Project Plan.
Determine the SBOM format and minimum requirements.
Identify security requirements,secure storage and tooling.
Plan for Proof of Concept
Progress
Secure Installation and Operation Guidance Development.
Preparation of SBOM
Integrate SBOM in each phase of Secure Software Development Lifecycle.
Scan for vulnerabilities, secrets, misconfigurations
Take corrective actions.
On going
Analysis and review of existing SBOM periodically and any changes as needed
Using above tool(s), one can generate Software bill of Material in standard formats (SPDX/CycloneDX) or tool’s own proprietary format (e.g. syft has its own specification too.). Integrating this process of detection and corrective action as part of Continuous build and Deployment process will go long way in being up to date with vulnerabilities detection.
