Author: Sandeep Bajpai, Senior Architect
“ SBOM — What’s that ? “ Don’t worry its not A bomb or A soft bomb 😃”
SBOM stands for Software Bill of Materials. It is a comprehensive inventory of all the components and dependencies that make up a software product. It is essentially a list of all the software components, libraries, and dependencies used in creating a software product, along with their respective versions, license information, and other relevant metadata.
“Lets Understand with An Example”
A Seasoned Project Manager and Technical Architect decided to start building a software product , They created a Team of developers and asked them to develop a module of the product. Development Team starts developing the module and soon they realise that they would need some open source or licensed libraries to be integrated or imported for completing the module functionality. They used the open source modules , packaged and deployed on the test environment. Technical Architect was reviewing the code and identified few lines codes from two different developers
Developer -1 Code:
import random
# generate a random number between 1 and 10
random_number = random.randint(1, 10)
# print the random number
print("Random number:", random_number)Developer -2 Code
import modern
# generate a random number between 1 and 10
modern_number = modern.randint(1, 10)
# print the random number
print("Modern number:", modern_number)Based on above review — Technical Architect realised that developer-1 and developer 2 imported some libraries and there is possibility of having more modules , libraries , packages which are not getting scanned from their internal security team. Architect asked the Project Manager to collect the the list of Modules/packages/libraries used while developing the module.
Project Manager interacted with Development team and created detailed list (including vendor details , licensing and version) of Software/Modules/Packages used to build the Software module. This List is called “Software Bill of Material” or SBOM.
“SBOM — Is it Important or beneficial to integrate ?”
Following are the benefits of creating the SBOM :
- Improved Software Supply Chain Security: With the growing number of software supply chain attacks, SBOMs can help in identifying the vulnerabilities and potential risks associated with the use of open source software components. This will help quickly identify and validating the security issue into the software supply chain.
- Compliance and Legal Obligations:Many software products uses 3rd party tools/libraries including open source software components, which come with different types of licenses. SBOMs help in identifying the licenses and other legal obligations associated with each component, which can help in compliance and avoiding legal issues.
- Increased Transparency: SBOMs help in providing a comprehensive list of all the software components and dependencies used in creating a software product. This can help in increasing transparency and trust between software vendors and users.
- Efficient Patch Management: With an SBOM, software vendors can quickly identify the components that need to be updated or patched .
- Better Risk Management: SBOMs can help in identifying the vulnerabilities and potential risks associated with the use of 3rd party tools/libraries especially open source software components.
“How would you create and Manage SBOM for Large and Complex Software Product or Environment ?”
Manually ……… ♿️
Creating a Software Bill of Materials (SBOM) for an operating system or Software can be a complex task due to the number of components involved. However, the following steps can be used as a general guide:
- Identify all the components: Identify all the software components and dependencies that make up the operating system, including the kernel, drivers, libraries, applications, and other system software.
- Gather metadata: Gather metadata for each component, including the name, version, license information, and any relevant security or compliance information.
- Validate the SBOM: Validate the SBOM to ensure that all the components and metadata are accurate and complete. This can be done by cross-checking the SBOM against the actual software components used in the operating system.
- Publish the SBOM: Publish the SBOM in a standardized format such as SPDX, CycloneDX, or SWID, and make it available to stakeholders such as software vendors, users, and regulators.
- Maintain the SBOM: Maintain the SBOM by updating it regularly as new software components are added or removed from the operating system.
Automatically … 🤖
- Use automated tools: Use automated tools to scan the operating system , filesystems or docker-image and generate a list of components and metadata. There are various open source and commercial tools available that can help in creating an SBOM. Below Are some tools to generate SBOM automatically :
FOSSology
WhiteSource
Sonatype Nexus
CycloneDX
Syft
Creating an SBOM for an operating system requires identifying all the components, gathering metadata, using automated tools, validating the SBOM, publishing it in a standardized format, and maintaining it regularly.
“Let us take an example to walk through the SBOM creation process Using Syft Tool “
Suppose you have a Linux Machine and You want to generate a SBOM for the server . The process is straight forward
a) Install the Tool
b) Run the Tool.
Lets make it more easy for you — Below is script to generate the SBOM for a specific filesystem on your Linux Operating System :
#/bin/bash
# Check if syft is already installed
syft version
if [ $? -ne 0 ]
then
echo "Syft is not installed. Installing Syft Now...."
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
else
echo "Syft is installed"
syft version
fi
# Check if JQ is already installed ( Optional - For Future Use casses )
jq --version
if [ $? -ne 0 ]
then
echo "JQ is not installed. Installing JQ Now...."
yum install -y jq
else
echo "JQ is installed"
fi
#Generate SBOM for specific filesystem
echo Generating SBOM ...
syft dir:/opt -o cyclonedx-xml --file /opt/sbom/output/sbom-raw-opt.xml“Your SBOM is Ready … Whats Next ?”
Your SBOM is ready — Lets Inject it into “Continuous SBOM Analysis Platform“ , One of them is Dependency Track .
Want to Learn More About SBOM Analysis Platform , Wait for my next Blog.
“Few other use cases”
Who doesn’t like 🍒 on 🍰 — Here are some other use-cases of SBOM:
- Just pretend that you got a Cloud Migration project from a client . You have to plan application migration from On-Premise to Public Cloud or vice-versa . You Just have to scan the Application code and Infrastructure using SBOM generators tool and whole list of Packages, Builds,Libraries and dependencies available.
- Your CXO team asked you to provide list of OpenSource vs Licensed tools used in your software supply chain — SBOM can do a magic here.
Conclusion
The purpose of creating an SBOM is to increase transparency and visibility into the software supply chain. It helps software vendors and users understand the security posture , dependencies and possible risks of a software product, identify potential vulnerabilities and compliance issues, and track the usage of open source components.
SBOMs are becoming increasingly important in the software industry, particularly in the context of cybersecurity and software supply chain security. The National Telecommunications and Information Administration (NTIA) and other industry groups are promoting the adoption of SBOMs as a best practice for improving software security and supply chain transparency.
Reference
