The Security Table
The Security Table is four cybersecurity industry veterans from diverse backgrounds discussing how to build secure software and all the issues that arise!
The Security Table
An SBOM Lifecycle
Aditi Sharma joins Matt, Izar, and Chris around the Security Table to discuss Software Bill of Materials (SBOMs). The team discusses potential advantages as well as challenges of SBOMs in different contexts such as SaaS solutions, physical products, and internal procedures. The episode also explores the importance of knowing what software components a company is consuming and the significance of SBOM for vulnerability management and risk posture. The team concludes by stressing that while SBOM has great potential value, the value realization is still a work in progress.
Links:
Chris' LinkedIn post about the SBOM cycle: https://www.linkedin.com/posts/securityjourney_where-is-the-part-where-the-vulnerabilities-activity-7128757968740777986-0PQV
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel
Thanks for Listening!
Oh, what a way to start with a bunch of people laughing. So, hey folks, welcome to another episode of the Security Table. Uh, it's probably not a surprise. We're actually having fun before we hit record. Then we hit record and we continue having fun. We're recording this on Friday, November 10th, which is Veterans Day observed here in the United States. And so we just want to say thank you to all of the veterans out there. We know we have a lot of folks in our community that are veterans. We appreciate you. We thank you for your service and, uh, just, just wanted to recognize you right off from the start here. And so we're going to talk about a lot of different things today. Like we always do, like I wish we had one topic, but you know, that's not really what the table is about. The table's about having a conversation about security things. And sometimes other things pop in. But we do have a special guest here, Aditi has joined us. And so Aditi, if you could just give our audience just a high level background on you. Like, what's been your cyber security background story, experience, kind of, what's your perspective, where you're coming from. That'd really be great for us to hear.
Aditi Sharma:Yeah, of course, thanks, Chris, for having me here today. Um, I love all your podcasts, first of all. Um, so just about me, I had an app happy accident of getting into security almost five years back when I was working for, um, a customer, you know, for some online application, I, my. My background is mostly around, you know, product manage, product management and business analysis, data analysis. So, I started my journey from automotive, telecommunications, and now I'm into security. So, just a happy accident working through different software solutions, and now just leading some. Uh, new software solutions into security.
Chris Romeo:Okay, so kind of your current focus then is on AppSec, product security, integrating security into basically into software, that's kind of your primary focus now?
Aditi Sharma:My primary focus is, uh, mostly around best practices, um, and product security, compliance, uh, attestations and all of that.
Chris Romeo:Okay, very cool. That helps the audience just to have a little bit of a frame of reference of where you're coming from. You know, when you start yelling at Izar, like everybody else is going to do, um, they'll at least know why. They'll have some idea as to why, uh, but we don't really yell at Izar. No, we just, this is, this is a fun, a fun space, maybe a little bit. Um, so we're going to go some different directions, but I put this. This picture on LinkedIn that I want to, I want to start with because I found this thing in the, uh, the new SBOM consumption guide that just came out and it was an SBOM lifecycle picture and we'll put the link to the post in the show notes just so you can see what it was, but the, the challenging thing about it is I found it didn't have any place where vulnerabilities are being fixed. And so I'll just describe the picture since I don't have a vision, a view of it up. It's SBOM delivery, it's, the doc, the document's called Securing the Software Supply Chain Recommending Practices for Software Bill of Materials Consumption. It has a life cycle, figure two, SBOM delivery, acceptance and validation, ingestion and parsing, extraction transformation and loading, and mapping and asset management. And I sat here and I said, I consider myself to be mildly intelligent. Where do we fix the problems in this life cycle? And then it kind of hit me, like, this has been the thing I've been railing against for the whole time I've been on my soapbox about SBOM. The fact that there is... No focus on actually fixing anything. And so I bring that to the security table. I throw the virtual piece of paper down and I can tell there's already people are, I can see it in everybody's eyes. They're already ready to, uh, to let me have it. So Matt, you were shaking your head first. So what, uh, what are your thoughts on my conclusion here?
Matt Coles:Well, I, I think your conclusion is actually, is good in that there isn't a focus on it. Uh, and maybe that's, that, that's the missing part, right. Is the, is the focus on. What, so what SBOM is for, and we really should let, you know, Aditi give the definition of what SBOM is because that's, that's, that's her, that's her area of expertise here. But, uh, having, not having a focus on, on the outcome of why an SBOM exists, um, is, is, It's unfortunate. I'll just, I'll just start with that. Um, but before we dive into that actually, so Aditi, can you sort of give us in your own words, we do, we love to work with definitions here. We start out with definitions. That way we level set for our audience. Can you help our audience understand what an SBOM is?
Aditi Sharma:Yeah, yeah, of course. So SBOM, aka Software Bill of Materials, is, uh, is basically the inventory of your product. Um, and the inventory of this product can have, you know, open source software, any commercial dependencies that That you're using and even the proprietary information that you know, you're, you're coding in house. So NSBOM is basically, um, you, you have heard the analogy with the food ingredients list that goes behind any, you know, whatever food item you're buying. The analogy goes with that a lot in the industry today. But it's, it's basically just, you know, um. The inventory of what your product is made of and it can have a level of depth to it. It could be just the top level. You could go beyond it. You know, second level, third level depends what level of vulnerability management you want for your organization, because ultimately the main use of SBOM is for vulnerability management. So that's, that's
Matt Coles:Okay, and so, and so in that,
Aditi Sharma:Matt.
Matt Coles:in that Correct me if I'm wrong here, but in that the SBOM gives a set of, a set of things with a bunch of, with potentially with vulnerabilities. That's not the end of it, right? That's not what, that's not the end goal, right? It's not just a list, correct? So so to Chris's
Aditi Sharma:no. So it's.
Matt Coles:go ahead, go ahead.
Aditi Sharma:You can use the, it's, it's about having that information and then how you use that information. Having that information is really important, so that first of all, you know what you're consuming, because as you're increasing the size of your organizations, the asset management piece comes into picture. And for that, you need to have your basic infrastructure ready. So once that is all set, as you have vulnerabilities coming in, as you want to know, where am I impacted? It's easier to find your way into that system. So... Think of, think of, um, having, um, to find, uh, you know, an issue into, like, for example, the peanuts, you know, peanuts allergy. Unless and until you won't know there is peanuts in your software, oh, not software, in your food. Uh, how would, how would you know? So you just got to know what's in your software. So it's, it's just about that. It's, it's a, it's a, I just, I always be like, it's a driver for something, something more. It's a static document that is created for every release, but how you actually make use of it will actually serve its purpose internally or for your customers.
Chris Romeo:So I'm tracking with you so far. I'm tracking. Go ahead, Izar.
Izar Tarandach:But if it's a static document and we live in an era that I think that I can safely say most of what people use every day is SaaS I don't see the significance of that static document for SaaS
Chris Romeo:So, hold on, I just want to confirm. You said SaaS, software as a service, not
Matt Coles:SAST,
Chris Romeo:Right. SaaS, software as
Matt Coles:SAST
Izar Tarandach:Yeah. Yeah. That's the other one. No, no, not, not even by mistake. That's, but, uh, No, no, no, so, uh, yeah, so what I'm trying to understand here is first the practice, the, the, the use, the usability of the thing for the public at large. So are, are we, here's where my, my biggest fear lies at this point. Are we creating yet another industry that we are going to feed? And that's going to be a thousand different startups. And that's going to be a thousand different standards. And it's going to be a thousand different solutions. And we still can't look at it and say, Oh, this is what I do? I mean, I recognize that it's good to know if there are peanuts in the salad. That's awesome. But, where Devalogy breaks for me is, it's not even that there's a lot of people who are allergic to it, there's a lot of people who are not even eating it. Who are not consuming it.
Chris Romeo:Well, if you keep pulling on the thread of that analogy, right, where it breaks down when you bring it to a software context is, I look at a list of ingredients, I see there's peanuts in it, I'm allergic to it, I throw the salad away. I'm done. That's the end of the con that's the end of the transaction though, right? Like, and my whole point here with this, and I started to go the same direction, Izar, you did, when we think about software as a service, you can't just shut it down because you got a bad SBOM result coming in. From, so you have a vendor, let's just, go ahead.
Aditi Sharma:In
Izar Tarandach:But if you're in a position that you are a SaaS user, you're not even going to fix that thing. So you just got a piece of information that's absolutely not useful for you,
Aditi Sharma:in the end, now, the second piece
Izar Tarandach:don't remember if we are going into it today or not, but now you have VEX that can explain to you, hey, why it's not so bad. So that has more of a, uh, usefulness to me than the SBOM itself. So now as part of that ecosystem, we are creating other documents that help clarify that ecosystem.
Matt Coles:so before we get into VEX, let me ask
Aditi Sharma:And that could be true.
Matt Coles:ahead, go ahead. Aditya. We run over each
Aditi Sharma:No, go ahead, Matt. No, go ahead.
Izar Tarandach:no, no, I'm the only one that speak over people here. Yeah.
Matt Coles:Uh, so... So, Izar called out having an SBOM for a SaaS service, and how, uh, you know, there's no action for the user. If they look at the SBOM for a SaaS service, they're like, ah, you got peanuts in there. And then, they can't do anything, because either they throw away the SAS, they either stop using the SaaS service, or they wait for the vendor to take action. There's nothing they can do. So, first off, is SBOM, is SBOM even a valid option in... For, for, for providers of SaaS services, or does SBOM really come into its own when we're talking about on prem products, package software, things that get delivered to customers, um, and, and where the customers would then have actions that they could take based on what they see in that, you know, they could, they could throw away the salad, so to speak, or they could pick out, pick out the peanuts.
Aditi Sharma:Yeah. If you, if you look at the, if you look at the, um, the executive order that came in, it, it also focuses mostly on on premise. Um, it focuses on products more than applications. It focuses more on, you know, actions which a customer can take in their own environment for, for, you know, um, if there is an action that has to be taken, if a patch has to be deployed and what not. With SAS, it's a, I, I feel like it's maturing, that space is maturing and what is not applicable in a SaaS environment, it's not. Not everyone has to consume it. It has to have, it has to work for your business. I, I really see SBOM. it is a compliance and all of that. But what is right for your business? What is right for your product? And a lot of companies have applications who are products, right? For example, there are so many CRM Um, products, which, which are literally applications, but they are a product for a company. So how do they want to manage their internal vulnerability management by understanding the software they're consuming? So this is more around what, where do you want to take your own security posture? How do you want to track everything within your systems? So
Chris Romeo:That's what I
Aditi Sharma:if you want to make use of, use of it, you should.
Chris Romeo:On the topic of SBOM and understanding kind of the usability behind it, I had a chance to catch up with Steve Springett via LinkedIn thread. I've been trying to get his opinion on this as far as the usability of SBOMs in the context we're talking about, where you're receiving SBOMs from an outside source and then trying to gain value from it. And he admitted as well that the the sharing nature of Uh, or value from sharing those things is limited at this point. So that was kind of, I guess, some of the conclusions I was hoping to, to get to is, I did want to go in another direction here because we did talk about SaaS, but let's reframe this in the context of just a physical product. Okay. Cause I think you have the same problem in a physical product that we described in the SaaS, but I want to bounce this off the table. Um, so imagine that we have a product that I've purchased. I'm the consumer, I'm the customer, and I'm getting an SBOM, set of SBOM sent to me via this life cycle we're talking about. I have the same problem though, if there's a big issue that the SBOM identifies. Because like, I can't, if I bought a network device, I can't just turn the device off. So yes, I have better visibility from a risk management perspective, but I can't really do anything. I'm still at the mercy of the vendor. And so, or does that change the game? Does the game change in the two scenarios we've been working from? A product versus a SaaS solution,
Aditi Sharma:So, it depends, um, if you are on the customer side or you're on the vendor side, um, so your actions would depend on, um, if you are a customer, you can go to that, you know, you can go to that vendor who is providing you that solution, right, that, okay. We have identified this issue. What are you doing at your end to get it fixed? But, but if I am the consumer, or you know, vice versa, it's just about knowing what is the issue and then where you go about it. Maybe it's an internal issue because that way you can even find out if something going on internally is wrong. And if you want to talk internally with your product teams and all those business units. You just take an action accordingly. So really depends on the perspective of what, which side of the chair you're sitting. That's just my
Matt Coles:so if, if I could, if I could, so what it sounds, what this sounds like then is, um, to Chris, to where you're going with this is if we talk about package software, a product, whatever, um, where the vendor doesn't give, uh, capability to the customers to apply their own patches. Um, from upstream. So let's just say we, for a moment, we're talking about software that embeds Java, you know, log4j, for example, right? And because everyone loves the beat on log4j, uh, there's no other components that exist that have vulnerabilities. Never, ever open a cell. Uh, so if you have a, if you have a system has a, you know, log4j, but you don't give the ability for the customer to go and apply a log4j patch as soon as it's available, then really the SBOM is telling you, Oh, you have, there's a, there's a component in here, it's called log4j, and oh, by the way, you can go look at its vulnerabilities, and you don't know if the vulnerability actually impacts the product at that point, using just the SBOM, but you can then say, Well, maybe this becomes more risky. I want to take it out of my DMZ, and I want to put it more into a closed network, or I want to change its network properties. I can add, apply mitigations to it.
Chris Romeo:I need clarification on something you said because I may not understand how the world works and that could be part of the problem here.
Matt Coles:do we ever understand how the
Chris Romeo:You described a scenario where I can buy a product. But yet, I can patch library versions of that product itself. I can patch the, I can patch the library myself, even though it's a packaged piece of software I bought from somebody else. Is that a thing that I just don't know about in the world?
Matt Coles:I don't think it's common. Certainly, I don't think that's a common thing. I'm thinking about, so, certainly if you buy Linux. or acquire a Linux version from somewhere, you could potentially patch that, right?
Chris Romeo:Sure. Of
Matt Coles:Say you buy it, say you buy a Chromebook, right? That Chromebook has applications that come with it. You can independently update those things, potentially yourself. You can side, you could side load if you want, right? Android does, or Chrome, you know, provide those, those options. Um, you could potentially apply patches from an upstream provider yourself. Um, there's a host of things you. could do. I don't think it's common, so I wasn't describing sort of a common thing that, you know, if a product is based on Linux, that it, that you get direct access to a shell to be able to, and a, and a, and access to the repository to be able to add components or modify components yourself. Although I imagine that does exist.
Chris Romeo:Yeah, because I think of, I think of products in the closed category. Meaning I get a metal box, it has a piece of software that includes software, firmware, and everything, but I don't have an interface to even really profile what software is there. I definitely don't have the ability to update the software. Because I started thinking about the QA challenges that exist there. If I update, we know what happens, and that's one of the big challenges in supply chain, right? I update a package. And it breaks 27 other things, other features that we don't even know why it's breaking. It doesn't make any sense that that thing over there is breaking. But we updated the package, apparently there's a dependency to it, and some new version broke the API, broke the library calls, and now that thing doesn't work either. So, um,
Matt Coles:So you're,
Chris Romeo:glimpse though, Matt, I thought you had solved my problem. I was like, maybe there's something I just didn't understand. But I
Matt Coles:yeah, not as far as I know. So really what you're looking, I think what you're looking at is you look at the SBOM, you go, oh, that, this has a component, this component has a vulnerability. The vendor hasn't supplied me with the ability to update that yet, and I can't do it myself, so I really have to take mitigating, you know, have to put in compensation controls or mitigating techniques to reduce the impact of that vulnerability. And that's the, the benefit of SBOM is really visibility so that you can make proper risk management. Not perfect, certainly, but it's a start. I think
Chris Romeo:You're onto
Matt Coles:a value there.
Chris Romeo:You're onto something here that I was missing. The SBOM as a driver for compensate other compensating controls. That may allow me to get visibility to, whereas in the past I might not have as much context. I might know that there's a giant OpenSSL vulnerability about to hit, but I don't have the context to know where I need the compensating control to go, right? I might be, I might be having a breakthrough here, but Izar's gonna break, he's gonna crash it for me.
Izar Tarandach:no, it's, it's, it's, okay, it's, it's like this. So, you, you had Steve in your thread saying that, yes, something is still missing. And it was something pretty basic, right? On the other hand, I, I, I have had the pleasure of, of speaking with Steve on other occasions, and, and learning from him, and understanding that the SBOM universe is being, Expanded to cover all kinds of things that we didn't think we... Some even thought about a threat modeling SBOM, and reachability And I keep going to thinking, we haven't figured out yet even the basic, how to consume this thing. And we are already talking about the new generation, next version, warp core, going ahead,
Chris Romeo:Ha
Matt Coles:Where's my sign? HBOM is a thing, right?
Izar Tarandach:Right, so you know to just bring me back to the basics, you know, just just give me some value value the hype for me right now I mean, I don't want anybody to misunderstand me and I think that you guys agree with me We see huge value in this thing, but so far it is future value It hasn't been realized yet and there's this huge momentum behind building this thing Yeah, let's get all the ducks in a row, then let's know what version the ducks are and what color the ducks are and where the ducks are coming from. Now
Matt Coles:And now what?
Izar Tarandach:just put them in a pond and forget them because I don't know what to do with the ducks. Heheheheh.
Chris Romeo:All right, so Aditi, you've been listening for a while here now, like, what's your take on this as far as this mini breakthrough I may have just had, plus Izar's, uh, pinpointing the fact that we do think SBOM is good, but it is a future value challenge.
Aditi Sharma:So, um I have seen in so many, you know, in my past five years journey of security, you will not get a benefit of security immediately. You will get the benefit of some security related actions when the time comes. So, since we brought Log4j, say you identify there's a Log4j vulnerability and you have to find out what all... Assets in my company are affected. What are you going to do about it? You will just go to it. So I always say SBOM is like the final name, but in the back of it, the engine is all your inventory management, whatever tools you're using, right? You just go back there and then you can do a simple search. Okay. What are my key products which are impacted? It's so first of all, it's a way to find the impact area. Second of all, When you connect the information with the CVEs which are available, then you can have a proper dashboard in front of you, where these are the components, these are the vulnerabilities, what is my status. So it's Alone, it will tell you, it will help you do your asset management together combined with CVE, you can do vulnerability management. So, it's a couple of process, it's not that straight forward, how people say it's a push of a button. It takes a lot of work behind the scenes to actually get that. Quality SBOM, quality inventory in place, because it's, it's not going to happen day one, it's a process and a lot of it's, you know, it's manual, then you go to automation. And so it's, it's not that straightforward, but its value is only when you try to see what is working in your application. Thank you. Um, in your ecosystem, how can you make use of it?
Izar Tarandach:So, I I totally get what you're saying, sorry. I I totally get what you're saying, Aditi, and and don't don't see this as a personal thing, it's just me
Aditi Sharma:I'm not. Yeah.
Izar Tarandach:Once you have an SBOM, and you have a CVE, and you know the package is... impacted. It's going to take like, what, a five line bash script to grab through your SBOMs and figure out where the CVE lives. And instead we have this huge industry shaping up. And I think that we all have been brought up and educated on the notions of small increments and showing the use as those increments go. And I go back to, okay, I get the use, I get the solution, we have a way to do the SBOMs, we have a way to consume it. But there are huge increments happening in this industry, and I'm not seeing those small leaps in usefulness. I'm just seeing, yeah, we got that case. We know how to read, how to grab SBOMs for things that have log4j in them.
Aditi Sharma:Yeah, it's, it's
Izar Tarandach:is the future?
Aditi Sharma:also think, so from government perspective, what I think, and this is just my personal opinion. When, whenever solar, you know, I think it was solar attacks, when, you know, after eventually, then Lock4J and SolarWinds, sorry, SolarWinds, and then Lock4J, and then eventually this came out. How I see it is, Um, sometimes, um, they want to know what open source you're using. Where is it coming from? Which country is it coming from? So, in the grand view, um, it's not just about vulnerability, but also, where is that software coming from? So that, so that, if you look at the executive order, what they're saying is, Hey, we will do the purchase from you only if you let us know what's in. What is in the, in the product that you're selling us? So it's, it's a national security issue at that point of time for them. So, so that's their business, right? That's what I'm saying. What works for you as a business, because that's what is working for them. And then to just make it work for everyone. Um, also there are so many tooling companies now coming up. It's, it's all also helping, helping it as a business for them. So. All the sound because everyone wants to innovate in this field. Everyone wants to be ahead of each other. So now it's a competition somewhere.
Chris Romeo:Here's, here's my, I want a business, I got a business idea though. I want to, this, this could be the solution, Izar, to what you just described as the problem. It's going to require AI though, okay?
Izar Tarandach:God.
Matt Coles:Why
Chris Romeo:No, no, no, stay with me here, stay with me here.
Aditi Sharma:AI bomb!
Chris Romeo:I think I, I think I can wrap blockchain into this too, hold on. AI, blockchain, and SBOM together, okay?
Izar Tarandach:Only if you DAST it at the end.
Chris Romeo:not doing that. I refuse to do that. I will not add that into this in this. Okay, so follow me here. Okay, we've got SBOMs. I as a customer am saying I want SBOMs, okay, for the piece of software that I'm buying. Between what this, what this new solution from this vendor provides is, I enter into a smart contract using blockchain between myself as the customer and the vendor that says what the terms of fix are going to be. And then they use my AI agent to actually patch the vulnerabilities according to the smart contract that we've agreed upon with timelines and deadlines for when things have to be patched. So, I mean, I think we got a business idea here. Let's start a company. Let me call my legal team and see if we can get a company.
Izar Tarandach:let's call it Know Your Business Inc.
Matt Coles:Why does it even need, why does it need ai? That's,
Chris Romeo:Well, because you can't patch fast enough. Right? You can't, you're not going to be, that's the challenge, right? Is like vendors always can't patch fast enough to keep up with whatever the accepted contract. So like, if you could give me a patch and a patched version an hour after I, after the SBOM hit that showed I had the issue, of course then I probably don't need the SBOM
Izar Tarandach:I feel
Chris Romeo:to make SBOM clear.
Izar Tarandach:I feel like I am in a beehive for the amount of buzz around here.
Matt Coles:You're, you're, you're more, you're more, uh.
Chris Romeo:in. I did the blockchain
Izar Tarandach:no, no, no, no, listen, listen, listen, no, no, no, that the blockchain I can even somehow accept. Not the way that you put it, right? But you know what? I, I, I, I think, I think that we all agree that SBOMs need some kind of verification, and nowadays I understand, nowadays. A couple of months ago when we last checked, I think that people weren't even having to sign SBOMs. But I could see some blockchain thing going in there to, you know, validate and see that there were no changes to the SBOM and this and that to the other one,
Chris Romeo:the SBOMs on the blockchain. That's another business idea. I didn't even think of that. SBOM on
Izar Tarandach:AI,
Chris Romeo:blockchain. Yes!
Matt Coles:Somebody mute him.
Izar Tarandach:I'm going to show out of the window. Happily. But, again, it comes down to, it comes down to what problem are we trying to fix, and, and, Aditi, for example, you mentioned provenance, okay, for, uh, for the, the, the, for verifying ITAR, for example. Again, it comes back to a point where I can write on SBOM whatever I want. The fact that I have an SBO doesn't say that, that actually reflects what's out there. Uh, sorry. In there, I mean, we even had people telling us that manually created that SBOs are better than automatically generated ones. So Yeah. I went there. So you know,
Chris Romeo:That's a good point though, you can't validate the SBOM, there's nothing that validates
Izar Tarandach:validate the format.
Chris Romeo:Yeah, but I, yeah, but I, my point is I can't, I can't run an SBOM checker against a running product to generate an SBOM and compare it with what you told me. I'm fully
Izar Tarandach:there is no third party. There's no third party lab that's going to run a separate test That's going to tell me that the SBOM that I got from the vendor is actually the SBOM of the product that I'm using That's
Chris Romeo:a whole other,
Izar Tarandach:Now, you can put, you can put blockchain in there, I think. Somebody kills, uh, somebody calls Zoe,
Matt Coles:So I would, I would be careful, I would be careful with that statement.
Chris Romeo:I got to work digital transformation in here real quick. No, I'm
Matt Coles:Oh, my God. I would, I would be very careful with that blanket statement of I can't verify an SBOM. The components that show up in an SBOM, remember, there's a hierarchy, right? So if my system contains two top level things and that... So each of those things contain four other things. Those components may be present in multiple ways, right? They may be present as code that's compiled in, either snippets or whole modules, or they could be independent things on disk, right? And so, in theory, You could, you could potentially, uh, validate the entire SBOM if you had detection capabilities. Of course, if you could do that, you don't really need the SBOM in the first place. Except for, except for, except for to prove, except for to prove that the system that you bought wasn't modified. In other words, no new functionality was added or functionality was removed inappropriately. At least from a, at least from a, at least from a,
Izar Tarandach:that's one, that's one signature away You just
Chris Romeo:Yeah, that's one signature tells me if
Izar Tarandach:the components and check. You don't need an SBOM for that.
Matt Coles:You don't need an SBOM for that, except you do need to know that the whole, you have to know that if, I mean, if you rely on, if you rely on signatures alone, right, we know that, we know that, we know that, we know that digital signing certificates get compromised, right, either they get issued inappropriately or they get stolen, and so it provides a level of assurance, an additional check that you can do. I'm not saying
Izar Tarandach:are not even signed! What am I comparing with?
Matt Coles:well,
Izar Tarandach:Matt, before I publish the SBOM, I do VISBOM and I change the versions to whatever I want. Now you're telling me that on the recipient side, they have to have the ability of rebuilding the SBOM, just for the sake of comparing with what they got
Chris Romeo:This is why we need the blockchain
Izar Tarandach:get? I'm going to block that chain. Right now.
Chris Romeo:you're gonna add that to my, the list of things I'm not allowed to say, but I, I, we're, we're, we're
Matt Coles:what's in your threat
Chris Romeo:really, we're all over the place here, but any, any thought be the voice of reason here. We've needed a voice of reason for a long time on this show.
Matt Coles:We have no voice or
Chris Romeo:can you bring a voice of reason to any of the things that we've just been tossing all over the place here? So,
Aditi Sharma:So I'm, I'm trying to think, um,
Izar Tarandach:I try that all the time, nothing happens.
Aditi Sharma:I think that I'm getting that effect, Izar, um, but I think with, with SBOMs, what's happening is there's a way now suddenly there's a Eureka, oh my gosh, my, you have your SBOM, I have my SBOM and now everyone can know. You know, what's in there, and let's be transparent and all that, but That's not practical, right? Because, um, literally, uh, SBOM is a secret source of your product somewhere, right? Because how your product is created is you have everything in there. Yes, and not, you know, you're not sharing the exact code, but... You have all the components, all the recipe ingredients over there. So, there are trade secrets, um, you may not, there is also an impact on your own vulnerability response teams, if you think about it. Because, if you start having a blockchain and having, you know, everyone's information into yours and... Then the customer is going to be confused. Where do I go? You know, so it, it has to be, it has to be a step by step process. And Izar, I cannot change your view whether, whether SBOM is useful or not.
Izar Tarandach:Oh, you can, you
Aditi Sharma:At
Izar Tarandach:totally, I'm open.
Aditi Sharma:the end of the day, you have to see what is your risk posture and how you're, how you're managing your vulnerabilities. Do you care about... What components your developers are, you know, using, what open source your developers are using in your product, because if you don't know that, if you don't have a manifest in place, if you don't have a filter somewhere, you know, because this is eventually helping in so many things, right, this whole process, it's also helping you be more cautious of what you're doing. What you want to have in your product. More cautious of taking steps of letting everyone know, Hey, you cannot just use anything that you like. You have to have, you know, you have to abide by the manifest approved within your company or whatever it is. So SBOM is kind of a driver in engaging these further, further discussions. I just feel like it's, it's a driver, it's an enabler. And then rest is on you, how you want to How do you, how you want to use that information
Matt Coles:I'm confused though, Aditi. I'm confused, Aditi, by the use case that you're highlighting. So, I've always been under the impression that an SBOM is primarily to communicate information from supplier to consumer. But what you're, I think what you're highlighting here is that an SBOM may be used supplier with internal, internally to the supplier. As well.
Aditi Sharma:Absolutely. So say I have close partners, right? And I work on, you know, vulnerability response for all these things with them. There can be a code of action where you also share SBOMs between each other, right? Just to understand, just to have that view of where, what are the components? What could happen next? about having that, that relation with the suppliers as well, internally, not everyone has to share everything outside, but for your internal, uh, for your own product, what all you are consuming, you have to keep an eye on what, what you're consuming because you have like 10 vendors. within your product as well.
Izar Tarandach:So now you touched on something that I can totally stand behind, and the analogy is another industry that I think that we constantly reach out to learn from, which is aviation. And if you ever look at the analysis of an aviation accident, they are able to know every single screw in that plane, where it came from and when, which batch, which lot, whatever, right? But then it falls back into the maturity of the SBOM universe today, and the way that I am, I won't say criticizing, but questioning it. is that we are moving very fast in this direction of SBOM all the things, while we lack the foundation work that would give me the ability to trust an SBOM to reflect every single screw that goes into my software. You know what I mean? So I, I totally get the internal, the, the internal side that you, that you put out, the, the external side. To me, it's starting to rub it the wrong way because we are saying, oh, whomever gets that product and gets that SBOM, they have to now rebuild the SBOM so that it compare with the SBOM that was given to them firsthand. And
Aditi Sharma:That's, that's hard.
Izar Tarandach:You know, I'm thinking everybody's talking about this shift left thing, and there couldn't be anything more shift right than this.
Matt Coles:I wasn't suggesting we should be validating the SBOM
Chris Romeo:left, please, please, please.
Matt Coles:way, Azar, I think
Izar Tarandach:I'm fainting. I'm fainting left. I'm fainting left.
Matt Coles:I think you confu, I think you confuse my statement with you can versus you should, right? You could, if your SBOM is, if your, if your SBOM is val, if your SBOM is signed, you can prove integrity and
Izar Tarandach:If it's signed.
Matt Coles:If it's signed, right? But if it's not signed, or if you want to do an independent validation, for whatever reason, it is probably possible for some percentage of those components. I'm not saying that you will have to, but you
Chris Romeo:I just want to piggyback on that, if it's signed, it's the same thing as a contract at that point. Like if somebody did, like it's, if somebody was to create an SBOM and maliciously change it on purpose. There'd be a liability case for me as a customer. I could sue whoever gave me that software if they modified it. If there was some material breach or something that occurred on my, I lost money as a result of that breach and turns out they lied to me. That's where everybody's afraid SBOM could go though, is the liability side. Because that, that, we know how long it takes liability to work out the courts to... Decide, try them, get a, you know, a body of record so we know what the, the answer's gonna be. Um,
Matt Coles:And we're making the assumption that the SBOM is complete. In addition to being accurate, and that's where the liability comes in.
Izar Tarandach:then you can always get told you could have checked it by yourself,
Chris Romeo:Well, I'm saying.
Izar Tarandach:the software.
Chris Romeo:The malicious case, I'm trying to, I'm trying to work around the malicious case where somebody just, like you said, they open VI and they just change the version numbers. That would, that's fraud, right? Like we have, we have rules and laws and whatnot in the United States that define what fraud is and, and that would be a pretty clear cut case of fraud if you gave me that SBOM and we had a contractual requirement for you to provide SBOMs and you just blatantly changed it and gave me something different. Um, I think that would be an easier, be an easier thing to get around.
Aditi Sharma:I don't see it that way. So yes, there could be repercussions, but This whole, this SBOM is maturing and you're not going to get it right the day one. And that's where, you know, the legal helps, right? In having all those. This is, this is what we know at the best at this time. And it can change the, as I said, there is a level of depth to SBOM. It can, for some products, Log4j was a level 6th or 8th. Like you cannot even find it with your basic top level dependencies. So, and that. That can happen with, I don't know. Um, but that's a good point that you raise. Yeah.
Chris Romeo:All right. We were going to talk about VEX, but I'm vexed by the fact that we don't have enough time. talk about VEX. we'll have to have another conversation about VEX because we're, we're just at about our, our time
Izar Tarandach:You want a vex it..
Chris Romeo:emphasis. I'm an anti VEX ter apparently. Actually I'm not, I don't even under, like I said at the beginning, I don't even really understand VEX yet. And so I do need to definitely learn about that. But let's do, um, let's, let's close it out. Let's kind of give some, let's do some final, a final, uh, statement slash. Thoughts, but not an argument because that will then turn around another iteration of minutes of recording time. But Matt, go ahead and go first. What's your, like, give us something to take away from this conversation.
Matt Coles:All right, so you start, we started this episode with I, with I, you posted something on LinkedIn and, and caused a farfuffle and, uh, around SBOM. And I think your, your original premise was, was good, was accurate that the flow that was described in the white paper. The guidance documents, recommended practices for SBOM consumption missed the key point by, by not explicitly calling out, oh, by the way, use this for understanding, you know, patching and, and whatnot. But I think I will also extend that to general risk management p and configuration management practices using the knowledge in the SBOM to understand that you need to patch. And, and, or thinking about now I need to provide mitigations and potentially change my network architecture or other mitigating techniques. That's the true outcome that you get from, from SBOM, in my opinion.
Chris Romeo:And that was a lesson learned for me. Like that's, that's something y'all taught me on this, this episode. So Aditi, let's, uh, why don't you go ahead and give us a final thought next.
Aditi Sharma:Uh, well, if you want to just keep an eye on, you know, what your product has, what you're consuming, open source, commercial, anything, and In turn, use the APIs available for having, you know, all the CVEs that are out there. And if you want to compare, do you have any components which are affected with the database that is available publicly? Um, you can actually see where you are standing in your security posture. So, give it a try.
Chris Romeo:Okay, thank you. Izar, what about you?
Izar Tarandach:SBOM will be great. SBOM is becoming great. Today, SBOM is not great. We are putting a lot of mass behind us, and it's building a lot of momentum. And I think that it's going to become something that's very central to the whole industry. But right now, the value proposition is there, the value realization is not.
Chris Romeo:Wow, and Because I'm kind of the impromptu host of this show. I don't have to follow my own rules And so I'm not gonna give you a takeaway. Thanks for joining us on the security table folks and We look forward to having another conversation with Aditi in the future to learn about VEX. Aditi Thanks for joining us on your first ever podcast appearance
Izar Tarandach:You survived!
Chris Romeo:here.
Aditi Sharma:Thank you for having me.
Chris Romeo:it
Aditi Sharma:No, this was great. Thank you so much for having me.
