DJ Schleen: 

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

I’m here with Daniel Bardenstein. You reached out to me on Twitter after I posted a note about creating this podcast called daBOM. We had talked a little bit and really got this synergy about SBOMs and where the market’s going and where this whole technology is right now.

Daniel, tell me a bit about yourself and your background. 

Daniel Bardenstein: 

I’m Daniel Bardenstein. Good to connect with you again, DJ. I’m the CTO and Co-founder of a startup called Manifest. We are a software supply chain company that’s focused on operationalizing SBOMs, helping organizations answer the question, how do I generate and solicit SBOMs from my vendors. And then what do I do with SBOMs once I have them, either from my vendors or from my, internal, developers. 

DJ Schleen: 

Give me a little bit of background on how you got into this whole SBOM topic and what you’re thinking about it right now. 

Daniel Bardenstein: 

It started when I was doing, some policy research at the Aspen Institute. I was focusing on medical device cybersecurity, understanding what the FDA did and their responsibility for making sure that medical devices were secure. 

I learned that the healthcare industry has actually been dealing with SBOMs in some form or another for a number of years already. They used to call it the CBOM, Cybersecurity Bill of Materials, and then brought along with everyone else and now calling it SBOM as well. 

 Some of the research and the discussions that came out there were this idea that the white hat hackers who’d been able to exploit medical devices and the impacts that they could potentially have, and when there’s a recall of medical devices or medical IoT, that it’s effectively on the FDA to try to figure out which vendors are impacted, what products are impacted and data that they don’t have. And you think that this is something, especially when lives are on the line, that you want a big government agency to be able to understand quickly and be able to notify people.

 That was my first introduction, two or three years ago. The second, really big event for me that kind of codified a lot of this was Log4J and Log4Shell. I was at, the Pentagon. Some of the largest, most mature organizations took between, four to 12 weeks to answer the simple question of where is this one library running in my environment, not just for my first party applications, but also for the various third party tools that I’ve purchased. 

It seemed like a very obvious idea at the time of kind of this one plus one equals two of, okay, so there’s this concept of, this SBOM, which provides novel data you look at it like a piece of data, not just a compliance burden, novel data about what’s in a particular asset. You can think about what happens when you amass a lot of that data and oh, couldn’t that be helpful for responding to something like, a Log4Shell like vulnerability. And then the light bulbs went off in terms of other things that you could actually use that data for.

And that’s a little bit of a story of my introduction into SBOMs. 

DJ Schleen: 

When you were starting off with these cybersecurity bill of materials at the Aspen Institute, was it a combination between hardware and software that you were using these inventory and create a manifest for? 

Daniel Bardenstein: 

I was doing a little bit less of the generation side there. I was more doing policy research into how could the FDA help promote cybersecurity in medical devices, secure medical devices, better with its carrots and levers. So for me it was a little bit more of just research, understanding the FDA pre-market guidance a couple years ago mentioned a CBOM, a Cybersecurity Bill of Materials.

 It’s mostly focused on these software components, not the hardware, that was part of a medical device.

DJ Schleen: 

So how do software billing materials today, like the CycloneDX format at SPDX format, how does that differ from what you were doing at Aspen Institute? 

Daniel Bardenstein: 

The SPDX and CycloneDX are definitely much more robust, than those earlier days, because SBOM is not just a two or three old concept. We still to this day see people just providing dependency lists in PDF for Excel and that was the norm. And even if you go on Slack’s website, Slack actually has a list of all their third party dependency for their desktop app written in a quasi PDF doc. CycloneDX and SPDX represent this big step forward into how do we make this stuff more machine readable, how can it be automated? How can it be more easily shared? How do you actually make it actionable to a user. Because machine readable means great for exchange and automation. It means very poor for a human to understand what’s going on quickly and easily.

DJ Schleen: 

One of the previous episodes that I had recorded, there’s conversation about some of the formats being so flexible that tools that generate these Software Bill of Materials might generate them in a different format. How do you deal with that, and merging those together and just the exceptions around these evolving specifications. 

Daniel Bardenstein: 

Overall we’re going to continue to see, both of those formats, continue to evolve. They’re both meant to be as flexible as possible, and they’re always pros and cons to that, especially when you have generators trying to keep up and making sure that their generators are to spec.

 I’d also be surprised if there are only two major players for the long term. There are very few places in IT security where there’s only two of, standards or two formats of something. So I imagine there’ll be more to come. 

 The spec and the format you can expect it’ll continue to change and oscillate. as long as the tooling is such that you can bring your own format and there’ll be some sort of parsing or ETL. 

Back when I was at Exabeam building essentially a sim or machine learning based anomaly detection, you’re taking Windows logs, you’re taking proxy logs, you’re taking VPN logs. There’s no standard necessarily for each of those log formats, even within the same vendor. It just meant that we had to spend a lot of time writing parsers for each of those, different data formats and getting into a normalized state where then you can do your analysis. We can expect to see similar things with SBOM in the future. 

DJ Schleen: 

Let’s talk about inventory and management and how we actually use these things because we have these documents. Let’s go and dig into how do we manage these things? How do we exchange these back and forth and what do you think about that problem space. 

Daniel Bardenstein: 

A lot of the current dialogue around SBOM is focused on almost like an SCA workflow where we’re thinking about, selling to developers how you ship and build more secure software, which is very important.

The narrative is really often talking about one SBOM at a time. We’re thinking about one project, one application that I’m as a software supplier , and I need to make an SBOM for that. And then someone’s telling me this SBOM is magic and going to make all of my problems go away. That undersells the value of SBOM, ? And I keep referring to it as a data set, data is more valuable in bulk. 

Before we get to how do you manage the inventory, which is the aggregation of that data, let’s talk about sharing.

 The standard right now is to email, as we all know, a very secure, way of exchanging information. As soon as somebody receives it, they’re going to download it and forward it and share it. And you’ve lost kind of all provenance, or might as well show up on the front page. While there are those of us who believe philosophically that SBOMs should be public, . we’re seeing pretty strong for the market that we’re not quite there yet.

A lot of software suppliers or vendors, they want to keep this stuff close. What we’re seeing now and what we’ve actually had some success developing, doesn’t have to be overly complicated, but can you build a, a simple portal that allows organizations to securely and selectively share their SBOMS with whoever that third party is.

Is it, a government regulator? Is it an insurer? Is it a customer? Is it some other third party? There’s still a lot of education in the market going around, a lot of legal teams being concerned that people are sending their IP out the door in SBOMs, which as we know is not necessarily the case because it’s just high level inventory lists.

 That low bar, just making sure there’s some degree of confidentiality, integrity, and some basic authentication on who can access this information and documents. We hope to see this open up more broadly in the community.

 I’m switching hats now, I’m a software supplier, writing applications developing SBOMs and sending them to my third parties, and now I am the government agency or the hospital receiving SBOMs from all of my vendors and third parties. Where am I going to put all these things again, email? Terrible answer, but we see it.

The second thing we see, put it in the drive or the teams folder, and then wait for the next Log4Shell, or whatever it is, and I’m going to con control F and try to turn that into some meaningful insights. 

Or the third option, which has been our approach and we expect to see it proliferate is, this is data. How do we put the data in a way that, if I can put it store things in a normalized format, I can easily search and filter across things. You have some basic set of data so you can search to enrich it with vulnerability data with exploitability data. 

SBOM is just the list, but it’s of software. But from that list of software, you can go off and get so much information that’s out there. 

Inventory is phase one. Even the inventory is helpful to have a software inventory, right? We talk in security a lot about asset inventories, and you can’t protect devices that you don’t know are on your network. We think of like attack service management tools. I need to know what’s my public footprint to make sure that people can’t exploit what’s publicly exposed. Same concept applies for my internal software. What are all the libraries that are being deployed on my production network?

Just putting the SBOMs in one place solves that problem. It helps if you have some tooling to make it a little bit more easily surgical and filterable, but that’s just phase one. 

You’ve successfully stored your SBOMs, but you’re not really acting on them. That’s the drives towards what are those use cases? How do I use this for vulnerability management, how I use this for procurement and GRC, when I want to go buy something new and make sure that I understand the risk of a piece of software when I’m about to buy it. 

DJ Schleen: 

Is that where people are right now is the sort of crawl, walk, run, and people aren’t even crawling yet when it comes to SBOMs. Or are they still trying to figure out, do I even need to generate them? 

Daniel Bardenstein: 

We work with some companies and have some companies that are very, very mature. They have their policies in place. They’re generating SBOMs for their internal applications. They’re starting to require SBOMs from all of their third party vendors. They manage the SBOMs, and then when somebody requested from them, they have a way to send it. , There are some organizations out there that are doing that, and it’s really impressive.

Vast majority of the companies out there that we interact with are more in the space that I’ve heard of. SBOMs, I still need to be sold a little bit on the value, or I am, but how do I get started? That’s a question we get a lot and help people on that journey.

 Then you still have folks who say I still don’t know what an SBOM is, please educate me. So we’re getting there. People are still trying to figure out how SBOMs can help them the most. 

The Log4Shell response is one of the strongest, sources of value. Having organizations understand that is a strong value prop for SBOMs. We work with some organizations that are actually starting to integrate SBOMs into their procurement processes. 

Healthcare customer wanted to buy a new tool and we got them to require SBOMs in their vendor due diligence questionnaire. So if you give us an SBOM, we’ll fast track through, so you don’t need to answer all these big, long sections of the dreaded Excel spreadsheet that everybody hates. 

The vendor was able to generate an SBOM pretty quickly. We helped them a little bit. They threw it up in the tool and we found some vulnerabilities. Nothing too crazy. But then it allowed the organization to then have an informed conversation with their vendor about, Hey, I know there’s some known vulnerabilities in this tool that you’re selling us. One of them has a pretty easy fix and is a little bit more exploitable. Are you willing to fix that? The other one we’re a little less worried about. 

 You can actually have a more informed conversation around making sure you have good SLAs from your vendor, making sure if there’s an easy patch if they can. And all that took was like a day or two, so it didn’t really slow down the proof of concept process that the pilot process that they were running.

DJ Schleen: 

Do you think the government’s going to do anything when they get these. What do you think they’re going to do with these things? 

Daniel Bardenstein: 

In the absence of the right tooling, not much. That’s a fear of mine to be honest, because not only did the government have to respond on its own to SolarWinds and Log4Shell, but they also had to look out for the broader US and global community.

So it would be a big lost opportunity if a bunch of SBOMs just ended up in a government teams folder. It is certainly my hope that especially as the entity that’s pushing a lot of SBOM generation, and we want the SBOMs that the US government also takes a bold stance and is public about here’s what we’re going to do with them, here’s how we’re going to operationalize them. We’re not just doing this as a compliance burden. This is data that will help us as the government do our mission better and their mission being, how do we help secure the larger business and IT/OT security ecosystem around the country and around the world.

DJ Schleen: 

There’s been a lot of pushback, from industry or the industry on software bill materials and providing them to the government. But at the same time, people are still trying to wrap their heads around these government comes out with the minimum required fields. Licensing’s not in there. Transitive dependencies aren’t in there. So it’s really high level and it seems like a spark for the industry to really take the lead on this and define what we do with these and how we transmit and manage them. 

Let’s take a step back to the SLA conversation with that healthcare vendor.

I started doing this at one of my previous employers where we would ask for our software bill of materials from our vendors as part of that third party risk governance. And we ask folks, do you have proper SDLCs in place? Do you check for static analysis? 

What happens when an organization in that use case, that healthcare company, gets an SBOM, finds a vulnerability in it that’s critical, and then says to the vendor, you need to fix this because this is part of my crown jewels now, and you need to fix it within my SLA, which is 24 hours, and the vendor has a different expectation.

How do you negotiate that? 

Daniel Bardenstein: 

I’m very curious to see how this plays out. What I would love to see is that those types of SLAs can be better negotiated by software consumers during procurements, during the initial negotiations, because they have the SBOM, because they have the information, they know it’s there.

That gives them better leverage to say, your SLA must be X-Y-Z, or must align with ours for our systems because we know, for many hospitals buying medical devices that they were contractually prohibited by, medical device manufacturers from doing anything to manipulate or manipulate the devices or try to put on any sort of antivirus, that was their words, but any sort of like additional detection mechanisms or anything to even trying to run some basic testing on these devices would avoid the warranty.

 Giving more information to organizations that buy software will help them negotiate better SLAs in terms upfront, given that they know, not just what is in this particular asset that I’m looking at right now, but over time they’ll get a sense of how does this vendor typically do when they put out new products?

I’d love to see the government take a bigger role in helping drive vendor side response and SLAs as well.

DJ Schleen: 

One of the things that I’m concerned with is if you have a full SBOM, you actually list the file names and you list all the libraries and you list everything. By giving that, that could turn into reconnaissance for a hacker. How do we ensure from either a product perspective, or is there technology out there that can look at the CIA triad, keep the confidentiality, the integrity.

 Let’s take privacy for example. How do we keep secrets, secret.

Daniel Bardenstein: 

I don’t think there needs to be a whole new, data privacy regime unique to SBOMs that you wouldn’t apply to your other sensitive business information or crown jewels.

 I think what would be very interesting to see, which would be a fun thing for either private sector or maybe even the government to do, is test that hypothesis empirically around does an SBOM give a potential researcher or red teamer more information that they otherwise would’ve had? Or how much of a headstart does it give them? We often hear this, oh, it could be fodder for a red team, both nefarious or non. We still haven’t seen that born out in practice.

 It’d be interesting to see if, it takes longer for them to actually sift through an SBOM and figure out an entry point versus just running their existing tools, it may be more of a moot point. 

DJ Schleen: 

I like that. we don’t have the empirical evidence around any of that. and not just in the SBOM case, but everything else. 

So we’ve gone through a couple of use cases. We have the use case of a organization requesting one and sending one. We have the inventory management and understanding where things are, like, do we have that Log4Java version that’s vulnerable. Do we have open SSL somewhere? 

What about vulnerability information? We hear a lot in the ecosphere about VEX and sharing of vulnerability information. How do we get that out of an SBOM for our listeners? 

Daniel Bardenstein: Let’s start from the basics. As we know, an SBOM just contains the list of software dependencies, versions, licenses. Plus a little bit extra, but really just describing, the software. 

There are some people. who believe that SBOMs should contain vulnerability information. , under the JSON blob that describes, the software and their versions, there should be another blob that contains all the vulnerabilities there. I count myself not in that camp. Vulnerabilities can change so much just in terms of their applicability, the severity and relative, respective information around them, even the CPEs that they impact. 

If the SBOM describes this more fixed state of the asset, how do we transmit information, again, in a machine readable way about vulnerabilities? VEX is supposed to be one of those answers… a machine readable file, like another JSON file that a vendor is supposed to put out that says, Hey, for this new vulnerability in this asset, these are the conditions under which it is actively exploitable or applicable for each specific customer.

Consuming VEX in a meaningful will require more effort for now from software consumers because they have to figure out… they have to take the VEX and say, okay, is this exploitable given everything? But then I have to understand all the machine readable bits and look at my current configs and see whether, it’s applicable.

DJ Schleen: 

Are we going to get to a place where we recall software, at least closed source software? What are your thoughts on recalls? 

Daniel Bardenstein: 

Literally just yesterday of this past week, the CISA director, Jen Easterly was giving a speech in Pittsburgh and mentioned security by design, secured by design. And she stepped into those waters. We need to move towards holding software vendors responsible for insecure code and product liability. 

My personal thought is that makes a lot of sense. I say this as somebody who runs a software company myself. You can’t always compare software to other industries. But it is pretty wild that in any other industry, if there’s something wrong, it’s the vendor’s responsibility to identify, to notify, to recall.

 With SBOMs, they’ll now be able to do it with software.  

DJ Schleen: 

Where do you see software bill materials going? Do you think that we’re at this inflection point or we even there where we’re thinking about creating all of this burden and this work and potentially automation file storage?

Do we go there or do things start deflating into something that’s more manageable and more realistic? Is this like an experimentation phase? 

Daniel Bardenstein: 

There’s value in the data and there’s value in transparency. If you start with the idea of there’s value of knowing what’s in the software that I’m about to buy, then the experiment is worth having. There needs to be a better, faster way to communicate information about risk. So SBOMs are just the first, foray into that. Of, Hey, we’re going to use JSON or XML docs to do that.

 My hunch is there will continue to be experimentation. The biggest obstacle is trust. As these experiments continue, the global community will establish more trust in, I can trust these risk notices that are coming out. Data can be used for good and for meaningful value. One feed of data, or you have 20 feeds of data in different formats as long as at the end of the day, by the time it gets in front of a user screen, it is clear and actionable and understandable. 

The user at the end of the day doesn’t care what happened to get there.  

SBOMs are still in the early phase of their maturity. There’s some big steps being taken. The journey is a worthwhile one. The market will most likely succeed if we continue to build tools that are user-friendly, and make it easier for even not technical users to answer these simple questions like, how much risk is there in the software I want to buy?

DJ Schleen: 

For the listeners that are out there who are just getting started with SBOMs, introduced to it, they may have never heard about it before now. What are the things that they can do to start the journey, 

Daniel Bardenstein:

Starting with the vendors can be a very easy lift. Once you write, or generate a basic SBOM policy, we wanna be able to X-Y-Z, have all new vendor questionnaires or evaluation processes require SBOMs. It doesn’t require engineering lift. It’s more of a policy lift.

And then at least, you’re collecting the data. You’re not going to solve all of your legacy problems, but you’re getting anything that net new has some sort of review. 

At least with an SBOM there are some tools out there that can help you do some basic analysis on them even one off. So you’ve already gotten some value there. 

Right now, this is a manual process, where you have to go out and ask all your vendors, or if they come to you, through the, vendor risk process, you say, on your questionnaire, give them an incentive. If you give us an SBOM you don’t need to necessarily answer certain questions about application security or SDLC, whatever is more germane.

 That’s the easiest way for people to get up and running with SBOMs. 

Then, making sure you put them in a single place. So you’ve gotten a couple SBOMs from your vendors. Put them in. It could be a folder to start. You have data, you can collect it somewhere. And then, once you’re starting to collect some SBOMs and requesting SBOMs from your vendors for the tech you already have, you have ’em stored somewhere, then you can actually turn your engineering or product security teams on. How do we do some basic analysis of this stuff. How do we run it through their open source scanners you can look at for vulnerabilities? You’re eating the elephant one bite at a time. 

Some of the hardest lift is usually when you’re trying to generate SBOMs for your internal developers and applications. It depends on the organization, but it helps to have stronger DevOps or DevSecOps types of folks that feel confident.

Here are the tools I run to generate an SBOM. Here’s how I automate it by putting it into the CICD pipeline. If organizations have stronger teams there, it can be fairly easy to say, Hey, go look at a couple of tools, build them into our pipelines and make sure that we can generate SBOMs without burdening our developers.

There’s a lot of small steps that people can do, but starting just with the requesting of the SBOMs, the aggregation of the SBOMs and some very lightweight analysis is kind of that backbone end-to-end workflow that’ll start to get organizations more visibility into their software supply chain. Then they can build on top of that and make it a little bit of a deeper implementation. 

DJ Schleen: 

This episode of daBOM was created by me, DJ Schleen, with help from sound engineer Pokie Huang and Executive Producer Mark Miller. This show is recorded in Golden, Colorado, and is part of the Sourced Podcast Network. We use Captivate.fm as our distribution platform and Descript for spoken text editing.

You can subscribe to daBom on your favorite podcast platform. We’re going to be releasing a new episode every Tuesday at 9:00 AM. I’ll see you next week as we continue to diffuse daBOM.

CycloneDX Project
SPEX Project
Dependency Tracker
OWASP
Sonatype