On the 12th of May 2021, The White House released an Executive Order (EO) that outlined the guidelines for improving the cybersecurity of the United States. After many high-profile cybersecurity breaches related to exploits within widely used open source software, the Federal Government moved to learn from past exploits and create a more comprehensive security strategy.
As an ongoing part of this effort, the Biden Administration is working towards creating a more stringent policy that helps to increase the detection, assessment, and remediation of cyber incidents. One core feature of the EO was the necessity for software vendors providing software to the U.S. government to issue a Software Bill of Materials (SBOM) with the sale of their solutions. The message from the administration was for the public sector to follow suit.
60 days after the EO was released, The White House tasked the National Telecommunications and Information Administration to publish the minimum elements for an SBOM, which have since been created. With these recent developments, software distributors and developers are beginning to provide SBOMs with the sale of their products.
I’m going to outline for you what you need to know about SBOMs, touching on what they are, how they fit into your business, why they’re necessary to manage the software supply chain, and some challenges you may run into.
What is an SBOM?
For many years, SBOM has been used as a generalized term, fairly commonly interchanged with OSSBOM (Open Source SBOM). While many believe that SBOM simply pertains to the open-source software that a platform uses, this is not accurate. In fact, an SBOM is actually the complete documentation of a software bill of materials, including all connected components that the software contains.
Since the EO, the definition of SBOM has become unified, with The White House defining it as:
“The term “Software Bill of Materials” or “SBOM” is a formal, queryable record containing the details and relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product.”
After this definition, an SBOM has become “analogous to the list of ingredients on food packaging,” with this now being a core part of how companies can understand the software supply chain and manage risk to their organization.
Another core part of this definition is the fact that SBOMs should be machine-readable, as automation makes the process of moving through this extensive document much more manageable. Due to the increasingly complex web of international software licensing and transfer, manual documentation of an SBOM is an extremely demanding task, with automation being the most reasonable path forward.
Why do I need an SBOM?
With both the U.S. and the U.K. now both requiring companies that work with their government-related businesses to supply an SBOM, there has been a reaction moving steadily up the software supply chain. For example, it is becoming much more prominent for customers to ask their software providers for an SBOM.
Alongside aligning with the current movement that shows us more and more regulatory requirements around SBOMs, your software company should supply an SBOM as they:
- Help to identify security vulnerabilities and license compliance issues
- Are essential in managing the supply chain
- Improve software security
Additionally, with the mass movement to this form of more stringent documentation, companies that cannot answer questions about where their software comes from, what open source providers they’re relying on, or how their code is checked and verified, are becoming outliers in the industry.
When a customer approaches software companies that are unable to answer SBOM-related questions, or provide one in general, they may come across as unprofessional. Additionally, this cuts to the core of customer-developer trust, with developers that cannot verify their own software instantly demonstrating that their platforms may not be safe during this era of increased security threats.
If you want to ensure your business remains as competitive as possible, then you need to understand all the related processes of your own software, providing an SBOM that covers all your components as well as any open-source elements that you rely on.
Someone down the line will require an SBOM, meaning their requests will end up on your to-do pile anyway.
What are the challenges associated with SBOMs?
SBOM discussions are everywhere and are often talked about as if they are a silver bullet in the industry. While they can contain all the information that vendors and customers could need, there are often a range of challenges with SBOMs that could prevent them from being as complete, accurate, and wholly useful.
Typically, there are a few fundamental challenges that SBOMs face that pose a problem for their adaption into the industry:
- Consistency – Although the White House has now set a specific definition for SBOMs in their EO, the exact specification of what distinct companies include in this still differs. With this, the accuracy and consistency across SBOMs issued by different companies can generate blind spots or missing information. Additionally, many companies are still using manual strategies to craft their SBOMs, leading to critical data and component information being left out. Provenance and ongoing management certainly become too complex, especially with continued security threats and vulnerabilities such as Log4Shell.
- Updating – When there’s a new software release, they must produce and distribute a new SBOM. For platforms that are regularly updating, this scales the physical demand of producing an SBOM, with companies that are not using the correct tools having to take large amounts of time to produce their SBOM. This is a further demonstration that SBOMs need to be produced automatically, or else the additional work is simply too much to maintain.
- Connection – What is shared or produced for the sake of transparency becomes an issue with downstream and upstream partners in the software supply chain, with the possibility that the SBOM is incomplete and inaccurate. Insert your customer in the process who is potentially not getting the full story of what’s in the code you’re passing on to them. When lacking certain details or knowledge areas, an SBOM becomes ineffective and could lead to potential exploits.
Although frustrating, these issues are not insurmountable. Especially with the automation of SBOM production, these problems can be remedied, allowing the software supply chain to continue uninterrupted while integrating this advanced level of transparency.
Many of these challenges have proposed solutions, with The Software Supply Chain Open Source Exchange addressing these in a panel discussion.
What Are the Best Practices for Creating a SBOM?
While the best practices for creating an SBOM are always changing, with different organizations using distinct practices, there are some general conditions that are worth incorporating into your SBOM process.
Considering that SBOMs are becoming increasingly important within the world of business, IT, and cybersecurity as a whole, it’s vital that you regard the following potential practices:
- Frequent updates
- Establish an Open Source Review Board (OSPO)
- Integration with threat intelligence
Let’s break these down further.
The creation of an SBOM, especially for large-scale enterprise organizations that create and distribute more than one software application with robust release schedules, is no easy task. While it is not impossible to create an SBOM manually, it is considerably more difficult than using a tool that helps automate SBOM delivery.
Typically, when businesses leave SBOM generation as a task for software development teams, developers may put the task off until they have a free schedule. After all, in today’s environment, software engineers are heads down creating new solutions and innovating in order to get to market faster and stay competitive.
Instead of relying on manual work to create an SBOM, the movement to automation using a software composition analysis solution such as Code Insight will ensure that SBOMs are kept up to date with ease.
Even with complete automation, SBOMs still require work. Due to this, there will always be an amount of time that elapses between different versions of an SBOM refresh. Not every company should, or will have the means to, update their SBOMs on a daily basis. This is a fairly unrealistic expectation.
Depending on the organization itself, the frequency with which you should update your SBOM will vary. Variables include release frequency, number of software applications, resource availability, knowledge of SBOM production, company and/or team size, and whether or not strategic policies are in place to govern open-source and third-party component use.
Regardless of the circumstances, one of the best ways to estimate how often you should update your SBOM is to update your software inventory whenever it makes sense; this could be monthly or whenever you release new code.
Establish an OSPO
If your organization is using open-source components in your deployments, then it’s always a good idea to develop and establish an Open Source Program Office (OSPO). An OSPO will allow an organization to coordinate its open-source program activity across all of their applications. When established and configured correctly, the OSPO then becomes a central location that holds all of the open-source activity.
Additionally, the OSPO becomes a port that allows for your organization to engage with the open-source community as a whole, even taking on further technical functions. For example, the OSPO could then manage the GitHub enterprise account, making this available for all stakeholders.
To learn more about OSPOs, this webinar with speakers from Revenera, Bank of America, and Hewlett Packard Enterprise is a great resource for building a successful
Integration with Threat Intelligence
When creating an SBOM it’s always a good idea to integrate with any security operations areas that may be relevant to its content. Threat intelligence is one of the most important security operation areas that you should cover, helping your SBOM to contain information about how it picks up on threats.
This will ensure that whenever a team needs to handle threat intel, they are able to reference your organization’s SBOM to rapidly work through the software used and whether any of it will pose a risk. If there is a match between a competent under threat and those who are documented within your SBOM, then a threat response will be triggered, saving lots of time.
As a unified document that details the composition of an organization’s software, the SBOM allows for complete software supply chain management and maintenance. While open-source and third-party components allow developers to rapidly create, they also come with a range of potential security issues. That’s where the SBOM comes in, providing a methodical document that demonstrates compliance, details components, and ensures that any potential risks are clearly identified and remediated.
Alongside benefiting the organization itself, SBOMs are vital in improving relationships with partners, customers, and the open-source community as a whole. As SBOMs have evolved beyond just a list of software components, their up-to-date information provides a complete picture of software.
This new generation of automatically generated, detailed SBOMs ensure that developers can derive maximum value from open-source code, mitigate the most common security risks, and create levels of compliance documentation when disturbing their software.