A Software Bill of Materials (SBOM) lists all the open source and third-party components present in a codebase, and has been mandated in the US. It helps make software transparent and less vulnerable to attacks.
Open source software security is always in the spotlight. Every time there is a cyber attack, a lot of time and effort is required to detect not just when, where and how it occurred, but also to measure the real impact on the applications and services that are running in digital environments. Recent cyber attacks have highlighted the general lack of knowledge about code dependencies and attacks on the software supply chain.
A Software Bill of Materials (SBOM) helps organisations to meet new domestic and international cyber security requirement laws. Supply chains point out the relationships between the various components used in building software. These components include libraries and modules. They can be open source or proprietary, and free or paid.
Why are SBOMs needed?
An SBOM is a list of all the open source and third-party components present in a codebase. It also lists the licences that govern those components, the versions of the components used in the codebase, and their patch status. This helps security teams to quickly identify any associated security or licence risks.
An SBOM provides a machine readable list of components of the software and its dependencies. As it has become a key component for cloud security for private and government organisations, it is estimated that 88 per cent of organisations will use SBOMs by the end of 2023.
Similarly, smart organisations that build software maintain an accurate, up-to-date SBOM, which includes an inventory of third-party and open source components to ensure that their code is of high quality, compliant, and secure.
SBOMs and cyber security
In 2021 there were several high-profile security attacks, including on software companies like Codecov, Kaseya and, most recently, Apache. These types of supply chain attacks prompted the US to issue a cybersecurity executive order detailing guidelines for how federal departments, agencies, and contractors doing business with the government must secure their software.
Among the recommendations was a requirement for SBOMs, to ensure the safety and integrity of software applications used by the federal government.
Any organisation that develops software in the US must now maintain SBOMs for its codebases.
Software supply chain management company Sonatype, in collaboration with Red Hat, provides SBOM certification on the Kubernetes platform. Sonatype Nexus Lifecycle with Red Hat OpenShift can easily integrate an automated and production-ready SBOM with software, to increase transparency and stop a cyber attack.
However, SBOMs lack certain standards as of today. Tech giants like Google and Microsoft are pushing for these standards, to help keep a check on the vulnerability of their cloud apps.
Multiple SBOMs are produced at different levels of the software stack. The various levels needed to have a complete audit trail of the entire supply chain and to create a single relic (microservice, binary, library, etc) are shown in Figure 1.
The challenges
SBOMs may be critical to our overall security practices, but they are not perfect.
Today hackers can introduce criminalised antiquities into a software system. A standard SBOM to compile source code is still unavailable, and the tools used to generate SBOMs also have challenges. SBOM-generating files such as Rust’s cargo.lock and NPM’s apt-cache can be hacked. As a result, SBOM reports can be easily manipulated and edited to deceive their creators.
Today’s SBOMs are full of inconsistencies, bugs and incomplete data. Improper analysis of potentially powerful source codes may result in a weak cyber security system. As more workloads are added to the cloud, understanding and auditing SBOMs becomes critical. Efficient SBOM-generating tools are required in such cases.
The speed at which the cloud changes is a great challenge for SBOMs. If SBOMs change minute to minute with the cloud configurations, they might produce too much information, which may hamper usage by customers. The cloud SBOMs must be able to manage this torrent of data.
Building secure software by generating SBOMs
Generating a software bill of materials (SBOM) is part of your DevOps process.
Fortunately, there are a number of tools that can help create SBOMs. The steps involved in generating SBOMs are as follows:
- Choose your SBOM generation tool. As an example, let’s use Syft.
Download and install Syft. - Determine the SBOM output format you need.
- Run Syft against the desired source: syft
<source> -o<format>
SBOM generators are often specific to a particular ecosystem such as Python or Go. Some are capable of generating SBOMs for a number of different ecosystems and environments. Some of the more popular SBOM tools are:
- Syft by Anchore
- Tern
- Kubernetes BOM tool
- spdx-sbom-generator
- Buildx and BuildKit of Docker
The primary focus of any SBOM solution should be on open source code. Open source components comprise 60-80 per cent of today’s applications, and their use is expanding exponentially. Unfortunately, open source is also attractive to cyber attackers. In 2020, open source codes were host to almost 10,000 cyber attacks.
Organisations are unable to accurately record and summarise all the software they produce, consume and operate. Without visibility, software supply chains are vulnerable to security and compliance risks. SBOMs enhance visibility in the software supply chain. Companies can use SBOMs to better understand the risk of the new software before acquiring it.
