A software bill of materials (SBOM) itemises the components of software and helps companies secure software products in the event a vulnerability is discovered. Let’s see how it does that.
The world runs on software. As vulnerabilities related to software grow, so does the need to curtail these risks. Fortunately, minimising security risks related to software doesn’t need to slow the pace of development or put deadlines in jeopardy. Fundamental to organisation-wide security efforts are software developers, who must be aware of—and secure—all code they use, including open source.
As found in recent research by Revenera about the software supply chain, 61 per cent of scanned codebase files are attributed to open source components, up 6 per cent over the past year. Despite the prevalence of open source software (OSS), awareness of how open source is being used is surprisingly low. Only 6 per cent of the issues uncovered during audits were disclosed prior to the audit start, indicating that organisations need to better track the open source components they’re using and the risks they carry.
Minimising security risks isn’t possible without a complete and accurate inventory of components, licences, and vulnerabilities. A software bill of materials (SBOM) itemises this information, providing clarity into the components and helping companies secure software products when a vulnerability is discovered. SBOMs enable software companies to demonstrate transparency and build trust in the software they deliver. This is all part of good quality assurance (QA) and can give software companies a competitive edge.
As the roster of cyberattacks grows and as cybersecurity regulations increase, SBOMs are a must for all parties in the software supply chain. Here’s a look at what SBOMs are and how they can help ensure that software is secure by design.
Why are SBOMs in the spotlight?
The regulatory environment is increasingly emphasising the use of SBOMs, as they help indicate the quality of the software. This comes in large part from the expanding need to manage security and licence compliance, with the goal of protecting against the risks of cyberattacks.
In the United States, the ‘Executive Order on Improving the Nation’s Cybersecurity’ issued on May 12, 2021, raised awareness of the principle of and need for SBOMs. This executive order drew on wording from the National Telecommunications and Information Administration (NTIA) and its Software Component Transparency project, which have worked to move SBOMs forward. These initiatives made clear the need for anyone selling software to the US government to deliver an SBOM.
This also triggered heightened awareness within the private sector and within regulated industries. For example, some companies, like Scania (part of the Volkswagen Group), now only accept software from their suppliers if an SBOM is provided.
Previously, the European Union had guidance for things like cloud solutions, Internet of Things (IoT), inventory of third party components and libraries, and SBOMs. The executive order raised awareness globally about SBOMs and how they can add value by meeting the requirements of vulnerability disclosure programs. Software companies in India, Europe, or anywhere else are likely selling their software or product to a US customer or the US government and therefore must be aware of the move towards SBOM usage.
A March 21, 2022, fact sheet from the Biden-Harris Administration highlighted the need for companies to strengthen their cybersecurity initiatives. The need for this comes not only from the growing number of cyberattacks and exploited vulnerabilities (such as Log4j and Spring4Shell), but from the risk of Russia’s potential engagement in “malicious cyber activity.” Vulnerabilities will continue. It’s a matter of when, not if.
A closer look at SBOMs
When an airplane or automobile is built, every component is tracked. An inventory defines exactly which parts, big or small, were used in the manufacturing process. Should a part fail or need to be recalled, it’s clear which vehicle is impacted.
That same approach of tracking components applies to the safe development of software. An SBOM provides a list of the ingredients in your software. It inventories all the software components and dependencies in an application. Minimum elements include data fields, such as name, version, and licence. Predominantly open source, an SBOM also includes all inbound third-party software that’s used.
The immense volume of data in an SBOM means that it must be in a machine-consumable format. Relying on a human processor or manual approach isn’t viable. The format must be one that both the provider and the consumer of the SBOM can programmatically communicate and interpret, while keeping pace with rapid development cycles.
Today, the software industry is coming together to identify what format that inventory should take, working towards a consistent presentation of SBOMs and for automation support. A standard format will make it easier for software companies and software consumers to build, use, and share the SBOM. Noteworthy industry initiatives include:
- CycloneDX: With origins in the Open Web Application Security Project (OWASP) community, CycloneDX is a “lightweight” standard for SBOMs, “designed for use in application security contexts and supply chain component analysis.”
- OpenChain ISO/IEC 5230: This is the international standard for open source licence compliance. This specification can be used to strengthen varied business use cases throughout the software supply chain, such as procurement and outsourcing activities, or due diligence for mergers and acquisitions (M&A) activity.
- SPDX: The Software Package Data Exchange (SPDX) is an international open standard (ISO/IEC 5962:2021) for “communicating software bills of material information, including components, licence copyrights, and security references.”
- SWID: Software identification (SWID) tags (defined by the ISO/IEC 19770-2:2015 standard) contain identifying information about the specific release of a software product, helping organisations track the software that’s installed on devices.
How SBOMs protect the software supply chain
Nearly two-thirds (62 per cent) of organisations have been impacted by software supply chain attacks in the past 12 months, as found in the Anchore 2022 Software Supply Chain Security Report. This means that software companies are both subject to and passing along vulnerabilities in their code, highlighting the need to identify all components in use.
Developers must know the origin of the components they’re using from upstream within the software supply chain. They must also identify components being passed along further downstream in the software supply chain, such as through a software development kit (SDK), operating system, or other modules that customers use to build applications.
By identifying components and their associated licences, an SBOM provides a clear format to track and communicate this information. Additionally, in the event that one of the components has a vulnerability, having this information immediately at hand will help facilitate rapid remediation. When this information isn’t readily available, development teams can be left scrambling to identify whether or not they’re impacted by a vulnerable component (as was commonly the case with Log4j), wasting valuable time that could better be used for fixing the issue.
SBOMs as part of software composition analysis
The creation of accurate, current SBOMs happens as part of a comprehensive software composition analysis (SCA) program. SCA is the process of automating visibility into the use of open source software and other third-party content, supporting application security, risk management, and licence compliance.
SCA can discover and track all OSS and the associated licences, and then create an SBOM based on those findings. It can also help create and enforce policies, monitor for security vulnerabilities, and integrate open source code scans into the build environment.
The automation that’s inherent in SCA is critical for staying up-to-speed with dynamic development environments. Static audits simply can’t keep up with the pace, as new vulnerabilities occur daily. SCA’s automated tracking helps developers stay focused on what they do best: creating great code.
Best practices for creating and maintaining an SBOM
Protecting the use of open source software is aided by a “shift-left” approach, in which compliance and security risks are addressed early and often as part of the development process. This is fundamental to the ability to continue developing software, without delaying releases.
An open source program office (OSPO) can be instrumental in establishing policies about the use of open source. The OSPO can also centralise efforts to identify and mitigate risks related to open source, including managing the creation and maintenance of an SBOM.
SBOM standards (such as SPDX, identified above) can help clarify what should be in an SBOM. Generally, an SBOM should include:
- Software component and versions
- Vulnerabilities
- Licences
- Third-party notices
- Usage information
- Alerts and notifications
- Tasks
The software bill of materials life cycle includes creating (and updating) the SBOM, refining it, reviewing it, remediation (in the case of discovered vulnerabilities, based on their severity and on organisational policy), and monitoring for ongoing and frequent updates. Automation, as supported by SCA, ensures the speed necessary for ongoing review of code, delivering updates with the frequency needed to keep pace with contemporary development processes.
Making software secure by design
Rather than looking for vulnerabilities after an issue is revealed, tracking and managing security risks can yield safer products—with fewer headaches. Implementing SCA and a software bill of materials into software development practices will enable automated continuous management without disrupting software development and releases.
When developers look for open source code to deliver a requested functionality or to address a technical challenge, they should evaluate whether that code fits within the best security practices. Clear security parameters can help avoid using code that’s riddled with vulnerabilities. And a well-maintained SBOM can help quickly identify and remediate any security flaws that end up in the code.
