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.
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.
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:
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.
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.
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.
SBOM use cases can be broadly divided into three main categories:
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/