A software bill of materials (SBOM) is a list of ingredients that make up software components. Therefore, it’s sometimes called a software ingredient list. Although the definition of SBOM seems simple, in practice, it’s used in a much broader context.
You would use an SBOM to catalog what your project needs in order to complete it and ensure compatibility between the various application and communication tools you need.
The SBOM structure is not complex, it is basically a text file with an enriched list of used software components of a given software package.
A software bill of materials may contain any of the following: a list of software components and their dependencies, a list of the external libraries used by components, a list of software licenses required for each component, and others.
Software bundles are a machine-readable inventory of software components and their dependencies. This includes information about their components, as well as their hierarchical relationship with one another. Furthermore, ensure that the inventories are comprehensive and complete. In case they are not complete or there are gaps (unknown or missing components) it must be stated explicitly. SBOMs may be generated for any combination of open-source and proprietary software.
Best practices for a comprehensive SBOM policy should also include baseline attributes with the ability to uniquely identify individual components in a standard data format. The most efficient approach to work with a pervasive SBOM policy is to have them generated as a byproduct of a modern development CI/CD process. For legacy development environments or for externally developed software (for example with no access to source code), there are a few standard formats for SBOM.
In today’s ever more complex development environments it is imperative that SBOMs can be shared frictionlessly between teams and organizations as a fundamental part of software management transparency. This transparency model is supported by the ISO association through its OpenChain Specification, and it is part of an effort to improve security in the digital industry.
THE IMPORTANCE OF SBOM
The following statement by Alan Friedman, a senior advisor and strategist at CISA and the US federal government’s SBOM czar, shows how important the movement towards software quality and transparency is:
“The next phase of the initiative is ready to begin, with more vendors expected to soon start offering a detailed peek at the components used inside their software to federal customers.
But while SBOM will need time to fully mature, the important thing is to get started with what’s ready now and build from here.
To go from security [where software] is a black box to think about the broader supply chain — that takes a while, especially in the federal government, but it is a priority.”
Why is there such a sudden and urgent demand for SBOM?
For one, in 2021 there were many high-profile security breaches, including Codecov and Kaseya. The most recent big bang was Apache Log4J which opened the doors for countless breaches and caused billions of dollars in damage. President Biden has issued a new Executive Order (EO) for the federal government stipulating that agencies, departments and contractors who want to do business with the government must follow strict guidelines for how they safeguard software.
These guidelines are in response to recent supply chain attacks which resulted in official software being compromised and used as a weapon.
One of the proposals was for legislation to require SBOMs in order to ensure the safety and integrity of software used by federal government agencies.
While the Executive Order was designed for those working with the government, it will likely become a standard for quality control of software in general.
SBOM SOFTWARE EXPLAINED – WHAT ARE THE BENEFITS?
The benefits and use cases for SBOMs are numerous; vary across stakeholders who produce, choose, and operate software; and are amplified when combined. Benefits include reducing cost, security risk, license risk, and compliance risk.
Use cases for Software Bill of Materials include better software development, supply chain management, vulnerability management, asset management, and high assurance processes.
Beyond complying with the recent Executive Order related to cybersecurity, actively using an auditable SBOM that uses zero-trust technologies is in the best interests of the software supply chain.
Today, developers and organizations are reusing an increasing number of both open-source and proprietary components in their applications. This complexity has been a cause for alarm for some time now since identifying each software component is crucial to understand if there may be a vulnerability in it.
This is because “one bad apple can spoil the bunch”, as evidenced by the high-profile hacking of SolarWinds. In this sense, SBOMs is an invaluable tool, as they allow an audit of licenses, libraries, modules, applied patches, and other components for weaknesses. However, for such an audit to reliably trace the components used to build the software, the SBOM must have certain attributes.
- Unique identities for each software component
- Separate identities (independent of those used internally in the organization) to identify each machine and user involved in the development process
- Timestamps to facilitate traceability of each change or component incorporation
Additionally, from a security point of view, a key element for the reliability of the SBOM is to prevent “unauthorized changes” on it. And the most effective way to do this is by using an immutable ledger that records a history of when each change was made.
Once the reliability of SBOM is assured, DevSecOps teams can use it as part of their threat scanning toolbox and therefore improve software security.
SBOM STANDARDS “SPDX” AND “CYCLONEDX” EXPLAINED
Having established the importance of SBOMs, it remains to discuss how to implement them. A decade ago, developers did not have the infrastructure to facilitate the analysis of software components or the collaboration tools that we have today.
The creation of specifications led to the development of the two most outstanding specifications: the Software Package Data Exchange (SPDX) backed by the Linux Foundation and the CycloneDX specification managed by the CycloneDX Core working group.
Sharing SBOM data across the supply chain will involve both technology platforms and predictable data formats in order to achieve maximum efficiency. Software ecosystems are an important factor of any platform, and the diversity of these ecosystems can impact everything about usage. There’s no one size fits all solution.
One way to make SBOM processes work better is by taking existing approaches and methods and applying them. This will allow for interoperability between vendors and minimizes the need for new tools. It will also simplify the processes required for thorough software supply chain management.
| SPDX | https://spdx.github.io/spdx-spec | https://tiny.cc/SPDX |
|---|---|---|
| CycloneDX | https://cyclonedx.org | https://tiny.cc/CycloneDX |
Codenotary Trustcenter(™) supports the generation of these SBOM standard files and also the import of existing ones. That gives the user the ability to import SBOMs from a 3rd party supplier or vendor.
SPDX STANDARD
SPDX provides a standard language that can be used to communicate key components such as licenses, copyrights, and security information related to the various software components. Moreover, thanks to this specification, developers and organizations can associate SPDX documents to a specific software component or group of components. For this, development organizations can use different formats or even a just code snippet.
The enormous flexibility of the SPDX specification for sharing critical software component information recently earned it the status of an internationally recognized standard for SBOM, which demonstrates its undeniable relevance.
CYCLONEDX SPECIFICATION
The CycloneDX specification defines itself as “a lightweight software bill of materials (SBOM) standard designed for use in application security contexts and supply chain component analysis“.
In this sense, while the SPDX standard provides a format that facilitates the communication of third-party and open-source software components, CycloneDX provides the tools to analyze the SBOM for potential vulnerabilities. In other words, the CycloneDX specification addresses the safety aspect of SBOM components – undoubtedly crucial for DevSecOps teams.
WHAT SHOULD GO INTO A SOFTWARE BILL OF MATERIALS?
A Software Bill of Materials (SBOM) is a list of all the software components found in a given codebase or used in a given software build. It includes information on the open source components and license type, as well as whether there are any known vulnerabilities for those specific items.
OPEN SOURCE COMPONENTS
Do your developers use open source components in your code? Open source helps shorten development time, increase execution speed, and deliver more profitably to your customers. Recent reports of global code scanning show that 97% of company codebases contain open source software.
Although open source usage isn’t any more or less risky than proprietary code, it is risky for your organization to neglect security measures. Few companies understand the open source they are using and so it is important they have a reliable Bill of Materials that includes any open-source components. A complete Source Code And Operating Model list all the open source components that your application uses and the different licenses, versions, and patch status.
OPEN SOURCE LICENSES
Make sure that you have a proper understanding of the open source licenses your applications are using. There are both permissive, or viral variants depending on whether the license is one-off or repurposed from an existing open source license.
Businesses need to take care if they don’t want to be at risk of being sued for copyright infringement or having their intellectual property compromised. One of the most overlooked and therefore often in conflict with is the GNU General Public License.
When there are license conflicts existing it impacts mergers and acquisitions, causes vendor disputes, and distribution problems. An SBOM is a great way to help you work out the open source licenses that govern the components you use. It will also help you assess your legal risks.
OPEN SOURCE VERSIONS
Do you know if the open source libraries your code relies on are maintained? As the use of open source code becomes more prevalent, it is important to be aware of operational risks that can occur. For instance, teams may not be able to receive timely updates through a maintained developer community or they may face problems with outdated components which are no longer supported by developers.
Aside from poor code quality, reliability, and maintainability issues, operational risk can also lead to security risks. If there are no developers fixing bugs, then this could also go as far as them not detecting and fixing any security vulnerabilities. When we checked your code, we found that it relies on outdated components of open-source software. This can lead to security risks and an inefficient code update process which leads us to the SBOM.
OPEN SOURCE VULNERABILITIES
Last but not least, do you know the components used in your software and their current risk based on existing vulnerabilities? A common mistake in handling vulnerabilities is to scan source code as part of the build process or as part of the deployment process.
When looking at the software lifecycle, new vulnerabilities can be detected every minute, and knowing where these components are being used and where they are currently deployed and running is key. Once scanned doesn’t mean it’s secure. Continuous scanning including an updated SBOM is important.
Log4j taught us another lesson that highlighted the importance of having an SBOM. Once the software vulnerability was disclosed, it was a race to implement patches before malicious actors could exploit them. To quickly patch your systems or block exploits you first need to know where these vulnerabilities exist.
Having a software Bill of Materials will allow you to quickly assess the risks in your codebase and mitigate them as needed.
IS THERE A NEED FOR SBOM SOFTWARE SOLUTIONS
Short answer – absolutely yes!
No developer, no software maintainer, and no DevOps engineer want to manually collect the dependencies and produce SBOM documents. It needs to be fully automated within the software build pipeline, and the software deployment, and there needs to be a proactive check of where it’s currently running.
NOT ALL SBOMs ARE THE SAME
STATIC SBOM VS DYNAMIC SBOM
When a static SBOM is mentioned, it basically means that SBOM file is produced for each of the software builds and stored somewhere in a file server or git repository. Over time you have a decent collection of hundreds of thousands of SBOM files that are neither indexed nor updated. It’s like an archive for software dependencies that someone can read through whenever needed.
It also means that finding the right component (even just the existence of one) can take days or weeks or months.
The other important thing is, that many build processes are using the latest version of dependencies. Therefore a deployment with an updated version of a software stack has completely different SBOM information. That leads to absolute chaos in finding the right dependency version that is currently running and used.
DYNAMIC SBOM
That is where dynamic SBOMs come into play. They are automatically updated to the latest SBOM information and provide extensive search capabilities as part of an SBOM database. That allows for immediate findings of a specific dependency version like the log4j case.
But solutions like Codenotary Trustcenter update the SBOM information also based on the runtime (like Docker or Kubernetes). That way the user cannot just answer if some component is used but also where!
Relying on static SBOMs imposes a real danger to your software security.
- Relying on outdated data
- Slowing down your search for real threats because of the noise
DIFFERENT TOOLS AND DIFFERENT SBOMS
While every software and tool out there claims to be the best SBOM generator, you should carefully check the outcome of the results.
These should also not be measured by the pure count of dependencies as many tools show duplicated packages.
That can cause a lot of confusion and also creates useless overhead. Overhead never helps to scale, so keeping overhead for 1000 or 10000 projects can cause real scalability problems.
Example: The project consists of four different go applications that share 20 of the dependencies (components). The correct count for the whole application would be all unique dependencies based on hash, name, and version. Let’s say 100. As 20 of the dependencies are counted for all 4 applications in the same project, some tools show 160 instead of the 100 unique dependencies.
CONCLUSION
There is no doubt that SBOMs should be requested from your software vendors and that you should consider creating SBOMs along with your own developed software. It’s all about the proper storage of the SBOMs, so you can be sure it’s recent, searchable and trustworthy because untampered.
Make sure to choose the SBOM standard that makes the most sense for you and stick to that for all of the software developed or used in your infrastructure. When the next Log4j moment comes, you should be able to pinpoint the existence and the location of the component in question to mitigate risk as good as possible.
Eventually, you need #actionableSBOM and Codenotary supports you at every stage of it.
