Software passing through different stages in its development lifecycle is akin to the many stages of factory refinement that a silicon chip goes through. From one stage to the next, the software undergoes keen, close examination, consisting of various additional elements or ingredients.
Today, software is not developed in isolation or necessary from scratch. Codes and libraries are culled from various sources to speed up the process. However, only some of these elements are 100% secure, which is why it’s essential to ensure that the sources are at least verified, vetted, and accounted for.
Poor software is one that uses outdated or compromised code in its development lifecycle. Such a product is equally bound to have security breaches, providing an avenue for malicious elements to wreak havoc.
Before proceeding further in this article, let us briefly examine the concept of SBOM and how it is linked to cybersecurity.
What is an SBOM?
SBOM is an acronym for Software Bill of Materials. It refers to an inventory of every contributing sub-element to the final software package.
In other words, it’s a list of software that constitutes software. As previously highlighted, developers use third-party open-source components in developing their products. An SBOM accurately lists these constituents, giving end users a comprehensive overview of everything included in the package and allowing them to identify and avoid suspicious or harmful components.
Below are some of the constituents of an SBOM:
- Libraries
- Licenses
- Version strings
- Patch details
- Author name
- Supplier name
- Component hash
A primary concern for software organizations is the unwitting incorporation of compromised elements into their workflow. In such cases, the software will carry inherent security vulnerabilities, which is dangerous for the software supply chain.
Working with an SBOM
By using SBOMs, software developers take concrete steps toward achieving visibility and transparency in their development processes. However, there needs to be a fixed way to implement an SBOM into your process.
Each software development life cycle is unique, and it’s important to equally customize the process of generating an SBOM. In other words, the documents must accommodate various formats and provide consistent updates to avoid missing alterations that could contain potential vulnerabilities.
That is to say that software organizations must maintain a “living” SBOM rather than a static one.
The NTIA (National Telecommunications and Information Administration) recently published the Minimum Elements for a Software Bill of Materials, which has gained de facto adoption for SBOMs.
Per the requirements, all SBOMs are required to have these three elements:
- Data fields
- Automation support
- Practices and processes
In the first instance, data fields document basic information about each component to be tracked. On the other hand, SBOMs should have automation support to boast cross-platform scalability. Then, the final requirement for SBOMs is a detailed documentation of the processes and practices defining operations.
SBOM Formats
SBOM Formats refer to the standards that define a uniform structure for generating SBOMs. In other words, it defined software constituents in a format that other tools can interpret.
Although there are several other formats, the NTIA/CISA Software Component Transparency Initiative recognizes three main formats:
SPDX
Software Package Data Exchange is a Linux Foundation Project developed to serve as a common means of exchanging data via a unified format.
Of the top SBOM formats, SPDX has the widest file support range with support for RDFa, .XML, .JSON, .SPDX, and .yaml.
Additionally, SPDX has ISO (International Organisation for Standardization) certification, a plus for the format regarding quality assurance.
As such, it’s no surprise that SPDX is the preferred SBOM format for leading organizations like Sony, Siemens, Microsoft, and Intel.
SPDX documents comprise key information regarding relationships, annotations, licensing, files, snippets, packages, and document creation. The latter is used for backward and forward compatibility when using compatibility tools. On the other hand, package information includes descriptions of elements like components, products, and containers.
File information includes checksum licenses, copyright info, and other metadata.
SWID
The Software Identification (SWID) tag is a standardized XML-based SBOM format comprising of four tag types:
- Corpus
- Distribution
- Primary
- Configuration
Corpus tags help in identifying software constituents in the pre-installation stage. On the other hand, primary tags provide post-installation product definition, while distribution tags identify the product’s operating system or runtime environment, such as the Windows OS.
SWID is a vendor-neutral SBOM format that defines the product’s patch rather than the core product. The information in the tags acts as security and software asset management tools that support software inventory automation to identify missing patches, verify software integrity, and carry out checklist assessments.
CycloneDX
CycloneDX belongs to the Open Web Application Security Project (OSWAP) and is a lightweight SBM standard developed for application in the context of software supply chain security.
CycloneDX stands out from the other formats as one specifically designed to be a cross-compatible SBOM.
The platform supports a hierarchical referencing of vulnerabilities, services, and components that integrate with the inherent complexity of modern-day hardware and cloud infrastructure. To this effect, it supports the XML and JSON formats.
Additionally, CycloneDX supports the curation of all third and first-party constituents for vulnerability identification. This is possible through its comprehensive list of component classes and types, many of which have use cases outside of applications and software.
CycloneDX also supports integrity verification via software signing and provenance.
Creating SBOM
There are two main ways to create a software bill of materials- manually or via automation.
Given just how many complex components constitute SBOM, it is safe to say that manual assemblage is out of the question.
SBOM formats are machine-readable, so automation is the best way to generate one. Instead of going through the time-consuming and draining process, you can implement update changes on the go and ensure component verification via cryptographic signing.
There are three ways to automate SBOM creation:
Via an open-source tool
You can automate SBOM creation by using relevant open-source tools like Paketo and JupiterOne. However, open-source tools will only generate SBOM in one of two formats- CyclodeDX or SPDX.
Via a composition analysis tool
An alternative way to automate SBOM creation is to use a software composition analysis (SCA) tool. This methodology is designed to analyze third-party code legitimacy, license compliance, and software security.
SCA tools analyze the source code, binary file, container images, and software composition. After that, the open-source components are outlined in an SBOM and run through databases for further analysis to detect licensing, security information, and potential vulnerabilities.
SCA tools are quick, efficient, and compatible with cloud-native applications.
Use plugins in the CI/CD pipeline
CI/CD refers to Continuous Integration/Continuous Deployment, a core DevOps practice. By using maven plugins at the build stage of your Continuous Integration/Continuous Deployment workflow, you can audit and create SBOMs in the development pipeline.
Conclusion
Generating SBOM is one of many ways to protect your software from threats to the software supply chain.
The spate of attacks on high-profile tech corporations including SolarWinds and MiMi should serve as a wakeup call to specialists and professionals in the industry to take concrete steps to protect their apply chain.
Even if your software relies on external code, as is most likely the case, you can protect your product by automating SBOM creation. This way, you can speed up your workflow, and secure the development pipeline in one go.
