In recent years, the adoption of open-source software in development has surged, now comprising up to 90% of what’s built. Its popularity among companies globally stems from cost savings and accelerated product time-to-market. However, there is a crucial aspect to consider when integrating open-source software components. Synopsys reports that 84% of commercial and proprietary code bases include at least one known open-source vulnerability. This highlights the increasing importance of ensuring the security of the open-source components you use. And this is where a Software Bill of Materials (SBOM) comes in handy. 

What is an SBOM?

Open-source components and third-party code can be complex, with many layers. Just like Russian nesting dolls, these parts fit inside one another, and each layer can come with its own rules. To make sure their software is safe, companies need to know exactly what’s in it.

An SBOM provides detailed information about each component. It is like a label for software, which lists all the parts and their relationships – like a mix of open-source pieces, third-party parts, and the company’s own code. It gives technical details about each piece, including its name, version, and license. SBOMs can also include information on security issues, transitive dependencies, component origins, and other information.

For instance, in the automotive industry, manufacturers create detailed specifications for each vehicle, including parts they made and those from outside suppliers. If a part is found to be defective, the manufacturer quickly knows which vehicles are affected. It allows them to inform owners about needed repairs or replacements. This kind of clear record-keeping is important for finding where defects come from and how to fix them effectively.

Minimum Data Requirements 

In the U.S., software developers are increasingly adopting the Software Bill of Materials (SBOM), influenced by new government information security policies that require more stringent software security measures.

The Presidential Executive Order No. 14028, issued on May 12, 2021, aimed at “Improving the Nation’s Cybersecurity,” establishes specific standards for federal information systems. A key aspect of this order, detailed in Section 4, involves formulating guidelines for secure software development and procurement practices. The document recognizes SBOM as a crucial element for ensuring software integrity and managing risks associated with the software supply chain.

In line with Executive Order No. 14028, the U.S. Department of Commerce and the National Telecommunications and Information Administration (NTIA) have outlined minimum data requirements for software components, categorized into three primary groups:

1. Data Fields include essential information about each software component, such as:

• • Supplier Name: The name of an entity that creates, defines, and identifies components.
  • Component Name: Designation assigned to a unit of software defined by the original supplier.
  • Version of the Component: Identifier used by the supplier to specify a change in software from a previously identified version.

• Other Unique Identifiers: Other identifiers that are used to identify a component, or serve as a look-up key for relevant databases.

• Dependency Relationship: Characterizing the relationship that an upstream component X is included in software Y.
• Author of SBOM Data: The name of the entity that creates the SBOM data for this component.
• Timestamp: Record of the date and time of the SBOM data assembly.

1. Automation Support facilitates the automatic generation of SBOMs and machine-readability to allow for scaling across the software ecosystem. Furthermore, SBOMs should be generated in one of the following three formats:

• Software Package Data eXchange (SPDX)
• CycloneDX
• Software Identification (SWID) Tags

Software Package Data eXchange (SPDX)

This format is widely used for documenting information about software licenses and components. Developed by the Linux Foundation, SPDX standardizes the way organizations communicate the software components and licenses used in their products, thereby simplifying compliance.

CycloneDX

Primarily focused on security, CycloneDX is a lightweight SBOM format designed for use in application security contexts and supply chain component analysis. It provides a standard way to represent the components, libraries, and modules in an application, along with their associated security risks and licensing.

Software Identification (SWID) Tags

Developed by the International Organization for Standardization (ISO), SWID tags are XML structures that provide unique identification for software products. They help in managing software inventory and ensuring compliance with licenses. SWID tags are particularly useful for software asset management and cybersecurity purposes.

• Practices and Processes that need to be followed to integrate SBOM into the secure development lifecycle. These include establishing a frequency for SBOM updates, defining the depth of dependency trees, handling SBOM elements with uncertain or incomplete dependency information, and setting policies for distribution, delivery, and access control. 

SBOM Use Cases

SBOM use cases can be broadly divided into three main categories:

• Vulnerability detection and management: SBOM helps keep track of all code components. When a critical vulnerability is found, security teams can quickly use the SBOM to locate the issue in the code, understand its impact, and prioritize fixing it. For example, TuxCare’s SecureChain for Java provides a detailed SBOM for each Java package vetted and patched by the service, ensuring complete transparency for informed decision-making.
• Software license management: With an SBOM, companies can easily keep track of licenses for third-party and open-source software. Licenses often change, so regular checks are necessary. This helps ensure the company doesn’t break any license agreements or intellectual property rights, avoiding legal issues and financial risks.
• Software development lifecycle (SDLC) improvement: SBOM makes the whole process of creating, deploying, and maintaining software more efficient. For example, developers list all the software dependencies in an initial SBOM as they write code. This SBOM gets updated during the testing and deployment phases as new vulnerabilities and dependencies are found. It also alerts developers to any issues that arise after the software is in use, ensuring continuous updates and improvements. 

The Future of SBOM

SBOM is particularly crucial for companies that supply software to government entities, notably in sectors like defense and aerospace. However, its relevance extends to other companies as well.

The recent uptick in supply chain attacks, often exploiting open-source vulnerabilities, underscores the importance of rigorously examining third-party open-source components, libraries, and frameworks. These attacks can enable malicious actors to take complete control of a company’s systems, disrupt product functionality, introduce malware, and even spread viruses to clients and other interacting organizations. The unpredictable and potentially extensive impact of such attacks makes them a significant threat.

Gartner predicts that, by 2025, 60% of organizations will incorporate SBOM into their security systems. However, while useful, SBOM is not a panacea for software supply chain and assurance challenges, as recognized by NTIA. It’s one of many tools, not an all-encompassing fix. The effectiveness of SBOMs hinges on widespread adoption, which is still in progress, with standards and requirements evolving. Achieving universal use will take time, given the emerging variety of tools and standards currently in development.

The post Understanding SBOMs appeared first on TuxCare.

*** This is a Security Bloggers Network syndicated blog from TuxCare authored by Artem Karasev. Read the original post at: https://tuxcare.com/blog/understanding-sboms/