The tool, Software Bill of Materials has become a gigantic beast over time. Why? Because today’s software is really a patchworked quill of other software. A little code from that open-source one over there. A tiny line from that third-party paid one over there. And a pinch of your in-house concoctions.
Your secret sauce, the one customers pay handsomely for, not only has your ingredients but a couple of others borrowed from the likes of Heinz and that nice BBQ joint down the street. This is one of the reasons why creating and adopting and generating SBOMs effectively across your organization is such a daunting task. Why you might just need professional help, and the right set of tools to meet the challenge headlong.
A Software Bill of Materials is an inventory of the software products and services that are being used by a given organization. The Software Bill of Materials can be used to identify dependencies between the software products and services and to track changes in the product versions. It is also useful for identifying the number of licenses that are needed for various products.
For example, if you are building an iOS app to be sold on the App Store, your bill of materials would include the specific version of Xcode you are using as well as any third-party libraries you are using in your project.
Today, all organizations that dabble in software creation or app creation need to generate SBOMs. Why? Because we no longer have control over where and how exactly the software is going to be used. Let’s slip back in time to the late 80s, when Nintendo created their Mario Bros. game. Back then the company had total control over it — to the extent that it could only be housed in one of their cartridges and reproduced in one of their consoles. It was the biggest safeguard of their intellectual property. On top of that, their system was utterly isolated, it didn’t connect to anything or any other supplier. Just your TV set, which back then was as dumb as a rock.
Today, those same consoles have done away with cartridges and are now working off cloud libraries — games you can download from their digital store. Those same games, for multiplayer activities, hook up to the net. Those same games link up through optical and HDMI cables to your extremely smart television set. Those same games give participants the ability to post whatever they feel like on a miasma of social networks. Those same game consoles are also entertainment hubs, for the likes of YouTube, Netflix, HBO Max, Disney +, etc. Those same game consoles need hyper-fast Bluetooth connectivity.
For all those extras, you’ll need a code, a component, and a software plugin that you have no control over how it was manufactured. Or when it will be updated to fix a security breach. Or when it will become obsolete. Now, what if instead of game consoles, and game development, we expand our horizons to smartphones, tablets, laptops, smartwatches, remote patient tools, smart TVs, etc?
All of them need software, the software you might produce, and all that software needs other software from third-party suppliers — a lot of comments you need to stay on top of. That’s why SBOM generation is so challenging, because today even the most basic app is chock-full of codes and plugins you didn’t develop and that you need to supervise.
On top of what we previously described, the fact that your generated SBOM will end up looking like those huge library card catalogs, how you adapt and customize your Bill of Materials will determine how well you can use it. Whether or not all that data collection will work in your favor, and if you can leverage it properly for your benefit.
Let’s take a look at some of the challenges.
SBOM generation is sometimes a hit and sometimes a miss — why? Because an SBOM document can be as simple as a Google Sheet and as complex, and interactive, as a virtual repository. it can be a list of components or a list of actionable intel. The former is tricker, but much more rewarding and beneficial. It can list tasks for your team to get through, it can help you automate processes, it can create alerts for updates of certain codes as well as reviews, and it can be customized to your needs.
Automation is the name of the game, the more tasks you can automate the better. On top of that, your SBOMs need to be conceived and uniform across all your platforms. Remember it’s not only your very own SBOM generation you’ll be dealing with but those Bills of Materials your vendors and code suppliers present you.
Unless you ask for it, demand it, and lock it in, chances are your vendors will end up giving you a template-like SBOM. One your team will later have to dissect for it to meet their standards and format. Biggest pro-tip: lock the format in, have it so your vendors can’t present their SBOMs and be paid for their codes unless they stick to your format.
Who has access to what is always challenging? Not only for security reasons but because most developers simply don’t take the time to analyze this issue — in most cases, they just grant access to whoever asks for it. It’s important in SBOM generation to determine who has permission to do what — to alter or modify the bill in any way.
The software bill of materials can be generated using various tools, such as Microsoft Excel or SAP Business One. SBOM generation tools are important for any business because they help companies manage their inventory and reduce costs. But why contact a professional, aside from the fact that SBOMs are incredibly complex — because SBOM generation is dull, never-ending, highly detailed, incredibly insipid, yet necessary work. At the end of the day, your team is either to create, not to fill out paperwork.