#HowTo: Create and Maintain SBOMs

Written by

In September 2022, the White House published a new Executive Order requiring software vendors supplying the US government to provide a Software Bill of Materials (SBOM). The objective is to ensure that all companies in the supply chain providing the US government with software and services are sufficiently protected against cyber-attacks.

The context behind this significant move is that software supply-chain security has been an increasing concern due to numerous high-profile attacks. At the same time, the role of the software supply chain in the growing cloud-native application development ecosystem has added to the risks organizations face.

But, as companies strive to compete and create differentiated digital offerings, cloud-native development offers an opportunity to push new offerings and features to market faster. However, to move quickly and stay secure, many companies must significantly improve the security of their software supply chains.

So, what’s being done to address these challenges and growing regulatory requirements? Part of the challenge is that there is already a range of official guides, government guidance and innumerable headlines focusing on the software supply chain. With that in mind, organizations must focus on finding clarity to prevent compliance guidelines from slowing down their business.

Why Are SBOMs Key to Supply Chain Security?

To answer this question, it’s useful to look back at legacy approaches. Traditionally, many organizations would develop applications in-house using their own software. Among the various advantages this approach offered was that it enabled developers and security teams to design and control the entire codebase for each application. Today, however, this approach is far less suited to organizations that need to roll out frequent software updates and enhancements.

In contrast, the use of open-source software supports rapid development and release cycles, providing teams with ready-made components they can integrate into their application stack. Not only does this help increase the pace of software development, but as the open-source ecosystem grows, more components can be brought into today’s demanding development and release schedules.

In these circumstances, an SBOM enables organizations to identify and track all of these third-party components, open-source included. This delivers a range of benefits, from ensuring compliance with licensing requirements and ensuring that vulnerable open-source components aren’t used, to keeping track of the status of critical updates and patches.

SBOM Best Practices

For any software development team creating an SBOM, it remains the responsibility of their organization to maintain and update it as application components evolve or are amended. This includes everything from new features and code updates to bug fixes, among a myriad of other possibilities. Given these changes can conceivably be implemented at any time and across multiple teams, they should be tracked in real-time. Failure to do so means the SBOM is highly likely to become outdated.

The next best practice consideration focuses on ensuring data integrity. Organizations creating and maintaining SBOMs should be able to audit everything it contains, such as all version numbers and licences. To further ensure its integrity, all the information in an SBOM must come from trusted sources and be verifiable by a third party.

An effective SBOM should also identify potential issues that could impact users. For example, it should clearly show the current state of the application and what steps should be taken to fully secure it. The information should include details, such as the existing files and components in active use and if any security or other issues need attention or monitoring. For example, these could include restrictive open-source licences, known vulnerabilities, bugs or limitations in software components.

In addition, organizations must clearly identify SBOM documents, primarily because the same version of a piece of software can have multiple SBOMs that apply to it. For instance, a new version of an SBOM can be issued that corrects an error or provides an alert for new vulnerabilities that were unknown when the previous version was released. As a result, it should be crystal clear which document represents the latest version of the SBOM to ensure users have complete, accurate and up-to-date information.

As cyber-attacks become more frequent, software supply-chain security is becoming a top priority for organizations everywhere. As a result, the SBOM is a useful tool that enables companies to identify and track software components and keep users fully updated about identifying and eliminating potential security issues. By implementing a best practice approach for creating and maintaining SBOMs, organizations can stay secure and competitive in the ever-changing digital market.

What’s hot on Infosecurity Magazine?