Earlier this year, the White House issued an Executive Order on cybersecurity that set out to establish new security requirements for software vendors that sell software to the U.S. government. One such requirement is that vendors provide a software bill of materials (SBOM) as part of the federal procurement process.
In this blog, we break down what a software bill of materials is, why it is important, and provide SBOM examples.
What Is a Software Bill of Materials?
A software bill of materials (SBoM) is essentially a list of components needed in the build of a software project.
Also known as a Bill of Information or Bill of IP, the concept of a bill of materials has been around for many decades, primarily in the world of manufacturing. Usage in the software world has seen steady growth as a means to help hardware and software teams collaborate better.
One area where in particular that has seen an increase in SBoMs is the systems market, where hardware and software teams need to work more closely together. As semiconductor design has evolved, there has been an increased focus on IP reuse and the need to integrate IP components. Hardware teams have been keeping track of IPs used as BoMs for some time now, and it seems like a natural evolution to adopt the methodologies employed to the components used in software design.
Back to topWhy Is a Software Bill of Materials Needed?
As mentioned earlier in this blog, if you are a software vendor that provides your product to the U.S. government, you will soon be required to provide a SBoM with your product.
But beyond the case of government use, the benefits of using a BoM are abundantly clear. In the past, it was acceptable for hardware teams to carry out their designs first, and the software teams would follow. However, these days it is essential that these two teams work in parallel (even if they operate in separate silos).
This is where the utility of a Bill of Materials comes into play. Think of both software and hardware as being made up of components or materials. With the creation of a BoM, there becomes a standard reference that links together the software and hardware teams, allowing them to work together in harmony.
Learn How to Better Plan and Execute Software Development in Our Webinar
Establishing a Software Bill of Materials is one of the most essential steps in building a software product and getting it to market. Watch our recent webinar for tips on making an effective SBoM and a look at next steps.
A BoM makes it easier for either team to pass data to the entire community without having to make an effort to communicate directly. The BoM records data of what version of the software the hardware team should be supporting, and vice versa.
If this universal layer of communication was removed, the hardware team would need to find a way to communicate changes to the software team, and to whom in particular. While this is not a monumental task with a small team, it can become hard to manage manually with a large, distributed team and even more complicated if there are external contributors.
A BoM eliminates the need for manual intervention, allowing both teams to see when a change is made, understand its dependencies, and then make fundamental changes of their own if needed. In addition, it allows changes to be made earlier in the development process, which aids in keeping projects on track, catching errors early, avoiding breaks in hardware or software, and cutting down on rework later in the process.
SBoM Example
One SBoM example that sticks out, which really illustrates its need, is a large organization that was recently effected by their lack of this document. This organization, which we discussed in another blog about why traceability is important, had a family of hardware platforms that had slight differences between each item.
While a single version of software worked across the platform at first, subsequent patches to the software became incompatible across other items in the hardware family. Without the use of a SBoM, this error was not discovered until after the release of the patch, which led to numerous failures in the field.
Back to topImportant Traits of SBoMs
One essential trait of a SBoM is that it needs to be a living document which reflects the current state at any time. If there are any changes, whether it be on the hardware or software side, the BoM should change with it. This real-time data is critical for both hardware and software teams.
This living document should incorporate everything associated with the project; not just the design files, but also the metadata that capture the linkages between hardware and software components. I refer to the metadata as the six Ws: the Who, What, Where, When, Why, and hoW of the IP. This would include, but is not limited to:
- Who created the IP.
- Who else is using the IP.
- What version of the IP is current.
- When the IP was introduced into the design (and what version).
A bill of materials typically lives within a version control system, like Helix Core, which creates a single source of truth. This centralized view provides visibility into every action in the project from all contributors, regardless of what tools or system they are using.
A BoM also needs scalability for when projects or organizations grow. In addition, it needs to be tied into requirements and testing processes — especially in applications where functional safety is a requirement. When the system BoM is tied to requirements and testing results, it simplifies, or even automates the process of showing an evidence trail from requirements, through design, to verification.
Back to topHow Methodics IPLM Helps to Create SBoMs
Semiconductor design teams have been using Methodics IPLM for years now to manage the lifecycle of their IP and provided traceability into where and how that IP is being used.
A core benefit of Methodics IPLM is the ability to keep track of the IP BoM for the entire design, with all the latest information. The methodology associated with using Methodics IPLM is easily extendable in the world of software design and managing the components that make up a software project.
Already, many Methodics IPLM customers have begun to adopt Methodics IPLM for their software projects. Software teams have the access to the same benefits that the traceable platform provides, including the automatic creation and management of the SBoM for these software projects.
That’s just one of the reasons why Methodics IPLM is trusted by 9 of the 10 top semiconductor companies.
Connect with Perforce to learn about how Methodics IPLM can help you create a Software Bill of Materials and streamline your workflow.
LEARN MORE ABOUT METHODICS IPLM
Related Reading
Explore additional BoM content: