The time when manufacturing companies solely focused on building mechanical products is gone forever. These days, every product is a combination of mechanical, electrical, electronics and software.
For products containing software, some of these products’ software can be embedded while another portion of the software can be hosted in the cloud and connected with the products.
You can imagine the level of complexity the companies need to go through to ensure all pieces of the components including software are aligned. In my earlier article, I wrote about the importance of Multidisciplinary BOM and how OpenBOM enables engineers working with multiple environments in a much more efficient way.
Today, I want to focus on software Bill of Materials and why the priority of work on software BOM is extremely high these days. Unless you’ve been living under a rock for the last few years, I’m sure you’re aware of extreme sensitivity to cybersecurity and the need to properly manage the software components inside of products.
Software BOM – Why Now?
CSO Magazine article Government-mandated SBOMs to throw light on software supply chain security can shed light on how the government is planning to mandate manufacturers to provide a software bill of materials to help ensure the integrity of an application’s components. Here is the passage:
An SBOM is “a dependency rack,” Allan Friedman, lead on the government’s SBOM activities and director of cybersecurity initiatives at NTIA, said at the NIST workshop. “At its core, it’s not that complicated. It’s saying, ‘hey, this software that I have. What’s in it, and what in turn is in [the components that make up the software]?'”
An SBOM is effectively an ingredient list or a nested inventory, a “formal record containing the details and supply chain relationships of various components used in building software,” the EO states. The EO requires NTIA to produce three proposed minimum elements that should go into any SBOM: (1) Data fields (such as supplier name, component name, version of the component, and more); (2) Operational considerations (such as frequency of SBOM generation, depth of the dependency tree, access to SBOM data, and more); (3) Support for automation (making sure the data can be produced at scale and consumed at scale using three different data formats already standardized, including three leading file formats known as SPDX, CycloneDX, and SWID).
How to Replicate Manufacturing Companies BOM Experience to SBOM?
The same article speaks on the need for companies to adopt the same methods of BOM management that were cultivated in manufacturing companies for decades.
Bills of material are not new. Although a relatively new concept in cybersecurity, bills of material have been part of other industries’ requirements for decades. American engineer, innovator, and management specialist Edward Deming pioneered the concept of a bill of materials at Toyota in the 1940s. “Bills of material are standard in every other industry,” Jennings Aske, senior vice president and CISO at New York-Presbyterian Hospital, tells CSO. “Why not software?”
Simply exposing the ingredients of software would improve the safety and security of software products, although many organizations are likely to object to such exposure. “I liken this to automotive safety,” Aske says. “When Ralph Nader was pushing for seatbelts, people thought, ‘well, they’re not needed,’ or ‘it’s government overreach’ or ‘customers aren’t going to like it.’ And then companies like Volvo figured out this actually could be something they could use to sell their products. They could charge more.”
While not every BOM management is the same, there is a huge opportunity to solve the problem of SBOM management and alignment with other modules – mechanical and electronic. This is why having a flexible data model combined with multiple BOM disciplines is very important. Unfortunately, most legacy systems are managing a single type of BOM usually derived from design systems (MCAD, ECAD, PCB design). While these BOMs are good for design, they don’t provide a good and flexible data model to manage a variety of BOM types as a single whole data element.
OpenBOM Flexible Data Model
A key difference of OpenBOM’s technology is its ability to provide a completely flexible data model managing reference-instance data model for multi-disciplinary BOM.
The foundation of the model is a distributed catalogs’ system capable of managing multiple sets of item definitions – mechanical, electrical, software.
In addition to that, OpenBOM’s product structure model allows it’s user to combine a diverse set of BOM records with full flexibility of data model on both item and instance level. Last but not least, OpenBOM patented collaboration technology allows team members, contractors, and suppliers to work together to provide each their own piece of the whole BOM.
With the way things have been rapidly changing these last few months the urgency for a flexible and robust platform is here to stay. While the methods to manage BOMs were developed in the manufacturing industry a long time ago, having flexible tools capable of connecting to multiple design environments (including software tools) and pull all information together arranging it into manageable data assets can be of much help to many types of industries.
The urgency to manage SBOM is here and it comes from three independent directions – (1) product complexity; (2) regulatory compliance and (3) cybersecurity.
OpenBOM has tapped into this need and is providing its client base with the flexibility, data management, and communication it needs to get to the next level.
To get an inside look into the OpenBOM tool, register for free and start your 14-day trial.
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.