What is an SBOM?
A Software Bill of Material (SBOM) is a comprehensive inventory that details every software component that makes up an application. It includes open-source and commercial third-party libraries, API calls, versions, and licenses.
Applications used in the supply chain ecosystem are an amalgam of elements from several sources. These sources may contain vulnerabilities that cybercriminals could exploit during supply chain attacks. SBOMs ease vulnerability management by providing information about these elements.
When incorporated into the software delivery life cycle (SDLC), SBOMs enhance visibility into third-party software patch status and licenses, and provide other security-related information that can bolster code integrity.
SBOM’s role in cybersecurity
Gartner predicts that by 2025, an estimated 60% of organizations will mandate and standardize SBOMs into their software engineering practices, compared to less than 20% in 2022. This lends credence to the importance of SBOMs to organizational cybersecurity.
Government regulations and directives have also placed emphasis on the adoption of SBOMs. For instance, after the security incidents involving prominent organizations—such as Codecov and Kaseya in 2021—the White House issued the Executive Order on Improving the Nation's Cybersecurity, mandating SBOMs as a prerequisite for organizations transacting with government agencies.
Although SBOMs don’t prevent attacks, they ease the tracking of both first- and third-party software components, quickening the identification and mitigation of potential vulnerabilities. The Log4j and SolarWinds attacks offered real-time insights into how important SBOMs are. Let’s take a look at how both of these incidents played out.
The Log4j vulnerability, found in Apache Log4j, was tagged CVE-2021-44228 and had a 6.6 severity ranking. Cybercriminals exploited the vulnerability to gain unauthorized access to thousands of Java applications, into which they deployed malicious code.The incident affected several high-profile organizations—including Alibaba and Deutsche Telekom CERT—and raised eyebrows concerning the security of software used in supply chains, especially regarding risks posed by vulnerabilities in open-source libraries.
The 2019 SolarWinds attack orchestrated by Cozy Bear, a cybercriminal group, also proves the importance of SBOMs. Cybercriminals injected malware called Sunburst into SolarWinds' Orion IT network management system and infiltrated the network systems of about 18,000 SolarWinds customers. SolarWinds then unknowingly distributed the malware to customers via its March 2020 updates, resulting in a cyberattack that had far-reaching consequences, including financial losses to the tune of billions of dollars and about 11% loss in (the affected) organizations’ annual revenue.
These attacks and their consequences have nudged organizations towards the use of SBOMs. After the Log4j incident, several organizations raced to identify their points of implementing the Java library to minimize the attack surface and block the backdoor.
This was a long and arduous exercise because it required a component-by-component analysis of their entire stacks. But organizations that had already implemented SBOMs pre-attack swiftly pinpointed the exact locations of the Log4j component. This enabled them to take prompt action to mitigate the effects of the vulnerabilities, an important benefit—among others—of deploying SBOMs.
Benefits of SBOMs
The following are three core benefits of SBOMs.
1. Vulnerability management
Since SBOMs enable organizations to accurately track third-party components, they allow developers to assess associated risks, such as open-source libraries before and after incorporation. With these insights, developers can make informed decisions on components to adopt as well as maintain an up-to-date SBOM.
2. Regulatory compliance
Many governments and regulatory organizations now mandate the use of SBOMs as a standard. Industry standards such as the Payment Card Industry Data Security Standard (PCI DSS) and the Health Insurance Portability and Accountability Act (HIPAA) also impose rules regarding the security of software components that collect and process data. To this end, SBOMs can help organizations avoid legal and financial penalties and meet up with the required licensing and usage terms.
3. Incident response and forensics
SBOMs aid the exact identification of the vulnerable component if a security incident ever takes place. This zeroing in helps organizations prioritize affected segments in the network, and assess potential impacts, easing incident response and forensic analysis.
What should an SBOM include?
An SBOM should include details about all open-source and proprietary software components used in a product, including their names, versions, and licenses. It should also specify the relationships between components and their dependencies.
The following key elements should be present in an SBOM:
1. Component identifiers: This includes metadata such as supplier and component names, component origins, description and maintainers, artifact ID, timestamp, version number, and specific references, such as Git commit IDs or a SHA-1 hashes for every component.
2. Dependencies: The relationship between each component and its dependencies must be clearly documented.
3. Version information: This includes software version number, file name, and operating system to enable easy installation and prevent compatibility issues. Version information enables you to track necessary updates or patches for each component.
4. Vulnerability data: It is essential to include information about known vulnerabilities associated with each component. This data can be obtained from vulnerability catalogs such as the National Vulnerability Database (NVD) or CVE (Common Vulnerabilities and Exposures).
5. Licensing information: Each component has licensing terms (e.g., MIT, Apache, and BSD Licenses). The SBOM must contain these terms to ensure compliance with license obligations.
7. External references: These include URLs or documentation related to each component. They provide additional context on the functions of the components.
Wiz’s agentless SBOM allows you to gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots and deploying an agent.
Common SBOM formats
SBOMs can be generated manually or automatically.
The manual method involves listing all software components and their respective versions, licenses and dependencies in spreadsheets. It is only suited to small-scale deployments and is prone to human error.
The automatic method involves integrating SBOM tools into the Continuous Integration/Continuous Deployment (CI/CD) pipeline.
After generation, SBOMs are structured in two major formats: CycloneDX and Software Package Data Exchange (SPDX). Below is a brief description of each.
| Format | Description |
|---|---|
| SPDX | SPDX supports representation of SBOM information, such as component identification and licensing information, alongside the relationship between the components and the application. SPDX enables information gathering and sharing in various file formats, including human-readable and machine-parsable formats such as JSON, XML, and YAML. It enhances transparency, and facilitates license compliance. |
| CycloneDX | CycloneDX supports listing internal and external components/services that make up applications alongside their interrelationships, patch status, and variants. It structures the data as an XML or JSON file, and enables you to add details such as Common Vulnerability Scoring System (CVSS) scores and descriptions to the SBOM. CycloneDX is highly extensible, allowing developers to add new capabilities as required. |
To give you a better understanding of the SBOM formats, consider this example of the CycloneDX inventory in JSON format:
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79",
"version": 1,
"components": [
{
"type": "library",
"name": "nacl-library",
"version": "1.0.0"
}
]
}In addition to the two formats covered above, organizations can also use Software Identification (SWID) tags, which are usually installed during deployment. SWID tags provide SBOM information such as software component release dates and licenses. Regulatory bodies and the US government consider SWID tags, CycloneDX, and SPDX as acceptable SBOM formats.
Challenges to creating and maintaining SBOMs
Creating and maintaining SBOMs can pose the following challenges.
| Challenge | Description |
|---|---|
| Complete application inventory | An accurate SBOM is a comprehensive inventory. So, generating one involves tracking applications across various environments and departments. This can be taxing and time consuming. |
| Generating SBOMs throughout SDLC | For end-to-end security of the supply chain, SBOMs must be implemented during every phase of the SDLC process: development, testing, and deployment. This may introduce maintenance overhead especially if the applications are regularly updated or when software release is in sprints. |
| Code and image scanning | Since SBOMs can be generated through code and image scanning, code-scanning techniques often result in inflated reports containing production-inactive dependencies, thereby seeding fatigue into the assessment process. |
| Efficacy | Although SBOMs seek to mitigate the effects of software component vulnerability, they rarely provide in-depth information such as the extent of damage of identified vulnerabilities. This is a blind spot that DevSecOps teams try to address. |
Wiz's approach to SBOM security
Wiz Code enhances SBOM (Software Bill of Materials) security by providing comprehensive visibility into the components and dependencies within your software. With real-time scanning and automated security checks, Wiz Code ensures that vulnerabilities within third-party libraries and open-source components are identified and mitigated early, keeping your software supply chain secure.
Some advantages of agentless SBOM deployment include:
Flexibility and simplicity: Dedicated agents are add-on services that consume resources, adding to a fast-depleting resource tank. Agents also need ongoing maintenance, adding to a sky-high maintenance overhead. Agentless deployment eradicates this. Agentless SBOM deployment also eliminates agent-to-OS compatibility concerns, ensuring consistent and reliable SBOM generation across diverse environments.
Instant and complete visibility: Agent-based deployment can be time-consuming since agents must be installed on each subsystem in the software stack. Quite differently, an agentless SBOM gives you a complete view of your applications' components—from the open-source libraries in use to the package and nested dependencies involved—within minutes, without leaving any blind spots.
SBOM search: Search and locate specific OS and open-source packages across cloud environments, helping to quickly address security vulnerabilities by identifying outdated or compromised libraries. This capabiliity is particularly timely given recent critical vulnerabilities found in widely used libraries like xz-utils.
Always up to date: As opposed to agent-based SBOM deployment, which requires manual installation which can be error-prone, an agentless approach allows you to generate up-to-date SBOMs without manual intervention, ensuring consistent and efficient supply chain security observability.
Agentless SBOM Generation
Gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots.
