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 Fable
Join Chris, Matt, and Izar for a lively conversation about an article that offers 20 points of "essential details" to look for in a Software Bill of Materials (SBOM). They dissect and debate various points raised in the article, including generating SBOMs, the necessary components, and how to gauge the quality of this digital inventory. Their critique is both insightful and humorously candid, and they will offer you a tour through the often complex world of software documentation.
Hear about topics ranging from open source dependency tree, the necessity – or not – of manual SBOM generation, and the importance of a Vulnerability Exploitability Exchange (VEX) document alongside an SBOM. You will hear why they think an SBOM with a VEX can transform and simplify risk assessment procedures by providing clear and actionable insights for threat management.
Links:
Forbes: 20 Tech Experts Share Essential Details To Look For In An SBOM
https://www.forbes.com/sites/forbestechcouncil/2023/10/09/20-tech-experts-share-essential-details-to-look-for-in-an-sbom/
FOLLOW OUR SOCIAL MEDIA:
➜Twitter: @SecTablePodcast
➜LinkedIn: The Security Table Podcast
➜YouTube: The Security Table YouTube Channel
Thanks for Listening!
I can hear the Muppet theme song right now.
Izar Tarandach:sensational, international, and it's gonna start the security table.
Chris Romeo:to... What a way to start! With a little rendition from the Muppets. So, I don't even know how to explain the Muppets, so I won't try. Just Google it, read the Wikipedia entry if you don't know what we're speaking about. It's from many years ago, but it's
Matt Coles:Manamana. You can find it streaming somewhere.
Chris Romeo:Yes, I should find it. I would love to watch those shows again. Alright, well, um, the three of us were coming off a visit to our nation's capital, Washington, D. C., where we hosted the first ever threat modeling conference, and I don't know about you guys, but I'm just, uh, running on fumes today. But, uh, luckily, I still have snark available even when I'm running on fumes, so that will It may even get worse, so just, uh, you know, parental warning, there may be a higher level of snarkiness in this, so we've got a special topic, too. So it's kind of like a perfect storm, where everything's everything's coming together for the storm of the century, right here. So, we want to take a look at an article, and I'm
Matt Coles:You're just going to unload on this topic, aren't you?
Chris Romeo:Me? I may, I may. I've been unloading on this topic for the last month or two, if you might remember,
Izar Tarandach:Month or two?
Chris Romeo:Okay, longer. So, the title of the article is from Forbes, and it is 20 Tech Experts Share Essential Details to Look for in an SBOM, and this is a expert panel from the Forbes Council's member, Forbes Technology Council, and so
Izar Tarandach:Fee based.
Chris Romeo:Yeah, so that's a good thing to, yeah, it is a, it does say membership fee based. When all we're doing is reporting the news here, it does say that in the byline of this particular item. And so I know as we were going through this and looking at the various things, uh, we definitely had some questions. So let me just read off the first one that we want to comment on. An open source dependency tree. Number one on their list. Because components and pieces of code are often dependent on others, one of the most complex challenges in application security is open source dependency management. SBOM should include an open source dependency tree so users can see the core components of an application and where they come from to help engineers quickly identify and manage dependencies in the code. This one seems like it's pretty good. It seems to be relatively...
Matt Coles:It's literally the definition of an SBOM. Yeah. Yeah, I mean,
Chris Romeo:should always start with the definition, though, for
Matt Coles:no, but an SBOM,
Izar Tarandach:detail to look for.
Matt Coles:yeah, an SBOM shouldn't include it, an SBOM does include it.
Chris Romeo:Okay, but it is a detail you should look for. Like, you should look, I mean, if an SBOM didn't have an open source dependency tree...
Izar Tarandach:Have this.
Chris Romeo:Would it be anything? It's not even SBOM.
Izar Tarandach:it would be text.
Matt Coles:well, so here's an interesting question. Uh, let, let's just, I wanna tease out two parts to this. There's a notion of top level components versus transient components, right? So what you have, what you embed actually what you have, what you, what those things embed and what, what those things embed and the hierarchy can
Izar Tarandach:or transitive?
Chris Romeo:transitive.
Matt Coles:the, yes. Sorry, not transitive, Well, transient would be if they came and came and went, but transitive,
Chris Romeo:whole new category you just invented of open source packet. They're transient. So, you know, they just, they come into the packet, they come into the app, and then they just leave whenever they
Izar Tarandach:at the package go!
Matt Coles:Actually, actually, I will say that we, we actually see, we probably see these pretty commonly right where if you have suites of tools where some tool, some of those things are optional, you may have transient components in runtime, not necessarily at deploy time or, or, you know, package time. Uh, I mean, Linux distros are the same way if you think about it. So
Izar Tarandach:that gets downloaded at runtime.
Matt Coles:that's right. So, so that's not unreasonable.
Chris Romeo:of all my nightmares is what you just, you just keep feeding into these are my nightmares. Okay, but get us, get us to the, get us to the,
Matt Coles:so, so the one part, the one part I, the one issue I have with this, and this is just me, is, probably just me, is the dependence, is the, the insistence that SBOM is only for open source. Certainly open source code is... Considered risky for some reason. Uh, you know, not without, not without reason. Uh, and, but commercial components or non-open source components are likewise. necessary to be tracked. So SBOM helps with tracking those components, understanding what's in. Commercial components just operate under a different license, so why rely solely on, on open source here? Why, why focus solely on open source?
Izar Tarandach:Right.
Chris Romeo:So let's move on to number two. Let's get some, let's have some fun here. So this one says a library with version numbers. Make sure that vendors include open source packages and libraries with clearly marked version numbers, delivered in a machine readable format so you're able to check vulnerabilities and those of nested dependencies. Having an SBOM at the start of a contract is good, but having one that is up to date and includes a live data feed is best. Rather than point in time security, you have continuous assurance.
Izar Tarandach:So this is reasonable, it goes a bit more into the definition, but to tell you the truth, the live data feed threw me.
Matt Coles:That's right, it's a, SBOM doesn't, SBOM doesn't do that
Izar Tarandach:wait, you want to put an RSS feed in an SBOM? Hey, this is the SBOM today, but if you want more details in a continuous way, follow this feed! And don't forget to subscribe.
Chris Romeo:you invented an RSSBOM.
Matt Coles:I, yeah, I think, I think that's what
Chris Romeo:RS-SBOM.
Matt Coles:if you, if, if your SBOM was posted as a, as an XML feed that you could get regular updates from first. So let's just take a step back about what an SBOM is describing, right? An SBOM is describing point in time, a system and what components it includes. Now let's say for a moment, this is a product that you ship or it's a software application that you're providing to somebody. you ship that, it's not going to change. Right? It's going to be pretty set in stone at that point in time. When you deliver SP1, it will change. But then you'll have an SBOM for SP1, not an SBOM for pre SP1.
Izar Tarandach:I, I'm going to give you the, the benefit of the doubt and say that this is during development. So you do your SBOM in the beginning and he's saying Don't, don't keep that one, right? So continuously update your SBOM as you build. But at delivery time, that's what Matt said. It goes out, it goes out frozen in time. Hopefully signed.
Matt Coles:I'll
Chris Romeo:I had I'm softening on the first statement here because when I originally read this about making sure you have libraries that are clearly marked with version numbers, I was like, who has a package that isn't labeled with a version number? But then I started thinking about it, though, if you're building software, if you're building packages internally, for inclusion in your applications that are not in NPM. They're not in the various public, you know, Maven or public repositories. You could not have proper versioning. So you could violate that constraint. So I've softened on that first thing. We've got to unpack what the heck is continuous assurance?
Matt Coles:Oh my god.
Izar Tarandach:no. No, no, no, no. It's, it's, it's, it's, it's, it's, it's, it's a very rare thing in our industry. It's called a buzzword.
Chris Romeo:Oh, I'm
Izar Tarandach:no meaning
Matt Coles:All right. All right. I'm going to be, I'm going to be positive here with, with, with Elliot's, uh, suggestion of you'll, you will, I would read it differently. I would have, well, people will go read the article and see who the person is. So, I think what it should have said is, you can have continuous assurance, not that you, you know, imply you will have.
Izar Tarandach:It
Matt Coles:And, and,
Izar Tarandach:too,
Matt Coles:well, it allows you, it allows you to, the SBOM gives you the ability to then hook it up to some sort of engine that goes, yes, a tool of some sort that goes and looks. This component, these set of components have these versions, do these versions now have vulnerabilities?
Izar Tarandach:Yep. So
Matt Coles:I wouldn't call it assurance. I wouldn't call it assurance though. I would call it continuous monitoring or continuous management.
Izar Tarandach:That's true, but it could be interpreted as I am looking for continual assurance. By doing the monitoring. So it's aspirational.
Chris Romeo:assurance is different than continuous assurance.
Matt Coles:If you're running this in a CI/CD pipe, if you're running this in a CI/CD pipeline and your SBOM, if your SBOM is consumed by the CI/CD, it could do the checking on a continuous basis, right? CI/CD, continual delivery, continual integration. Why not continual validation of patches from embedded components?
Izar Tarandach:So again, I think that we can agree that two is more in the building side of things than in the delivery side of things. Right? But, but it's the basic functionality of,
Matt Coles:I mean, you could, you could,
Izar Tarandach:agree, it's the basic functionality of an SBOM.
Matt Coles:you could continue it into run time, I think. In other words, if you had a monitoring tool that could consume those components and validate them against NVD on a regular basis, then, then that supports some level of assurance.
Izar Tarandach:Okay.
Chris Romeo:All right. Let's, uh, let's go to five.
Izar Tarandach:Five? You don't wanna do, uh, what's it? Okay, yeah, five.
Matt Coles:Well, it's three, three and four. Well, four especially is, again, definition of SBOM,
Izar Tarandach:is the same thing, yeah.
Chris Romeo:Yeah. I felt like that wasn't adding anything for, into the debate for us, but
Izar Tarandach:But, but three sort of trips me a bit.
Chris Romeo:which one,
Izar Tarandach:Right? Three. Because it asks, an SBOM should have clear language as to how the software is updated and supported. I'm sorry, the SBOM doesn't contain any information about the process. The SBOM just is.
Matt Coles:You could give metadata
Izar Tarandach:You can put the Bible in metadata, but should you? I mean, it's not a contract on how you're going to do upgrade, uh, updating. It's not, uh, it's not driving any kind of, uh, automation. So.
Chris Romeo:hold on. I got a great idea. Let's create something new called Process-BOMs.
Izar Tarandach:You remember what started, uh, what happened in the beginning of this week when we started creating Bones, right? It did not go well!
Chris Romeo:Yep.
Matt Coles:And I will also highlight, go take a look at Cyclone DX sometime. Because Cyclone DX has a lot of capability.
Izar Tarandach:But, again, you know, I, I, I've, I've... Spoken with Steve a number of times, I, I, I had interviews with him and Cyclone DX is, is, is getting big and it's encompassing a lot of things. And I love that, but it's a formal, formalize, formal, it's making formal a lot of, a lot of information that we have out there to drive pipelines. But that doesn't mean that there's a consumer on the site, that there may be data in there, but nothing is listening and using it yet.
Chris Romeo:and for those playing along at home, the Steve Izar is referring to is Steve Springett, the project lead for Cyclone DX, Dependency Track, and recent Global Board of Directors Was how was elected to the global board. So
Izar Tarandach:Electee? No, Elec yeah. But, Inductee, Inductee. But, uh, just to point out, to me, Steve is like, personally, just me. Steve, to me, is the ultimate source of all that is SBOM related.
Chris Romeo:True, true. We can get into that later. I mean, I, uh, on a LinkedIn post, I was trolling SBOMs again for the fourth time,
Izar Tarandach:My threat model is cooler than your SBOM?
Matt Coles:DAST.
Chris Romeo:that was nice. Yeah. Yeah. My threat model, definitely Izar is responsible for that. My threat model is, is cooler than your SBOM statement and sticker that you could get, um, but Steve finally weighed in and like I told him when I saw him, I was like, I've been waiting. Oh, look at that. We
Matt Coles:Remember this from like,
Izar Tarandach:Oh yeah,
Matt Coles:long ago was this from?
Chris Romeo:Yeah, that's true. That was early in Security Table, but, but, um, yeah,
Izar Tarandach:and still current.
Chris Romeo:yeah, but it was good to see Steve weighed in on that topic and finally confirmed for me, because I'm the same way, like, if Steve says it about SBOM, I'm pretty much gonna believe in it, like, he's in the middle of this, he's driving this thing, and he even said, like, yeah, you know what, the whole sharing thing, eh, I don't know that I see it either, and that was my whole point, so I'm like, okay, if Steve sees it that way, then maybe I'm on to something, but we got to keep going here.
Matt Coles:yeah, I just wanna, I just wanna call out for those again, also following along at home. SPDX is the, is the other format for SBOM So you have Cyclone dx, and SPDX is the two competing standards for, for SBOM
Chris Romeo:All right, so, you know, I'm gonna skip over number five. It just doesn't look as good as number eight, which I think is gonna start a fight between you guys. And I just want to watch that happen, so. Um, number eight says whether the SBOB is generated dynamically or manually. And so, I forget what side of this issue you guys are on. So, who's the dynamic generation and who's the manual generation?
Izar Tarandach:I do the dynamic, but with the caveat that I need a better definition of what the manual is. Like, is the manual just clicking a button and starting a process? Or is it, I'm gonna go look for the versions and write them down in
Chris Romeo:Matt was arguing that man, not necessarily that he does them manually, but for the ability Right. To be able to, so let's ask him what, like when you, if you're gonna argue the point, you gotta be able to define define what the thing is.
Matt Coles:So I think the danger of solely relying on man on dynamic. So, uh, I wanna be careful. I, there's, there's parts to SBOM creation. Some of which deserve to be manual, some deserve to be, I think, deserve to be automatic. So, you need inventory, you need inventory first, you have to do discovery. And we know that discovery is challenging, right? There are tools out there, I'm not going to go into them, uh, we shouldn't, uh, for better or for a lot of worse, uh, that discovery of components is hard, especially when we're talking about transitive dependencies. Right, so when you have a top level, you may have a bill of materials as part of your, as part of your build process. You may or may not know what packages are included, and it depends on a host of things. What language you're in, uh, what type of system, what technology you're building. And so, um, you may miss things if you rely entirely on automated discovery. So building your inventory may require some manual effort. Once you have an inventory, dynamic generation is absolutely, uh, essential. Right, you should be able to take a spreadsheet or take a, uh, a flat file or some, a CSV or whatever of, uh, of a component inventory and produce an SBOM using code. That I 100 percent agree with. And that's, that's, so that's when I say dynamic, I mean, dynamically, uh, uh, considering that dynamic discovery is error prone, but dynamic generation of the actual SBOM content is a requirement.
Chris Romeo:Isn't manualness of this? And either, I want you to, to come in on this, but I'm just, I want to get this thought out because I wanna get Matt's take on this before we switch to the dynamic side. Isn't manualness of SBOM generation a lack of maturity?
Matt Coles:I think, I would say yes, aside from the fact that who in their right mind wants to deal with handwriting JSON? Uh, I mean, yeah, it's an easy language for, for, or structure, data structure for, for, you know, for people to read, but you can easily get it wrong by when you're doing it by hand or, or. Plethora of tools out there for building JSON content. Auto manual, right? Uh, and so, again, the discovery part is the hard part for me. Always has been, right? The, once I have an inventory, putting it in SBOM format, why not automate that? Are we, Izar, now on the same page, or are we still at loggerheads here?
Izar Tarandach:No, no, no, I mean, you put the manual thing into context. But where I'm going to sort of disagree with you is that... And... It's just disclosure. My first startup 30 years ago was all about opening RPMs and DEBs and whatnots and finding out the dependencies. I don't think that as a rule the package managers and package inventories have gone much better than they were at that time, right? But they are still able to at least give you a good tree of things that depend on things that depend on things. And we do have more tools available nowadays to cover those things that don't come as part of a package manager. Where I have a problem with manual stuff is that at the end of the day even if we consider the Boundaries and the defects of these tools that generate inventories, I think that they are bound to, over time, as part of a process, generate less errors than a person invested in those processes. So the person writing, the person discovering, the person figuring out, I think that there is just a higher chance of error over time. Then a process that you might refine and end up figuring out what is missing and just fixing that specific problem.
Matt Coles:I think, I think we're on the same page. It goes back to that, that notion of tool assisted, right? We, so we know that many of those tools will misreport components that they discover either. It can't figure out what version it is. It reports multiple versions. Maybe it reports multiple licenses and SBOM, you know, obviously licensing is important here. And so. It needs to be tool assisted. I will highlight or just reiterate the fact that, you know, there are some things like, you know, statically linked code modules and, and or pieces of source code that get included, which are components, but they're written, you know, taken in source form that are built in that won't show up in package managers, right? That does require some sort of human intelligence, at least today, to figure out that they're there. Thank you. or to properly interpret the results that come from the tools that do the automatic discovery. So I think we're on the same page in that, in that regard. The other part of number eight, I think, I think here is about time sensitivity. And absolutely, that's a great call out for the reason that we said, when you ship something, you know, you'll fix the SBOM in time. So obviously whatever process you have has to run in whatever time you have between inclusion and packaging and release.
Izar Tarandach:Definitely.
Chris Romeo:Okay, well I was hoping for a lot more spirited debate on
Izar Tarandach:We're tired.
Chris Romeo:Yeah, that's true, that's true. You're unable to raise the level
Matt Coles:wait, but when we go to nine. Why don't we start with nine?
Izar Tarandach:Oh my goodness.
Chris Romeo:What's wrong with nine?
Matt Coles:Uh, does that, what, what does SBOM have, uh, related to, uh, which protocols you're running?
Chris Romeo:I think there's a crypto-BOM
Matt Coles:There is a crypto-BOM, but it's not an SBOM,
Izar Tarandach:bump. Yeah.
Matt Coles:not an SBOM.
Chris Romeo:Aren't all BOMs SBOMs? Yeah,
Matt Coles:No, SBOMs are software bill materials. Crypto-BOMs are crypto
Chris Romeo:a generic term. Yeah. Yeah. Yeah.
Matt Coles:Has it? Are you sure?
Chris Romeo:so. I'm afraid it has.
Matt Coles:Oh great, so HBOM is covered then.
Chris Romeo:I think so.
Matt Coles:So hardware and software are the same thing?
Chris Romeo:the general population talks, that has heard of a SBOM, I don't think the general population has perspective on all the various types of BOMs that we do because we've looked at the issue.
Matt Coles:Only Cyclone DX has different types of BOMs though, right? SPDX only has SBOM. And when you talk to CISA, I think when you look at CISA, they specifically, specifically, explicitly call out software bill of materials.
Chris Romeo:Okay,
Matt Coles:So when people are talking SBOM, In the, in the attestation space, I think they're only looking at SBOM.
Chris Romeo:so this, I mean, this number nine specifically says SBOMs with deprecated algorithms will soon be obsolete and costly to upgrade. So it doesn't say CBOM or crypto-BOM or anything like that. So is this just a, a twisting
Matt Coles:I think it's a language problem, right? Like, having, having a deprecated OpenSSL version? I don't, so first off, an SBOM that contains an OpenSSL version that's deprecated means the package that the SBOM is for has a deprecated OpenSSL version. I absolutely could see that that would be a costly, you know, a costly problem to upgrade. But. the, I don't believe, and maybe you guys know, but I don't believe that the SBOM format itself actually describes what functionality those components have, meaning it's a component, a component version, licensing, and potentially other metadata, but not directly what functions you're calling or whether you're using, you know, X, Y, and Z algorithm from it.
Chris Romeo:I'm looking at this one still, number nine, and I'm like, is this just a way to answer the question to promote what it is that you do?
Izar Tarandach:Mm.
Chris Romeo:that sounds slightly mean, but like, does this have any, I don't, I don't get, this doesn't have anything to do with SBOM. This is like, it's calling for crypto agile software that's crypto agile.
Matt Coles:an SBOM can't tell you. I
Chris Romeo:quantum safe standards. Like, this sounds like this might be a recommendation that I should use somebody's product. Kind
Matt Coles:mean, it's a, it's a great design. It's a great design pattern, right? You should design crypto agility into your system. Absolutely. You should definitely design in the use of quantum safe algorithms. Absolutely. Do you have the ability to store that in an SBOM and transmit that to consumers?
Chris Romeo:It's a it's a different message Yeah, it's the wrong. It's a message that's just been put into this squeezed into an SBOM-sized box When in fact it is a crypto-sized rectangle. I'm stretching. I mean, this is a real stretch. Let's look at number 10 because I just I did a little research about number 10 because I wanted to make sure what we.....I want to be careful.
Izar Tarandach:Okay.
Chris Romeo:So number 10 talks about data residency and how we should look at data residency, um, because it affects how and where data is stored. Different countries and regions have different laws, laws can impact data owners, controllers. I searched the Cyclone DX standard, which is a public document, I can't find anything about data residency in the standard itself. So does this have anything to do with SBOM or what's it, what are you concluding?
Matt Coles:I think it's like, it's like nine. It may be, it may be optional extra data that could be encoded in the SBOM, but it's not standard as part of a part of the specification.
Izar Tarandach:Yep.
Matt Coles:You have metadata. You can store a ton of stuff in metadata.
Izar Tarandach:You can put whatever you want in there.
Matt Coles:Yeah, but, but so I guess what, uh, this author is, uh, is calling out is there should be information that you encode in the SBOM, and I guess it may depend on what the SBOM is representing. If the SBOM is representing a desktop application, really there's no, that's, somebody can install it, they can run it locally, maybe it talks to a database locally, even maybe it talks to a database within a local network, you don't really have a data residency problem. If that SBOM is representative of a SAS service, however, or a cloud enabled, you know, multi site cloud enabled thing, then data residency obviously would matter, and you may want to encode that information. I don't know that SBOM, though, is the right place to put it. Like, a datasheet, or, or, you know, other, you know, an admin guide or something might be a better place for that.
Chris Romeo:Yeah, I mean, the worst thing you could do is try to squeeze everything into an SBOM. Like, an SBOM is not the single format to rule all formats that's going to contain everything. Well, you need to put everything about your product into the SBOM. Well, the SBOM is 12. 7 terabytes. Let me just send it over to you so you can process it,
Matt Coles:Oh, by the way, it's, by the way, it's text.
Chris Romeo:Yeah, it's text, it's not encrypted, so it's, it's a lot of, you got a lot of work to go with it. Alright, I think we got enough out of that one, so, how about, let's take a look at 16. How many and which functions are enabled? These days, most software products are consumed as software, uh huh, with multiple functions that can be charged separately, so we're talking about functions like capabilities or things that you could be charging, so like features almost. Per user, per device. One item businesses should thoroughly check is how off, how many of these functions are enabled, used, and leveraged. Enterprises often use multiple products with redundant functions, eliminating redundancies can result in massive savings. I think that's a true statement.
Matt Coles:True statement, not an SBOM thing.
Chris Romeo:What a, what the heck does it have to do with SBOM?
Izar Tarandach:Look, again, it's the kitchen sink. Right? So I,
Matt Coles:Yeah.
Izar Tarandach:I think that people are interpreting SBOMs really, uh, uh, aspirationally, like somebody told them, this is going to solve all their problems. So people are like projecting all their problems into the SBOM. But again, we, we go into the, there is nothing on the other side consuming this stuff.
Chris Romeo:Yeah,
Matt Coles:mean, what would that look, what would that even look like? So first off, You, you produce an SBOM for a single for products, right? And so if you have multiple products, you'd have multiple SBOMs and what you're gonna look across'em and go, oh, both of them are using open SSLI. Therefore one of them must be redundant.
Chris Romeo:That is an astute assessment of this challenging statement. All right, I think we're enough on that one. I think we've, we've,
Matt Coles:can we go back to 13 for a moment?
Chris Romeo:I mean, we can, we can go anywhere we want.
Matt Coles:Let's go back to thir thir, let's go back to a 13 for a moment because.
Chris Romeo:This one kind of ties into 12 though. This is kind of the... The name, how long it takes to receive the SBOM is not indicative of the actual content of what was stated here. Cause I get what he's saying. Like his point is if somebody can't put together an SBOM, and I heard this from somebody at the conference in the last week, if somebody can't put together an SBOM, that could be an indicator that they're really bad at security and software, building software,
Matt Coles:or they don't have automation in place.
Chris Romeo:which in this day and age, if you tell me you don't have a build pipeline for a piece of software, I ain't buying it. I'm sorry. I'm not taking something that you're compiling on some developer's machine. If you don't have that, because it's, it's not hard to do that. You can, I mean, pipelines are everywhere. Like you can get a free license to a pipeline SaaS provider and you can wire up your build process in an afternoon. So there's no excuse to say, well, we just don't have the ability to do automation. Well, then you don't have the ability to receive my money.
Izar Tarandach:So what I'm hearing is that the automated way is better.
Matt Coles:For the construction of the SBOM? Perhaps, yes. We 100 percent agree.
Chris Romeo:for building software in a standard way. Yes, of course, automated is always going to be better because it's a standard set of steps. You want it to do the same thing in the same order every time.
Matt Coles:Now,
Chris Romeo:Verses the developer going,"Oh, you know what I forgot, Matt? I forgot to run the SAST scanner. That's what it was? Oh, that's why we got compromised. I knew it. I knew there was a reason."
Matt Coles:Or I forgot to include OpenSSL. I mean,
Chris Romeo:Yeah. Oh, you needed OpenSSL? Come on. I didn't. I had an old version. I just went with what I had on my laptop.
Matt Coles:Yeah, exactly. So, the other, the other piece I want to pick up, pick out of this actually is, is kind of interesting. You know, the very last sentence is, if it's a ladder, so if it, if it's, uh, If they're scrambling to produce it on demand, you should scrutinize the accuracy and quality of the dependencies. And I think this is a little bit, misses the mark, but it does raise another, another question. So if you have a software package and you are trying, trying to put together top level dependencies, that's, that's one problem, right? The, the producer of the software. owns those dependencies, manages those dependencies. What might be missing though is if you're looking for transitive, uh, the transitive information and those don't have SBOMs from those vendors. And as a software producer, you should be looking at your supply chain and getting SBOMs from them, as opposed to trying to piece one together yourself for the components that you embed. Then I could definitely see looking at that and go, hmm, this software includes components that has a questionable supply chain.
Chris Romeo:Alright, let's, we're gonna, we're gonna pick up 18, 19, and 20, so let's, let's focus in here. And I know 19 is one that we, that Matt, you have expressed is something that you think is the best part of the advice, but we gotta deal with 18 first, I'm sorry.
Izar Tarandach:sometimes, no, no, no, no, no, no, I
Chris Romeo:The delivery address. I'm just going to read this verbatim because sometimes truth is stranger than fiction. A key item to look for when requesting a software bill of materials is the delivery address. This could have a large impact on how taxes are applied or excluded from the bill.
Matt Coles:Oh my god, Kitchen Sink,
Chris Romeo:Yeah, I'm speechless.
Izar Tarandach:parsed this with somebody that we valued, and uh, 18 and 20, we parsed it together, and we got a
Matt Coles:oh the final price,
Izar Tarandach:we got a theory on the, the thought behind it. Software bill of materials can also be interpreted as a bill of materials for someone who bought software. So we are talking here about people who think of shrink wrapped boxes of CDs being delivered somewhere, and those are listed in a bill of materials. And because what's being delivered is a software, then it's a software bill of materials. So,
Chris Romeo:this a, isn't this, hold on, let me go back to, I'm sorry, I'm gonna have to scroll back to the top. Just give me a
Izar Tarandach:no, no, no, no, no, no, no, no, no, wait, wait, wait, what happened here is
Chris Romeo:20, no, no, no, no, no, no, 20, 20 tech experts share essential details to look for in an SBOM,
Izar Tarandach:yeah, but they don't say experts in what?
Chris Romeo:Okay. Touche. To
Matt Coles:so right, I mean obviously there are bills of material that can contain software today. We, we, hardware bills of materi Hardwa....Bills of material for systems do exist, and they can contain line items that include software. But that's not what we're talking about here.
Izar Tarandach:Look, the main question here is, who is this Bill and what materials did he buy?
Chris Romeo:the
Matt Coles:where, which, and where did he buy, where did he buy them? Because apparently that matters for tax. Uh,
Chris Romeo:All right. So 20 was just talking about the final price, which kind of plays into this whole thing with the, it's like, it's like these folks are just not talking about the same thing that we think of as SBOMs.
Izar Tarandach:Now, I have to, I have to, uh, to be honest here, the first time that I read this article, I had to take a moment and go, am I missing what's happening here? I mean, these guys are experts. I'm not, I'm not. There's a lot going on on the SBOM world that I have no idea.
Matt Coles:The second sentence, the second sentence on the final price, number 20. Then, work your way up. SBOMs will have line items that line, that list changes if the final figure is
Izar Tarandach:No, no, wait, wait, I think that we have to read the whole thing.
Matt Coles:Oh, okay. Always check on the final price to make sure there are no figures that are higher than the original expectations and statement. Let's stop there. We can just stop there. Remember, an SBOM contains...
Izar Tarandach:Do not pay for open source software more than they are asking for.
Chris Romeo:So, is there an invoice inside of the SBOM that I'm not available, that I'm not aware of?
Izar Tarandach:There's certainly a voice inside something...
Chris Romeo:Alright, we gotta end on a high note here, okay? Because Matt Love, no, we can't just be the guys from The Muppet Show that are up in the balcony throwing down just snark and comments and...
Izar Tarandach:I'm sorry, we definitely can, we just won't.
Chris Romeo:We can't, but we have the ability.
Matt Coles:have been a good Halloween costume.
Chris Romeo:That is 100 percent true and I think I'm gonna...
Izar Tarandach:I did my bit.
Chris Romeo:Alright, so let's read number 19 because Matt read number 19 and he was just gaga about this. So 19 says a VEX document, which stands for Vulnerability Exploitability Exchange. An SBOM is only an inventory. When requesting an SBOM,
Matt Coles:That's the statement.
Chris Romeo:You also, that's it? No, requesting, when requesting an SBOM, you also want to request a VEX, or a Vulnerability Exploitability Exchange document. A VEX document is a companion to an SBOM that lists the actual vulnerabilities present in the software, whereas an SBOM only lists the components. With both items in hand, you can begin to better understand the risk posed by using a vendor's software.
Matt Coles:I want to give kudos to Lee for this. He did a great, he or she did a great job on this. An SBOM is only an inventory. If you look at an SBOM, you're going to get component and component version. You can go out to NVD and look for vulnerabilities, and that's great on its own. With VEX, you can communicate additional information. As the vendor, you can communicate additional information to the consumer. When you see this component and this version in your SBOM, and you go out to NVD and you find this vulnerability, Maybe we have an issue, not an issue, maybe we have information that says, well, that's not really exploitable. Or maybe we have additional information to provide that can help you with your risk management discussions.
Izar Tarandach:Yep,
Matt Coles:They go hand in hand. This is an awesome, in my, in my opinion, this is an awesome, uh, awesome statement.
Izar Tarandach:I think that this is one of the best values that comes out of the whole SBOM movement, right? At some point somebody said, hey, you know what, everybody is going to get this big list of packages and versions, and they're going to run in circles to figure out if something is actually exploitable or not. How cool would it be if the vendor had a machine readable way of explaining that out apart from their usual advisories and everything, that people could consume quickly and actually apply to their environment and say, hey, you know what, it's a CVSS 10, but actually for me, no, it's not. So I agree with Matt, like if there is one thing to take out of this article, uh, it's that.
Chris Romeo:Let's end on a high note. It's all about the VEX document. That's the the guidance that we really loved coming out of this. And uh, yeah, read the article, people. Read it for yourself. Draw your own conclusions. Don't just believe what we say, but the article is out there. It'll be in the show notes. You can listen, or you can read it. You can then compare it to what
Matt Coles:You can laugh hysterically. Just
Chris Romeo:but draw your own conclusions. Your mileage may vary. Past performance is no indication of future gain. And all the other Things we should put as caveats to this podcast. Thanks
Matt Coles:Just keep in mind where you're going to do tax.
Chris Romeo:Table Podcast.
