When using digital technology, ensuring the security of the software supply chain has become essential due to the rising frequency and complexity of cyberattacks. Recent incidents like the SolarWinds supply chain attack and the Log4Shell vulnerability have highlighted the critical need for transparency and security in software components. A Software Bill of Materials (SBOM) plays a pivotal role in this security framework by providing detailed information about all components in a software application.
When integrated with code signing, SBOMs ensure that software remains authentic and untampered. It not only verifies the integrity and authenticity of the code but also accurately catalogues its composition, providing a comprehensive overview of all included components. Encryption Consulting LLC’s CodeSign Secure portal provides SBOM as a key feature that allows users to scan their code for vulnerabilities before deployment. By generating an SBOM scan, the portal provides a clear view of the software’s makeup, helping developers push secure code to platforms like GitHub.
What is SBOM?
An SBOM, or Software Bill of Materials, is a complete list of all the components, libraries, dependencies, and key details like licenses and versions used to build a software application. It allows organizations to comprehend their software’s composition, identify potential security risks, and ensure compliance with industry regulations.
- Vulnerability Identification: SBOMs allow organizations to pinpoint outdated or vulnerable components, enabling timely updates.
- Regulatory Compliance: Mandated by the U.S. government’s 2021 executive order for software vendors (Executive Order 14028), SBOMs ensure adherence to standards like NIST, ISO 27001, and GDPR.
- Risk Management: By providing visibility into the software supply chain, SBOMs help mitigate risks from supply chain attacks. Tools like Syft, Trivy, and various SPDX tools (e.g., SPDX SBOM Generator) are commonly used to generate these detailed lists, enabling your organization to identify and address vulnerabilities within its software components proactively.
History of SBOM
The concept of SBOM has evolved alongside the growing intricacy of software development.
- Early 2010s: The need for SBOM arose from the increasing use of open-source software, which introduced challenges in tracking licenses and vulnerabilities. SBOMs began as a way to aggregate data about open-source licensing for software components.
- 2010: The Linux Foundation introduced the Software Package Data Exchange (SPDX) format, a standardized way to document open-source licenses and compliance. SPDX became a foundation for SBOM, later achieving ISO standard status (ISO/IEC 5962:2021) in 2021.
- 2017: OWASP, or Open Web Application Security Project, launched CycloneDX, a security-focused SBOM format designed to identify vulnerabilities, ensure license compliance, and analyse outdated components. Both SPDX and CycloneDX became dominant due to their robust tooling support and their strong alignment with evolving security policies and regulatory requirements, making them practical choices for widespread adoption.
- 2018–2021: The National Telecommunications and Information Administration (NTIA) led a multistakeholder process to advance SBOM adoption. This effort standardized SBOM practices and promoted their use across industries. During this period, open-source tools like Syft emerged for generating SBOMs, often paired with vulnerability scanners like Grype to provide a comprehensive view of software components and their associated risks.
- 2021: The U.S. government’s Executive Order on Improving the Nation’s Cybersecurity (May 2021) mandated SBOMs for federal software acquisitions, emphasizing their role in securing software supply chains.
Benefits of SBOM
SBOMs provide significant advantages across the software lifecycle, benefiting developers, buyers, operators, and the broader ecosystem. Below are the key benefits as per the user roles, such as Developer, Buyer, or Operator, drawn from industry insights and strategies:
| User Roles | Benefits | Example |
|---|---|---|
| Developers |
|
For instance, a critical vulnerability (CVE) is announced for an open-source library that a financial software company uses. The development team can immediately query their internal SBOMs for all their applications. Within minutes, they identify which specific applications are affected, down to the version of the vulnerable library. They can then prioritize patching or upgrading those applications, minimizing their exposure to the new threat without manually reviewing countless lines of code. |
| Buyers |
|
For example, a large enterprise is evaluating two different HR management systems from competing vendors. ‘Vendor A’ provides a detailed SBOM, which shows all the third-party libraries, their licenses, and known vulnerabilities (with remediation plans), whereas ‘Vendor B’ provides no SBOM. The enterprise’s security team can use Vendor A’s SBOM to assess the security level of their product confidently, identify potential licensing conflicts, and demonstrate due diligence to auditors, making ‘Vendor A’ a much more attractive and trustworthy choice. |
| Operators |
|
For instance, a new, critical vulnerability in a widely used web server component (e.g., OpenSSL) is publicly disclosed. The operations team can cross-reference this vulnerability with the SBOMs of all their deployed applications and infrastructure components. This allows them to instantly pinpoint every server or application that utilizes the affected OpenSSL version. Instead of a manual, time-consuming audit, they can rapidly initiate targeted patching across only the impacted systems, significantly reducing the Mean Time to Respond (MTTR) to the incident and maintaining system availability. |
Consequences of Not Using SBOM
Failing to adopt SBOM can lead to considerable risks and vulnerabilities, especially given our current cyberspace and threats.
| Consequence | Description | Example |
|---|---|---|
Insecure Products | Without an SBOM, vulnerabilities in third-party components may go undetected, increasing the risk of cyberattacks. | SolarWinds Supply Chain Attack (2020): Attackers inserted malicious code into a legitimate software update from SolarWinds, a widely used IT management company. An SBOM for the SolarWinds software, if properly utilized, could have helped detect the presence of the unauthorized, malicious component during the build or deployment process, potentially preventing or significantly limiting the impact of this widespread supply chain attack. |
| Missed Security Updates | Lack of visibility into components makes it hard to know when updates or patches are needed, leaving software exposed. | Log4Shell Vulnerability (2021): The critical Log4Shell vulnerability in the Apache Log4j library impacted countless applications globally. Organizations without SBOMs struggled immensely to identify all instances of Log4j within their systems. They had to undertake massive, manual efforts to scan codebases and deployed applications, leading to delayed patching and prolonged exposure to a severe remote code execution vulnerability. |
| Legal Challenges | Untracked licenses can lead to violations, resulting in legal battles, financial penalties, and reputational damage. | GPL Violations (Numerous Cases): Many companies have faced legal action (or public scrutiny) for violating open-source software licenses, particularly the GNU General Public License (GPL). Without an SBOM clearly documenting the licenses of all included components, a company might inadvertently distribute software containing GPL-licensed code without providing the required source code, leading to infringement claims, product recalls, and significant reputational harm, as seen in cases involving various embedded device manufacturers or software distributors. |
| Unmet Compliance Requirements | Industries like healthcare require SBOMs for compliance (e.g., FDA’s “refuse-to-accept” policy). Non-compliance can delay product launches and incur costs. | Medical Device Regulations (FDA): The U.S. FDA, through guidance and policies, increasingly requires medical device manufacturers to provide SBOMs for their software. A medical device company failing to provide a detailed and accurate SBOM for a new device could have its submission rejected by the FDA, leading to significant delays in product approval, loss of market opportunity, and substantial financial costs associated with rework and resubmission. |
| Inefficient Development | Without SBOM, developers face delays in incident response, resource wastage, and challenges managing dependencies, leading to bloated code. | “Dependency Hell”: A development team building a complex application without an SBOM might find themselves in “dependency hell,” where conflicting versions of libraries cause build failures or runtime errors. When a security vulnerability is discovered, the absence of an SBOM forces developers to manually trace dependencies, potentially spending days or weeks identifying affected modules and their transitive dependencies, leading to inefficiency, delays, and an increase in development costs. |
SBOM in Encryption Consulting’s Code Signing Solution
Encryption Consulting LLC’s CodeSign Secure portal integrates SBOM to provide a robust solution for code signing and security. Here’s how to use the SBOM feature from our CodeSign Secure:
Access the SBOM Feature
Initiate a Scan
-
Click the Scan Code button.
-
Enter required details, including a GitHub Personal Access Token (PAT) for
repository access.
- To generate a PAT:
-
Go to GitHub settings > Developer Settings > Personal Access Tokens.
- Select “Tokens (classic)”.
- Click “Generate new token (classic).”
- Add a token note and grant permissions for “repo” and “workflow.”
Upload Code
Review Results
-
If vulnerabilities are below the specified threshold, a success message confirms the code is safe.
-
If vulnerabilities exceed the threshold, a warning message will prompt you to address the issues.
Insights of SBOM: Trends and Future
SBOMs are becoming a strategic imperative for organizations, driven by regulatory mandates, industry adoption, and the need for transparency in software supply chains.
Market Growth
The SBOM market is seeing exciting growth, with forecasts suggesting it will hit $1.318 billion in 2025, which is a remarkable expansion at a Compound Annual Growth Rate (CAGR) of 24% from 2025 to 2033. (Market Report Analytics). This growth is driven by increasing regulatory mandates and heightened awareness of vulnerabilities in complex software ecosystems. Sectors such as financial services, healthcare, and government are leading in adoption due to their sensitivity to security breaches and strict compliance requirements.
Regulatory Push
Regulatory bodies worldwide are recognizing SBOMs as essential for securing software supply chains. In the United States, the Cybersecurity and Infrastructure Security Agency (CISA SBOM) has mandated SBOMs for federal software acquisitions, a requirement solidified by the 2021 Executive Order on Improving the Nation’s Cybersecurity. Internationally, regions like the European Union and Asia-Pacific are introducing similar regulations, particularly for critical infrastructure and high-risk sectors. As per the reports from ISACA, these mandates are pushing organizations to integrate SBOMs into their development and procurement processes, making them a standard practice for compliance and risk management.
Technological Evolution
The future of SBOMs is marked by innovation and deeper integration into software development practices. As these trends evolve, SBOMs will play an increasingly central role in securing software ecosystems.
- Automation and Integration: Automation and integration with DevSecOps are becoming seamless, facilitating real-time security insights through tools that simplify SBOM generation and enhance accuracy.
- Vulnerability Exploitability eXchange (VEX): The development of standards like the Vulnerability Exploitability eXchange (VEX) complements SBOMs by providing context on vulnerability exploitability. VEX allows organizations to communicate whether a known vulnerability (CVE) found in a component listed in an SBOM is exploitable in their specific product or environment. This helps filter out irrelevant CVEs and significantly reduces “alert fatigue,” allowing security teams to focus on true risks.
- AI/ML Enhancements: Emerging technologies like AI/ML are set to improve SBOM analysis by providing greater insights into supply chain risks, predicting potential vulnerabilities, and enhancing automated remediation suggestions.
Conclusion
The Software Bill of Materials is an important tool for organisations to navigate the complexities of modern software development. SBOMs enable organizations to manage risks, ensure compliance, and build secure applications by providing transparency into software components.
Encryption Consulting LLC’s CodeSign Secure leverages SBOM to help users scan code, identify vulnerabilities, and confidently deploy. Along with this, it is truly a future-proof solution for software integrity. It provides robust support for reproducible builds, ensuring software artifacts’ consistent and verifiable reconstruction before signing using pre/post hash validation. Furthermore, CodeSign Secure is designed to facilitate the transition to post-quantum cryptography (PQC), helping organizations proactively adapt their signing processes to resist the threats posed by future quantum computing advancements.
By automating workflows, ensuring compliance, and leveraging advanced security features such as vulnerability scanning, reproducible builds, and post-quantum cryptography (PQC), CodeSign Secure empowers organizations to protect their software assets while maintaining trust in their products.
