I’m not the most active user of any social networking platform, but when I do engage it’s normally on LinkedIn -  and the first thing I usually see is a great article, video, or post from Chris Hughes. 

He’s a content machine - an active podcaster, and I can tell you that when his upcoming book "Software Transparency," is released, I’ll be the first to pick it up and read it.

I had the pleasure of meeting Chris in person recently, and he’s a remarkable person whose presence immediately establishes him as the smartest person in any room. 

He was just about to give a talk about Software Transparency and the Software supply chain. I was blown away by the amount of knowledge he shared, and the clarity in which he delivered it.

In today’s episode, I’m extremely excited because Chris and I dig into a diverse range of topics, and we explore the crucial concept of transparency at the crossroads where government, vendors, and consumers all meet.

Welcome back, to daBom.

Seems like every time I talk to someone or do research on Software Bill of Materials, I encounter VEX - Vulnerability Exploitability eXchange - and I never really understood what they were used for.

I knew they had something to do with understanding the vulnerabilities that exist inside the components we list inside of an SBOM, but why does the format or concept exist? After all, we already have ways of exchanging vulnerability information like Bill of Vulnerabilities or Vulnerability Disclosure reports, right? 

Well, VEX represents an approach to sharing vulnerability information as well. As well as being a concept, it offers a format specifically designed to describe the exploitability of a vulnerability. It encompasses crucial details such as attack vectors, exploit complexity, and the impact of a vulnerability. 

Why? 

Well, just because you have a component with the vulnerability, doesn't mean that the application itself is affected. It's quite possible that the component only has one vulnerable method - and it may not even be used by your application.

Understanding this context around vulnerability enables security practitioners, researchers, and vendors to assess and prioritize the remediation efforts more effectively. 

In this episode, I'll be talking once again to Steve Springett from the CycloneDX project and we'll be diving into the topic of Vulnerability Exploitability eXchange.

We'll gain a deeper understanding of how VEX fits into the broader landscape of information exchange and Software Bill of Materials, and how it contributes to our collective efforts in building safer and more resilient software systems.

Welcome back, to daBOM

Back in February, I posted that I was putting together a Podcast to help demystify Software Bill of Materials. Shortly afterwards - a reply appeared from Daniel Bardenstein. It was a simple message where he said that he'd love to talk about operationalizing and deriving value from SBOMs.

This piqued my interest - because the question of what we do with Software Bill of Materials has been a constant concern of mine. I've always feared that they would become just another document. Written once, and never referred to or viewed again.

One of the biggest challenges with SBOMs is figuring out how to integrate them into existing software development and procurement processes in a way that generates meaningful insights and mitigates risk. This is where the expertise of experts like Daniel Bardenstein can be particularly valuable,

I got on a call with Daniel as soon as I could.

You know those conversations where it seems you've known someone for years? Yeah. That was my first conversation with Daniel - and every conversation since then has provided more and more clarity on the tangible things we can do to realize the value of Software Bill of Materials.

Welcome back, to daBOM

As we continue the journey to unravel the world of Software Bill of Materials, I wanted to talk to a technologist who had been there from the start - and could shed some light on the background of the movement.

The search for such a person led me to the South German State of Bavaria, where I found Max Huber. 

Max has been a contributor to the SPDX project for upwards of 8 years, and helped build some of the first tools to create and process the format. 

SPDX - or Software Package Data Exchange - from the Linux Foundation has become one of the leading formats for describing Software Bill of Materials since its inception in 2010. The primary goal of the format is to simplify and standardize the exchange of information among software developers, suppliers, and users.

On today’s show we go behind the scenes with an engineer and learn a bit more about the technical side of SPDX, and gain insight into some of the upcoming features of SPDX 3.0.

Welcome back, to daBOM

It was back in early 2017 when an annual tradition started in a hickory smoke filled lounge in San Francisco. I'd found myself at B-55 in the Marriott Marquis sitting around a large table after her day of presentations at the RSA Conference. 

Surrounding me were some of the originators of DevOps, thought leaders from the Rugged Movement, horseman from I am the Cavalry, innovators from the Chaos Engineering tribe.

...and at the head of the table was Shannon Lietz - the original gangster of DevSecOps. 

If you know anything about DevSecOps, you know who Shannon is. The DevSecOps manifesto? It's directly from the technical mind of Shannon Lietz. How does she start? She began to develop an interest in agile development practices and the idea of . Integrating security into the development process decades ago, and she's influenced the industry ever since. DevSecOps came out of the seeds of that idea.

A seemingly endless stream of Smoked Old Fashioneds made it to the table. 

The conversation? Passionate discussion about DevOps with Security, DevSecOps, Rugged Software. Where was it all going? Is it just the same thing? 

In what we all coined "The Smokey Lounge" friendship started between all of us. We didn't know where this DevSecOps thing was going, but we all knew it would change everything...

And Shannon? She became one of my mentors and friends. She's one of the most fascinating Women in Tech I've ever met, and shares the same values I do, dreams of a secure future, is a creator, and has a technical. Welcome back to daBOM.

A package of Twinkies is a permanent fixture on Allan Friedman's desk, which he holds up to the screen during our conversation. A prime example of the underlying purpose of a Software Bill of Materials. The significance? The ingredient list on the package which lets you know what's inside. 

I always use the can of beans analogy myself - but the Twinkie - well, this is the bad stuff. Seems obvious that it's better to know what you're going to consume, then assume you're eating something healthy.

You can't help but think of Allan when you think about Software Bill of Materials. He's been advocating for the use of SBOMs to increase software supply chain transparency and enhance security for years. 

One of his beliefs - 

Organizations should not be using software without knowing what components are inside and any potential security risks. Particularly important in today's world, where software is an integral part of almost every aspect of our lives, from our smartphones to our cars to our homes. 

It's National Supply Chain Integrity month and in this episode, we'll hear about some of the Government's views on SBOMs, and why the topic is so important. 

Welcome back to daBom...

When the video call finally connected, I saw glitching Chris Blask sitting behind a studio mic, and in the background an open door revealed what appeared to be a lake -  with sun glistening across the water. 

For a brief moment, I thought Chris was working near a dock, but in fact, he was actually working on a boat. 

A boat in the middle of the waterway, far from any shore, in the Florida keys.

The internet connection wasn't the best as Chris took me on a virtual tour of a floating home and it took a bit of time bouncing between satellite and 5G to get things stabilized. As he walked around the boat and climbed up to the top, he showed me the solar cells, the generator, and the setup for his internet connection -  but just before returning to his microphone, he did a slow 360 degree panorama of his surroundings. 

I thought to myself... I'm on a journey to find out more about the DBoM Digital Bill of Materials project, and on the road, it leads me to a remote location surrounded by beauty and sunshine? 

Welcome back to daBOM...

I'm DJ Schleen and welcome to daBOM. 

I'm on a journey to demystify Software Bill of Materials and on this podcast I'll be investigating technical, regulatory, and practitioner stories in and around the SBOM and -BOM movement. 

Along the way you'll meet the people and teams responsible for creating and maintaining the various Software Bill of Materials formats, and we'll also dig deep into all types of Bill of Materials including SBOMs, SaSSBoms, IBOMs and any other type of -BOM that you may have heard about. 

If you're interested in software security, the software supply chain, and want to know what's in your software, you're in the right place.

On today's episode, I'll be talking to Steve Springett from the CycloneDX project about the CycloneDX format, SBOM specification.

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 may 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 our 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 components.

Not only do we produce software, but we also consume it from our vendors and suppliers. In this light, SBOMs can help organizations understand what we are purchasing from 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 in 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?