daBOM

Remember the X-Files television show? Dana Scully was one of the main characters - a brilliant FBI agent who worked on unsolved cases involving paranormal phenomena. Often skeptical of the supernatural, she was always willing to keep an open mind, and she was also a great role model.  She inspired many women in Technology, one of them being Lauren Hanford. Scully’s inspiration led Lauren into the field of Criminal Justice and Chemistry, and then she made a pivot into Computer Science, and Design. The catalyst being a desire to make doing homework easier.   It’s funny how technology always finds us.  Lauren has been a part of the open source community for years, and has a massive understanding of the space. Recently, she brought the TACOS framework (Trusted Attestation and Compliance for Open Source) to the community to help assess the secure development practices of open source software. It’s a perfect companion to a software bill of materials.  …and the name? It’s a nod to GUAC and to SLSA.   Welcome back, to daBOM

There's no better way to get to know someone than staying awake for 24 hours straight while moderating sessions of the world's biggest virtual DevOps conference - All Day DevOps. It's One of the many times I've gotten to spend with Hasan Yasar over the years.  We were hunkered down in an office in Tyson's Corner, just outside of Washington, DC, broadcasting throughout the day to an audience spanning the world, introducing some of the world's most talented minds before they shared their stories. Hassan and I met back in 2017 when we were both speaking at DevOps Connect at RSA, and I was floored at the wealth of knowledge he had about DevSecOps. He's done the research, knows the practice, and has the mind of an architect.  Hassan isn't only a speaker in the community, though, he's also an organizer of events such as DevSecOps Days Istanbul, DevSecOps Days Tokyo, and one very memorable panel I was on at an event hosted by the Software Engineering Institute at Carnegie Mellon University. Hassan placed me on a panel beside Brigadier General Greg Tohill in front of an audience of military personnel to discuss DevSecOps.  I will never forget fielding a question with General Tohill from a member of the Air Force. They asked "how do you fail fast with a ballistic missile?"  " You better have some good simulators." When Hassan and I caught up again at the RSA conference this year, our conversation turned to the topic of Software Bill of Materials and how they fit into the SDLC.  ... and then Hassan started talking about how we could shift them extremely far left...  Welcome back, to daBOM.

I'll never forget the day I met Tracy, although I really think we were actually separated at birth. We were scheduled to be on a podcast together and after introducing ourselves to each other in the call lobby, we began a discussion that most likely would've gone on forever at the host, not interrupted us to get the show started. It turns out we both have similar passions in the DevOps, DevSecOps, and SRE spaces, and not just philosophical ideas and hoopla high fives. We've actually done it. Practical implementation of ideas that have injected security into the software we all develop.  An architect, a programmer, a dreamer, and a visionary, she's also a strong advocate for diversity and inclusion in the technology industry, and has often shared her experiences about being a woman in technology.  Two topics that are very close to my heart as well...  Earlier this year, Tracy and I were brought together by Mark Miller for "It's 5:05", a podcast produced by The Sourced Network that brings snack sized news about open source and security topics to the masses on a daily basis. From the seeds of "It's 5:05" came the opportunity for me to create this podcast. And also for Tracy to create a podcast called "Real Technologists". And if you haven't heard it, you need to. It's a brilliantly done production about the people "behind the technology".  And speaking of real technologists, Tracy is one of them. Welcome back, to daBOM.

It must have been a year or so ago when I was looking for an open source vulnerability scanner to use in a project I was working on. As I scoured the internet, I stumbled upon a project called "VulnerableCode" - a server that could run locally and would return vulnerability information if you called its API and gave it a Purl. What's a Purl? It's an abbreviation for Package URL and it identifies a component that's used in a software we build. Think of it like a hyperlink that contains metadata such as ecosystem, name, version, among other things...  Why is it so important? It's quite simple. If you have a component Purl, you can query a vulnerability database and get a list of CVEs that affect that component. So we can think of a Purl as a key of sorts - and it shows up everywhere in a Software Bill of Materials.  Anyway, let's get back to the story.  The project I was working on? It was a little proof of concept CLI that would eventually become "bomber" - one of the first open source SBOM vulnerability scanners. I started prototyping using VulnerableCode but then moved on to vulnerability APIs that were available online, but I always wanted to return to VulnerableCode someday. That day came in December last year when a new issue was created in the bomber project on GitHub. It was titled "Fetch Data from VulnerableCode" and was submitted by one of its creators, Philippe Ombredanne. When we finally connected via email a few months later, I found out a few very interesting things about Philippe. First, he invented the Purl.  Second. He's a long history with SPDX, CycloneDX, and Software Bill of Materials.  Welcome back, to daBOM.

I read an interesting post on Twitter the other day about Software Bill of Materials. The author said "SBOMs promise a picture of what lies beneath the surface of software, but without large scale automated binary analysis, at best, they reflect intent not reality. As a result, relying on them is like being an explorer without a compass." The author does make some good points here. Large scale binary analysis is definitely lacking in some regards - but the technology is there to do it, and we've had a guest on the show that has talked about how they're doing it today for mobile apps.  But binary analysis is only one use case. There's so much more to Software Bill of Materials. As for the compass, even as late as the 1700's European explorers still used AstroLabs. They helped navigate using the stars, and although the compass was invented around the same time in Asia, it was only used as a backup to the Astrolabe.  What that shows is you don't need to have a compass to be an explorer. Just like you don't have new technologies without innovators like Tim Miller. He's one of the folks behind Guac - and that's an acronym for "Graph for Understanding Artifact Composition". It's an open source tool that aggregates software security metadata into high fidelity graph databases.  What does that mean? It means that it ingests SBOMs and provides a way for users to query that information.  Tim reached out to me after seeing Guac as part of my SBOM Reference Architecture" in a LinkedIn post that hit his feed. After getting on a quick call to discuss what I had planned for Guac I knew I had to get him on the show. What do we do with SBOMs after we get them? Buckle up, because we're going to talk about one thing you can do...  Welcome back, to daBOM.

Every one of us has a few of those people in our lives that change the trajectory of our careers, and for me, Dan Walsh is one of them.  It was just a few weeks after the world shut down during the pandemic when I was introduced to Dan by a mutual friend of ours - Aaron Rinehart - after Aaron heard I was looking for my next big adventure. He introduced us via text message and when I got a chance to meet with Dan We talked for over two hours, and I think we cracked a few brews along the way. It was a conversation that was filled with ideas, possibilities, and dreams.  Although I never met Dan in person, it didn't stop me from going to work with him in one of the biggest healthcare groups in the world.  We still hadn't met in person when I followed him to another company in the healthcare industry. We were just talking heads on a screen to each other at that time. But it was a new world, and none of it hindered our innovative spirit and friendship.  As the pandemic restrictions started to wind down, I arranged a trip to Chicago to meet my team, and as I landed, I hoped that I'd get to the hotel on time for a quick drink before the bar closed. I'd arranged to meet up with Dan. In person.  It was almost two years after we first talked on Zoom and here my plane was delayed, and it was really late. But I did get to the hotel... just in time.  I'll never forget walking into the lobby bar at the W, in downtown Chicago and seeing Dan with 4 full pints of beer in front of him. "It was last call" he said,  "you're taller than I thought you were", I responded.  Welcome back, to daBOM.

I remember being pushed back into my seat with a force I had never felt before.  It was the first time I had ever been in an electric car, and Brian Reed was at the steering wheel with this big smile on his face as we went from 0 to 60 in about 3 seconds. It was just one of the many memorable experiences that I've had while spending time with Brian over the years. It feels like every time I see him, he introduces me to something new, and the discussions we have - they're extremely illuminating.  Recently I ran into Brian and we started talking about Software Bill of Materials. As we were catching up, he mentioned something that caught my ear and I really had to hear more about. He asked... What do you do when you don't have source code to create an SBOM? What do you do when your vendor doesn't want to give you one? What do you do if you only have a binary file?  Well, it turns out you can do a lot... like binary scanning and reverse engineering.  I never thought of this approach as a way to generate, examine, and share information about the composition of software before - and you know, it makes so much sense.  Welcome back, to daBOM.

Earlier this year I had the opportunity to attend a software supply chain summit and meet Lisa Bradley, Senior Director of Product and Application Security at Dell.  Lisa had a point of view that was different from the people I talked to about SBOMs in the past. It was big picture practical view of how to implement an SBOM initiative at scale - for one of the biggest companies in the technology Fortune 500 - Dell.  While preparing for this episode, I found that Lisa's vast knowledge and experience in the field of product security made her an authority on SBOMs. Her insights and perspectives have not only shaped the SBOM program at Dell, but also have far-reaching implications for the entire industry. We're going to dive into the practical and this episode. How large organizations are handling SBOMs, and how they're handling the world of generating VEX using a brilliant approach to automation.  If you're wondering how the biggest companies in the world are dealing with SBOMs you're going to enjoy this conversation with Lisa. Welcome back to daBOM.

I often can't get over how small the world actually is.  Earlier this year, I attended the Second Annual SBOM meetup after the first day of the RSA conference. The venue was at a little bar on Minna Street, tucked away underneath the skyscrapers of San Francisco.  The bar was filled with quite a few familiar faces and after grabbing a cold beer, a hand reached out through the crowd to shake mine. Standing in front of me was Ritesh Noronha.  I'd never met Ritesh before - or so I thought for a brief moment. He asked me if I had coded "bomber" - an open source project that scans for security vulnerabilities. He then explained that he had been following the project for a long time, and had commented on some of the issues in the project. It turns out we had met before - on GitHub.  The odds of meeting each other at an event in San Francisco seemed almost infinite, but here we were discussing SBOMs and Open Source.  It turns out that Ritesh and his business partner, Surendra Pathak had also been building incredible open source tools to work with SBOMs and during our discussion we all started to talk about Quality.  SBOM formats are notorious for being so flexible that any tool can potentially create one that could just be a collection of "NO ATTESTATION" values - and this potentially renders them semi-useless - but Ritesh and Surendra have been busy creating open source tools that provide an SBOM quality score. Need to see if an SBOM conforms to the minimum requirements as specified by NTIA? Then you really understand that quality matters.  Welcome back to daBOM.

As the video connects I see Brian Fox, sitting in front of a collection of model spacecraft which adorn the shelves behind him.  It's a fitting backdrop for a conversation about the genesis of the software supply chain problem, and how exploration and discovery has led us to where we are as an industry today. Think about this, it all started when we began to assemble our software from components that we didn't write ourselves.  And Brian was right there.  He was there since the beginning of the open source supply chain universe - a pioneer of sorts. A contributor to the Maven ecosystem, and today he's at the technical helm of a successful company that enables the promise of making safer software sooner. I had the pleasure to work with Brian in the past, but I never had the opportunity to hear his story until now.  Welcome back... to daBOM. 

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?