Introduction

[00:00:00] DJ Schleen: 

Today’s software is extremely complex – and with the pervasive use of third-party components, it’s become extremely difficult for anyone to keep track of all the external code in their systems. 

Pieces of code that aren’t written by your own developers. 

These components are assembled by engineers and can potentially make up the majority of the software we build every day. For everyone outside the engineering organization? They might not even know what these third-party components are, or that they are even being used. This lack of visibility into what these components are and where they come from can become a huge risk. 

Enter the Software Bill of Materials, or SBOM, a document or collection of documents which can provide an extensive inventory of all the components and their dependencies in the systems and software we build. They can enable organizations to identify security vulnerabilities, ensure compliance with licensing or contractual requirements, and manage risks associated with third-party component. 

Not only do we produce software, but we also consume it from our vendors and suppliers. In this slide, SBOMs can help organizations understand what we are purchasing from our vendors and during a security review, we can infer tech debt and hygiene, and understand the risk we take on by purchasing software and rolling it out into our ecosystems – and we can also take proactive measures to mitigate those risks. 

There’s been so much conversation about the supply chain and Software Bill of Materials that it can seem overwhelming. How do we create them, how do we ask our vendors for them, what do we do with these things once we get them? Why are there so many types of BOMs? 

What I’m looking for is answers and although I think we’re on the right track, I’m not convinced that SBOMs – along with other variations such as SaaSBOMs, xBOMs, *BOMs, or even daBOMs are leading us in the right direction.

Maybe we’re just over complicating things? 

From The Sourced Network’s remote offices in Golden, Colorado, welcome to daBOM. Each week, we’ll talk with industry experts and practitioners who discuss their experiences with Software Bill of Materials, including their motivations for using them, whether they are dealing with an inventory or security issue, and if they’re implementing them due to government mandates. We’ll be looking at formats, standards, and stories about how people are working with SBOMs today. 

With each episode, we find another piece of the puzzle – words of caution – words of frustration – and more often than not, words of wisdom. We quickly find out that we’re on a journey to separate factor in fiction.

I’m DJ Schleen and I started my technology career as a hacker – a young kid with computer, a modem, and an endless amount of curiosity – and since then have spent my career in system development, architecture and security. I’ve spoken around the world about DevOps, DevSecOps, and automating the manual away and securing the software we produce as we do so. Now I’m on a journey to increase visibility into the components and dependencies that make up the software we create. 

Are Software Bill of Materials a potential solution to the problem of transparency and traceability, or are they just hype?

Join me on my journey every week as we seek out the answer.