DJ Schleen: 

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.

Hey everyone. Welcome back to daBOM. I’m DJ Schleen. I’m here with Lisa Bradley from Dell. We’ve been part of some conversations in the past about Software Bill of Materials, and I reached out to you. I’m like, I gotta talk to you about what you’re doing at Dell and some of the history that you have behind SBOMs. 

One of the things that I really want to get into on the show is the pushback that SBOMs are getting in the industry, especially around vendors supplying them to the government.

 Before we do that, tell me a bit about yourself and especially how you got started in technology. 

Lisa Bradley: 

I’m a senior director at Dell Technologies in the Product and Applications security team, and I have our PCERT Initiative, it’s product security incident response team. And then I have the Security Champion, Security Training program. I have the Bug Bounty program, and then I have a customer security aspect where we deal with all this fun inquiries that come in from our customers about our security practices. 

I’m also responsible for the SBOM initiative for all of Dell. 

When I was younger, it was funny because I actually never knew an engineer. People are like, oh, who was your role model as an engineer? I’m like, I actually never knew one growing up. Most of my family members were teachers or in that type of field. But my dad really liked technology and he had a computer and he had originally one of those first cell phones, that was in the car and everything.

Really that’s where I just got into technology and played with it. But math was always my love and math yields very easy into computer science and programming in that world. 

DJ Schleen: 

So you have a PhD in, is it mathematics? 

Lisa Bradley: 

Yeah, applied mathematics. 

DJ Schleen: 

That’s crazy.

That’s part of the bigger thing about computing, right? When you get into the heavy mathematics, that’s crazy. That’s really awesome. When was the first time you touched a computer and you actually said, Hey, you know what, I’m going to start coding, because you had mentioned that you were a coder back in the day.

How did you get into coding? 

Lisa Bradley: 

It was just because I was a math major and they made you take some computer science classes. I really liked my computer science lab partners and I thought, oh geez, I might as well do a dual major. That’s where it came from. 

DJ Schleen: 

So you have a major in computer science as well?

Lisa Bradley: 

Yeah, my bachelor degree is in math and computer science. I had a dual major. 

DJ Schleen: 

What was your favorite programming language? 

Lisa Bradley: 

I learned in Pascal, so I’m aging myself a little bit. I did an internship and learned ADA, and then in IBM, which is my first job, I coded in Java. I think Java was where I ended my career.

DJ Schleen: 

Do you miss it? 

Lisa Bradley: 

No, not at all. I actually typically don’t tell people I coded unless they tell me that they can’t implement something. And then I’m like, yes, you can. I know you can. 

DJ Schleen: 

You got into security. How did you get into the whole security org? 

Lisa Bradley: 

It’s a very interesting question. I have three kids and I was on maternity leave with my daughter and I was at IBM and I was working on beta programs for WebSphere application server and they dissolved the whole team.

There was 60 of us and they said, you either find a new job or we’ll find one for you.  I reached out to my network and luckily I had a big network and someone said, I think you should talk to this person, I know he’s hiring. He interviewed me and said, I’m looking for somebody who’s not afraid to knock on doors.

I said to him, in the past two days I emailed 417 people looking for a new position, so I guess. I’m the person for your job. 

I actually had no clue about what security was, and I came into it and, really I feel like it’s the biggest blessing. It was definitely where I was meant to be in my career and will end my career in cybersecurity space, too. 

DJ Schleen: 

Fast forward to where you are at Dell. We’re talking about SBOMs here. What are you doing with SBOMs at Dell? 

Lisa Bradley: 

I’m very opinionated, so I’ll be very honest with you. I have a love hate relationship with SBOMs. I’m really excited about them because they’re helping push all the good things that we always wanted to happen within the company.

We always wanted teams to have an inventory of their open source and third party vendor products and keep them up to date. They always had some form of an inventory. But this is forcing that, pushing the limits. 

It’s allowing us to be able to utilize that to make sure that we’re not on end of life, open source and keeping up with our vendors and then having stronger vendor contracts because we now all know all the vendors that we’re utilizing.

 It’s really helping in that place. 

Where I’m not so always keen on is sharing my SBOM to the world. 

So, fun story. Me and Allan Friedman at a RSA Conference were hanging out at one of the after parties and I kept on tapping him on the shoulder and was like, are you affected? Are you affected? Are you affected? 

 I was being that annoying person that’s going to have my SBOM constantly ask me if I’m affected, when in fact, I may not be affected. 

I am, always concerned of the amount of extra work that an SBOM is going to cause because of the customer panic when really my focus is to make sure that we’re handling our third party code and keeping it up to date and knowing when we’re affected by something and when we’re not, and not having to answer 5 million questions of our customers when the next open source vulnerability comes out.

DJ Schleen: 

Wow. So there was a couple of threads that are going to come out of that one. Let’s talk about the inventory side of things first. 

When you’re talking about inventory, what do you do with these things after you create them? How do developers deal with them? 

Lisa Bradley: 

I don’t think that the developers themselves are really going to be the ones that are handling with it, but more the security team that’s going to help support the handling of it. 

SBOM was such a catchy word, right? Everybody was talking about it. But the real crux of what we want is we want to protect our customers against vulnerabilities. 

Dependency management is the real key here. 

If you have a system that can have your SBOM, understand the SBOM, map it to new vulnerabilities that are coming in, and then have a programmatic way to notify those product teams that they now have new vulnerabilities, and then they address those vulnerabilities… you have a security update and you put out a security advisory say, Hey customer, here’s my update. That’s really the end goal. 

That’s one of my other problems with SBOM. Unfortunately it outshined the whole reason. And I have to like, explain people and be like, no, SBOM is just one aspect. Protecting our customers against vulnerabilities is really the use of it. 

DJ Schleen: 

Does the security organization at Dell handle all of the SBOMs? We have VEX, we have VDR, we have, oh my gosh, how many different specs from how many different places to describe what a vulnerability is.

Is that something that you take on as a security team after you get these SBOMs from, CICD process or from a developer engineer? 

Lisa Bradley: 

Yeah. Yep. That’s what my job is responsible for. I’m in charge of the whole dependency management ecosystem to making sure that those product teams are aware about the vulnerabilities.

If you think about the evolution here, it used to be for open source that maybe you would subscribe to some email. And you would be like, oh, OpenSSL. You get an email, Hey, there’s a new vulnerability. Here’s the update. But, we’re consuming so much open source. So having a platform is really the nirvana, the perfect vision for me of being able to successfully say, I have a mature vulnerability response program where I can always know about the risks that we have. I can clearly indicate that to the product teams and they could take some action. I do think that having that centralized system that feeds in the SBOMs feeds out into a ticketing type of system. which most companies have a ticketing system or a special ticketing system just for vulnerability management.

That’s the perfect picture for me. 

DJ Schleen: 

Have you found anything to actually do that, or is this a homegrown type of activity to actually make this centralized repository of, sorts and get all those integration points in? 

Lisa Bradley: 

We’re utilizing, a product that exists out there in the marketplace, one of the initial SCA type product. They’re evolving with us. A lot of those products started as just helping with open source because of licensing. Then they got it into the vulnerability part. Now they’re getting into the SBOM and the full dependency management. 

We’re growing with them and luckily they’re listening. We’re heading in the right direction with the industry and the product lines that we could utilize.

DJ Schleen: 

Do you ingest any SBOMs from those third party vendors? 

Lisa Bradley: 

We’re working on ingesting them. I would say the majority of the people in the industry, even the big vendors, are just figuring out how do we deliver SBOMs successfully to our customers. Which customers do we even give the SBOMs to at this point. Because there’s a risk with sharing information like that. 

Some of our vendor contracts are older. There was no such thing as an SBOM in our vendor contracts. Evolving our vendor contracts to make sure that SBOM is an aspect of it, that we could legally ask for it through our contract, and then they have to abide. So there’s like a lot that needs to happen in the picture here in order to get SBOMs for our vendors.

DJ Schleen: 

So when we talk about transmitting and receiving these SBOMs, you mentioned that this is an emerging type of problem space that we have to deal with. You mentioned before your love hate relationship with SBOM. Part of it was sending your SBOMs to other vendors or like your customers.

Is that like we’re releasing our secret sauce or divulging confidential information, or… 

Lisa Bradley: 

I don’t think it’s confidential information. I don’t think it’s information that we’re afraid for our customers to have. The fear is always to put that information in the hands of somebody that could hack us.

Yes. A lot of the times, if people are poking around, they’re going to figure out what open source we’re using. However, it’s more easily figured out when you hand them the recipe. 

We’re trying right now, especially as we’re still on our journey here to be really smart about, ” Is there a contractual reason to give somebody an SBOM right now or not?” What is the risk and how do we share it with them? How do we store them? All these things we’re figuring out as we go, because this is a whole new initiative. 

 I say it’s a new initiative. Not that wasn’t an initiative to know your inventory before, but having SBOMs, having to have multiple versions of a product, multiple versions of the SBOMs, making sure the right ones, get to the right customers.

There’s a lot there. Especially when you have a significant, product portfolio like I do in Dell. 

DJ Schleen: 

When we’re sharing those SBOMs with those vendors, we have the contractual information. We’re probably under NDA. We have mutual NDA with those folks. I completely agree with you. These could be some like downstream supply chain attacks that happen if that SBOM leaks out, or if there’s not the appropriate security controls around storing that data. Is that correct? 

Lisa Bradley: 

Yeah, for sure. If there’s a vulnerability in OpenSSL tomorrow, my teams and all of my products aren’t going to be able to turn it around and get that update and put the patch out the next day. It takes some time. Especially with some of these big servers and stuff. Like the build environment takes a significant amount of time. All of that time it’s out there knowing that we most likely are impacted by that vulnerability. 

With open source, the code is publicly available. It’s easier to exploit because the code’s there. It’s always a risk. There’s a lot of things that we’re doing, and this is why SBOM is just one aspect. The bigger picture is how do we, you know, address our vulnerabilities faster? How do we ingest open source or our vendor codes so that we quickly can get their security update and then pop out a new update ourselves for that product.

There’s just so many more things that are evolved with this picture in order to be successful in protecting our customers. 

While I want to focus on SBOM, I want to focus on all these things. I want to make sure that we’re maturing with all of our practices so that we could actually do the right things when we know what the right things, to do are. Meaning, how quickly can we turn around that OpenSSL vulnerability and get that code back into our customer’s hands that’s now protected against this vulnerability. 

DJ Schleen: 

Do you provide vulnerability information when you deliver your SBOMs, like vex or VDR or anything like that? 

Lisa Bradley: 

So we’re spending a lot of time on making sure that we could programmatically generate our SBOMs. Then once we have all of that in our pipeline, we should be able to spit out those SBOMs really easy. 

At the same time as we’re working on that, we’re working on our VEX strategy. What does it mean? How can we be smarter to actually know when something’s impacting us or not? A lot of the tools have false positives. How do we get that message very clearly? Because, I really don’t want the customers coming to me all the time asking me if we’re affected. I want to have that VEX out there for them to quickly, and programmatically know, yep, they’re affected. No they’re not. Or they’re still analyzing it. 

Then on top of it, because this is a whole big story, it’s a whole big ecosystem, I’m working on making sure that our customers clearly understand where our products are ending their security support life, and when our products are going to release their security updates so that my customer might say, Hey, my SBOM I imported your SBOM. It’s indicating that you use OpenSSL and there’s a new vulnerability that came out.

Then being able to look at the vex, being able to know if I’m affected, being able to look at my next update cadence, know when they’re going to get it fixed, and then they don’t have to question me. They know exactly when it’s going to come and all the information about it. And they programmatically could get it all at their fingertips.

That’s the fun picture. That blow your mind? 

DJ Schleen: 

That actually makes sense because it gives the listeners a practical use for using VEX. I always think like, how do I find out if I’m affected by something? Do I use like traceability tools or do I look up the call chain and say, oh, we’re not affected by X, Y, z bug.

 How can that be handled in a non-manual way? Have you crossed that threshold of figuring that out yet? 

Lisa Bradley: 

Right now we have a vulnerability response tracking tool for all of our vulnerabilities.

Where I don’t think we’re at yet, and I believe the industry is heading into, is to have more intelligence into being able to say, yes you’re impacted, besides an engineer having to go in and say, yes, we’re impacted. 

 There’s different packages and it may be that you don’t even utilize that package. If the scanners can understand that you’re not utilizing that package, then they could give you a high probability that you’re not impacted. 

 It may be that our VEX potentially even evolve to have an indicator like a programmatic tool indicates that there’s a 90% chance that it’s not impacted. So we’re not specifically saying not impacted yet, but it’s some programmatic way 

Also, if we think about the vulnerabilities that affected us in the past, then if there’s a vulnerability in that same type of component within maybe the software that we’re resolving, OpenSSL for example, that we already were affected by a similar vulnerability in that component before. Therefore there’s a high probability that we’re probably impacted again. 

All that information, if you have that, yes, we are impacted, no, we weren’t impacted in a ticketing system, could all tie together to have more intelligence, so then an engineer doesn’t have to do a significant amount of work to have a quick indicator to a customer if we’re impacted or not.

That’s my story. 

DJ Schleen: 

Dell produces firmware, software, hardware. Are you planning on, or are you implementing any other kinds of BOMs in Dell and in the processes that you’re defining?

Lisa Bradley: 

We typically already have the BOMs for a lot of our hardware out there. I don’t think they’re in a formalized way, but the information is usually open and transparent. We haven’t evolved in that space yet because right now our focus is to make sure that we’re meeting the regulatory ask of SBOM that are within the Executive Order.

DJ Schleen: 

Executive Order 14028. How does that affect what you’re doing with SBOMs? 

Lisa Bradley: 

I mean, that was the main driver. Dell has a significant amount of product portfolio and customer base. We want to make sure we’re not going to limit our customer base because of these regulatory acts that are coming after us.

We take it very seriously. When the executive order came out, we had a whole work group that was put together, different players across the business. Security was the main orchestrator. We had of course legal evolved very heavily. We figured out where did we have some weaknesses? Where are we good at? Where did we have room to grow? SBOM was one of the places we had room to grow. 

Now we have our SBOMs for the significant amount of our portfolio. We now feel like we closed that gap very quickly, although we want to continue to keep closing that gap and making sure that we could have every single product, every version that comes out, all programmatic and not manual, having those SBOMs. 

DJ Schleen: 

Can we meet those expectations that are being put on the industry? 

Lisa Bradley: 

I would say some of them are very unrealistic. For example, there’s thoughts of no vulnerabilities. Product self-ship with no known vulnerabilities. The next day there’s vulnerabilities. 

To be honest, there’s a lot of people I love that are making these decisions, but they haven’t usually worked in a vendor environment. They’re making these rules that make sense logically, but like we need to have a pathway through there.

With SBOM, when they asked for feedback back in the day, two years ago, that was one of the responses we had is, we need to phase this approach. There’s a phase one, there’s a phase two, there’s a phase three. If we don’t put in the phase and we just jump all the way to the end, no one’s going to be successful.

You’re going to have companies that are going to spend a significant amount of money just to meet that end thing when you probably want them to have an email address where vulnerabilities can be reported to by researchers. Let’s get some of the basics done. 

We need to give them the guidance of this is your basics, this is where you start, then here’s your next level, then here’s your next level. Sometimes they go to that final maturity state and they don’t provide that journey and path to get there. 

DJ Schleen: 

With the large companies like Dell and Intel, you’re really setting the stage in working with the government organizations to influence where the SBOM community goes and where SBOM technology is going, what the regulations are behind it. But you’re also setting an example and setting the stage for smaller organizations to not really go underwater to try to figure this all out themselves. 

Lisa Bradley: 

That’s exactly my point. If you go and tell these smaller companies that are just starting up their security teams and saying, you need to have SBOMs for everything and you need to be this, and this, and they don’t even have email that a researcher can report a vulnerability and then know how to follow the process to make sure that a vulnerability gets addressed and communicated to their customer.

All of that process, the policies, the tools all behind there, like that takes a significant amount of time and money. That’s where I think the regulatory part we have to be careful of is that we have to make sure that the core of PCERT and SCL , we’re letting companies be successful in that first.

Then the other things that are on top of it SBOM being one of them is a continuation of our journey as we mature to make sure that we could best protect our customers. 

DJ Schleen: 

What would you recommend to a startup or to a small organization based on what you know and the problems of figuring out what to do with SBOMs. What would you recommend they start with if they have nothing. 

Lisa Bradley: 

I would say learn from others. There are people who’ve been in this business for a long time that already have really mature practices. Most of us are very willing to talk to them. Most of us will be buying from them. They might one day be our vendor. So we want them to have good security practices because my customers expect my code and everything to have good security practices. 

That means if I consume something, it needs to have the best security practices too. A lot of companies aren’t utilizing all the resources around them and learning from others around them. 

LinkedIn is so powerful. Reach out in LinkedIn, say, Hey, I need some help. I’m trying to learn about PCERT. Can you help me? Most people are willing to talk and help. 

So that’s my suggestions. Learn from everybody else around you. Figure out what your first priority is, your highest priority, because you could get overwhelmed very easily of all the things that you want to do.

DJ Schleen: 

Where do you see SBOMs five years from now? There’s a lot of different ideas out there. Where do you see this? 

Lisa Bradley: 

Oh, in my perfect world, I would see them even being somewhat obsolete. Right now we spend a lot of time and energy trying to understand the vulnerabilities we have and the open source and the vendor code that we’re using, and figuring out which issues impact us and don’t.

If we just could get better of always getting the latest and greatest open source and being able to pull it in programmatically into our environment, then we don’t have to stress about what vulnerabilities are in it because our natural practices are always pulling in the latest. 

I’m hopeful that we’ll get there someday, in my lifetime, that they could become obsolete and that everything is just magical and we’re always automatically pulling in the latest code.

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 Sourced Network Productions. 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.