SBOMs are a generally new trend — they have yet to fully cement themselves into today’s digital/tech world. They are incredibly useful, and in many cases, they are a must — yet they still exist in a void. A void full of myths and half lies. A void brimming with misconceptions.
Let’s unpack some of the Myths and Facts surrounding the Software Bill of Materials.
The Unexplored nature of SBOMs
BOMs or Bill Of Materials have been in use since time immemorial. Since mankind decided to manufacture anything in mass. When Greek ancients started mass-producing amphorae – ceramic jars used to store both liquids as well as dry goods – they used a Bill of Materials to make sure their manufacturing plants would always have the necessary components on hand. These BOMs assured them not only that they could keep their assembly line in tip-top shape, but that they could reproduce the quality they wanted in their jars over and over again.
It was how they competed amongst themselves — some jars had metal inlays for durability, others had precious stones, some needed a unique clay mixture created in the quarry to shape the molds, and some were simply practical and cheap. Each vendor had a specific product, and each one of those products was made for a very niche-oriented demographic. And, each vendor valued its supply chain and suppliers. BOMs made sure that no matter who was in charge of the business, the products could continue to fly off the assembly line without a hitch.
From amphoras, we graduated to other much more complicated things — weapons, ships, building materials, microwave ovens, books, musical instruments, candles, and just about everything we could think of. And each vendor, or developer, kept a close watch on their supply-chain thanks to the information they had gathered in their BOMs. The Industrial Revolution supercharged this phenomenon, and suddenly what was once a voluntary choice became a necessity — businesses started to understand the real-world value of intricately detailed Bill Of Materials. Now the assembly line was mechanic and fast, not only that, now businesses were opening up regional offices, and franchises, expanding, and each one of the hubs needed a BOM to fulfill their product quota.
As computers and software came into the mix a whole new branch opened up and an S was added to the BOM acronym. In the beginning, these Software Bill of Materials were rather dull and succinct — one-line kind of affairs. Pac-Man was simply Pac-Man Atari/Namco/Iwatani. Basically, the name of the game, followed by the developer – Atari/Namco – and the creator team – Tour Iwatani’s team. Simple.
That only lasted for a couple of years. Why? Software became more complex. Companies started sharing codes or working off the same open-source library. Now, an SBOM is a huge list of different components. And it not only tells developers where their ingredients come from, but what version of it they are introducing into the mix, as well as if the ingredient needs to be replaced due to a vulnerability.
That complexity is where most businesses find themselves — in a gray area that’s still being created, that’s constantly evolving and is brimming with lies, half-truths, and a lot of fake news.
Software Bill of Materials myths VS facts
Let’s take a look at some of the various myths floating around when it comes to SBOMs – Software Bill of Materials.
Myth: SBOM is a roadmap to an attacker.
Fact: SBOMs provide transparency whose benefits outweigh the concerns. Can an attacker use an SBOM to navigate your systems? It’s theoretically possible. SBOMs provide a huge amount of info. That’s why they have to be heavily protected. But, they also provide security teams with a roadmap of where an attacker can come from, and how an attacker can enter your system. They give teams a clear line of sight into your software’s vulnerabilities, making it easy for them to supervise and manage all those breach points.
Myth: SBOM alone doesn’t provide any useful or actionable information.
Fact: SBOMs by themselves are just lists, it’s how you configure them that counts. SBOMs can be interactive sheets or simple Excel files. Some are highly dynamic tallies with dates, and actionable intel – such as alerts for when a new update comes along, priority levels of vulnerabilities, type of vulnerability, what team is patching things up, all the way to tasks, and whether a comment has been approved or rejected.
Myth: SBOM needs to be made public.
Fact: Generating an SBOM is a separate process from sharing it with people who can use this data. Your SBOM is, well, your SBOM. At most you may be asked, depending on your jurisdiction to divulge a section of it — the inventory list. Everything else, how you’ve tweaked those components, their licensing, their vulnerabilities, their status is a trade secret.
Myth: SBOM is a piece of product security by itself.
Fact: SBOM is a set of information about the software package that can be useful in providing transparency to the end user. SBOMs are a tool for users — including security teams. The best way to describe them is as part of the instruction manual your teams will need to make every other gadget in their toolbox work.
Myth: SBOMs will expose your intellectual property/trade secrets
Fact: SBOMs are a summary of included software components and do not expose IP. SBOMs are like the nutritional label attached to every KFC order. The one that tells you how many calories, proteins, and spices that bucket of chicken has. It lists all the ingredients of for example Original recipe chicken breast — 21g of fat, 120 mg of Cholesterol, 11 carbs, etc. That same chicken breast is composed of different ingredients, such as salt, pepper, smoked paprika, etc. Full of facts, but none tell you how to mix them up and create that crispy, heavenly bite — there’s no way for a person to reproduce, exactly, the Colonel’s 11 herbs and spices recipe. You might get copycats, but no one will be able to get it just right.
The importance of a Software Bill of Materials
The software bill of materials is a list that contains all the software components that make up an application or system. This can be anything from code libraries to third-party frameworks and plugins to custom-built modules developed in-house by developers.
It is important for any company that wants to have its software developed in-house or by a third-party company because it helps them plan out their budget for development costs with more accuracy.
Taylor is a freelance SEO copywriter and blogger. His areas of expertise include technology, pop culture, and marketing.
