Don’t Sleep on Software Bills of Materials

We chatted with ReversingLabs Software Assurance Evangelist Charlie Jones about all-things SBOM.

EPISODE TRANSCRIPT

PAUL ROBERTS
Hey, welcome back to another episode of ConversingLabs. This is ReversingLabs podcast, where we talk about all topics related to threat hunting, malware analysis, software assurance, software security more broadly. I am your host, Paul Roberts, and with us in the studio right now, I'm pleased to bring you Charlie Jones, who is a Software Assurance Evangelist here at ReversingLabs. Charlie, welcome.

CHARLIE JONES
Thanks for having me, Paul.

PAUL ROBERTS
Evangelist, Software Assurance Evangelist, that's a great title. Are you going door to door or what?

CHARLIE JONES
Yeah, something like that. I'm very conscious. It can be quite an ambiguous title, I get it quite a lot. The most basic way I explain my role is that I kind of help advocate for and educate organizations and individuals on kind of the importance of uplifting the security and integrity of the supply chain, specific to software. And I kind of do that through key activities. One would be external engagement, so speaking at conferences, podcasts like this, industry working groups, engaging with government agencies and also hearing from our customers. And then I guess the second part of that is kind of product strategy. So taking all industry trends, barriers, roadblocks that we're hearing or really success stories and then helping understand how we at ReversingLabs can enhance our product to kind of address the needs of our customers and the broader industry with kind of this ultimate goal in mind of making software supply chain security risk easier to manage for everyone.

PAUL ROBERTS
And just like to kind of get our terms straight. Charlie, when we're talking about software assurance in particular, what are we really talking about? What does that term really apply to?

CHARLIE JONES
That's pretty broad. I guess it ultimately is understanding how you can get comfort in the especially when we're talking about security assurance, the risk, the security risk that can be posed by using software on an everyday basis. And that really applies to I think the easiest way to break it down is to two key personas, which is publishers, so people that are developing and creating software, and consumers as well, people that are buying and using software on an everyday basis.

PAUL ROBERTS
Right. So today we're here to talk about a topic that is getting a lot of attention and certainly a lot of mentions online, and that is software bills of material or SBOMs. These have been talked about and discussed for a number of years and recently they have shown up in guidance from the federal government, from the Biden administration, and you now have companies really rushing to figure out what SBOMs are and how they can use them, I guess, for our listeners. Charlie, could you give us kind of spark notes on SBOMs, what these things are and what purpose they serve?

CHARLIE JONES
Yeah, so I guess in its most basic form, a software bill of materials, an SBOM, is just a list of components and any associated dependencies with those components that make up a piece of software so the analogy that you'll commonly hear describe in SBOM is that it's akin to a food label. Right. So it's just a list of ingredients within a software package. And it helps, once again, these two personas, publishers and consumers, understand what are the underlying components of software that I'm creating, a lot of which is open source code or third party libraries that you're using to create your software, or that you're consuming, so you know what you're actually using at the end of the day.

PAUL ROBERTS
Right. The analog here is, of course with bills of material that are more commonly seen in sort of the industrial world. Right. I think of auto manufacturers or defense industrial base right. Where there's obviously a need to know exactly what parts and components went into a particular vehicle or piece of machinery that rolled off the assembly line. Right. And that's kind of the origin of this whole bill of materials concept.

CHARLIE JONES
Yeah, exactly. I think, like you said, the concept of, I guess, an inventory of parts, especially for software, it's not a new concept, it's been around for years. That being said, I think the general recognition of the security risk that can be presented by third party and open source components is relatively new. And I think it unfortunately originates just like other security risks, and most security risks do from some very high profile attacks that happen on the software supply chain. So something that all our listeners are familiar with. Right. Log4j, SolarWinds, Kaseya, and all of those attacks, like you mentioned, led to some increased attention and oversight from governments and regulators. And probably the most impactful being that Executive Order 14028, which came from U.S. Government, and Joe Biden, which essentially said, come out with some more robust guidance. It tasked U.S. Agencies, CISA being one of them, to come out with some robust guidance over how to enhance the software supply chain. And one of the areas that specifically called out was the need for SBOMs essentially to prove the concept of provenance, the origin of something for software as the components which sit within it, and the validity of those sources and the integrity of those sources, and so on.

PAUL ROBERTS
Yeah, I mean, Log4j was kind of the use case, or the great example of this. This was an open source library that was just incredibly widely, commonly used, that had a serious, remotely exploitable vulnerability in it. And when it was revealed, the vulnerability was revealed, there was this kind of paralysis because many companies, both software publishers and of course, then their customers, the consumers of that software, had no idea whether they were exposed to this. Right.

CHARLIE JONES
I completely agree. It's... We hit this point where it should have been a very easy question to answer in retrospect, in hindsight. Right. The thing everyone struggled to answer was, is Log4j, this widely used open source utility? Is it kind of present in any of the software that I consume or produce. And it seems simple, but it is very hard to do if you don't have this kind of queryable inventory of software components. So when people ask like, why is it important to have an SBOM, the easiest answer is to say the basic right? It's important to understand the components that are in a software that you produce or consume so you can understand the security risk it presents. But honestly, I think it's a lot more important in helping support these kind of response and recovery efforts in the event that, you know, the components within a piece of software and if any of those components turn vulnerable, or turn malicious after six months down the road, after a software package has already been deployed in the case like a Log4j.

PAUL ROBERTS
So let's talk a little bit about the Executive Order that the Biden Administration released last year. I think it was in May of 2021 that came out. Talk about the kind of impact of that. As you said before, software bills of material were mentioned in that Executive Order, but what impact has that had on software bill of materials use in the interim? What does it mean for the federal government and for the software industry at large I guess?

CHARLIE JONES
Yeah, the Executive Order and the impact is kind of a lot to unpack. So essentially there was a section within the Executive Order, section four, and once again it directed government agencies, NIST being one of them, and CISA being one of them, to solicit input from various stakeholders across the industry. So private sector, academia, other government agencies. And so what they did is they published kind of this flurry of guidelines to once again help enhance the security and integrity of the software supply chain. And that's exactly what they did. So they came out with a few pieces of really helpful guidance. First one being they helped define or created a definition for what is critical software. And that's really important because it helps organizations take a more risk based approach to managing software. Right. You can't monitor everything, you can't assess everything for security risk. So being able to target what is critical is really important. The second piece was SSDF. So the Secure Software Development Framework that was developed by NIST came through the form of you're going to test me here, special publication 800-218. And then recently, they also published, in coordination with ODNI, the Office of Director of National Intelligence and NSA. A terribly long name. It's something like the Enduring Security Framework software supply chain working panel. They're coming out with essentially what's very helpful in a three part guidance for what they define as publishers, suppliers and consumers of software, all telling kind of defining the division responsibilities which exist between those key stakeholders and key roles and other guidance. And then most recently, probably the most impactful of government actions was it came about two to three weeks ago was a memo that was issued by the Office of Management and Budget, which is an executive office of the President of the U.S. And they essentially required an attestation against all the requirements that are listed out in SSDF for any organization that provides software to U.S. Executive Agency. So that means any new software that's built any major version change to existing software that's already provided to U.S. Government agency, or any software renewal in the event that they're providing software through a subscription based model, and that includes SBOMs. Right. SSDF explicitly says a couple of things about SBOM. So first, this concept of provenance right, you need to prove the origin of...

PAUL ROBERTS
Again, SSDF, the NIST Secure Software Development Framework. Those are the NIST guidelines for secure software development.

CHARLIE JONES
Yes. 800-218. The most important thing it does is it enforces kind of various requirements about not only the generation, but the distribution of SBOMs. So it has this concept of there's a requirement that explicitly says publishers need to share provenance information or make it available to their consumers. So at the end of the day, to summarize, what does it mean, the Executive Order? It means a lot of helpful guidance for publishers and consumers. And hopefully it means we know it means a fundamental requirement for certain publishers to provide SBOMs to the U.S. Government. And hopefully that transitions into or translates into SBOMs, becoming generally more widely available for consumers. It hopefully breaks down that barrier and makes requesting an SBOMs from a consumer a little bit more of an approachable topic for consumer, not this ridiculous audit request which it once was.

PAUL ROBERTS
Right. Sort of makes it kind of standard operational procedure for software publishers selling into the government space. Right. Good points. The memo that came out a couple of weeks ago also talks about SBOMs. Again, as you said, it's really about self-attestation for software publishers. But it also says you may be asked by a federal agency to provide an SBOM, especially if you're licensing what they term critical software to the federal government and basically sort of saying that's one option available to federal agencies, but not mandating it. Did I get that right?

CHARLIE JONES
Yes, I believe so. And along with any of these, sometimes you'll see these headlines that says all these requirements are all of a sudden mandatory in order to do business with the U.S. Government. I've seen a similar post, I think it originated through Twitter that was saying everyone was blowing up about that, oh, you couldn't have a critical risk vulnerability in any software package that's provided to the U.S. Government. It's not true. If you continue reading in them, it does say that, and it seems like a very stark requirement. But if you continue reading, especially with this memo, it essentially says, in the event that a software publisher can't meet a requirement in SSDF, they are able to define rationale for why and come up with a remediation plan. For how they're going to mitigate that risk so that the U.S. Government agency can make a risk based decision as to whether they're comfortable with that. It is a step in the right direction. I would love to see like, evidence based attestation and not self verbal attestation, but it's certainly moving in the right direction without making it entirely restrictive for anyone to work with the U.S. Government at the same time.

PAUL ROBERTS
It should be noted as well, there's also plenty of wiggle room for extensions or even exemptions from these requirements, depending on the need of the software supplier. And there are timelines for appealing to the agencies for either of those. So as is always the case with these types of mandates, a fair amount of wiggle room for individual software publishers, right?

CHARLIE JONES
Exactly.

PAUL ROBERTS
Let's talk just a little bit about so we're talking about SBOMs, software bills material, being a requirement in the federal government space. If we look outside of the federal government space, what does SBOM look like there, Charlie? Just in the software industry in general, is it common practice, are they commonly used, or is the federal government kind of getting out front here a little bit with this?

CHARLIE JONES
Yeah, I think we're certainly seeing industry awareness increase willingness and eagerness on the publisher and consumer side, which is good, definitely trending upwards. We've seen that not only in some of the industry working groups I'm involved in. So CISA led some really helpful SBOM listening sessions where they covered various topics about software bill of materials, adoption, transport of SBOMs, consumption of SBOMs, SBOMs in the cloud, all those types of things. So seeing it there certainly and there's also a really interesting study that the Linux Foundation came out with earlier this year that supports those trends as well. So a few of the interesting stats that I'll pull up here. The first is in terms of awareness. So 82% of both publishers and consumers are actually now familiar with the term SBOM, which it seems like a very kind of fundamental statistic, but it is truly an achievement and that we're moving in the right direction. We're starting to see increasing numbers of people that are actually expecting to produce them in the future. So it looks like 78% of all organizations are expecting to produce them in 2022 and onwards. And then in terms of current usage, 76% are actively engaged in addressing SBOM needs, which I think that essentially means they're investigating the acquisition of tooling to allow them to generate it maybe in an automated manner or consuming in an automated manner. And then the final one, which is probably the most powerful, is that 47%, so almost half are actually currently producing or consuming SBOMs. So a lot of room to grow. But once again, I think we're moving in the right direction towards adoption, especially with the fact that almost half of people are actually using them or producing them now.

PAUL ROBERTS
So one of the things that I think complicates some of the guidance coming out of the federal government is just the really complex nature of how most organizations are both deploying and consuming software these days. Right? We're very much in a hybrid environment where most companies of any size have a mixture of software that they are running locally on a network, as well as increasingly cloud based services and applications that they are licensing, but that they don't own the infrastructure for themselves. I'm trying to wrap my head around how we do SBOMs for cloud based applications and platforms that we don't ourselves control. So maybe you could kind of walk us through how that's supposed to work.

CHARLIE JONES
You are not alone, Paul. That is something that everyone currently in the industry is dealing with. Cloud definitely introduces some interesting barriers to adoption because of, like you said, the dynamic nature, the elastic nature of cloud services, kind of like you said. So as organizations continue on, I guess what I call and what I've heard other organizations deem is this cloud first architecture and furthering their cloud transformation journey. We're seeing more and more cloud native applications being built, and as a result, also SaaS services being consumed as well. So it kind of begs that question, like you're saying, how do you maintain SBOMs for cloud based applications, where the underlying components and services, things that make up SBOMs are very dynamic and elastic and change at a much faster rate, the seconds and minutes than a normal, like, traditional, on prem, built and hosted application. And honestly, there's not really an answer right now in this area. This is something they are investigating as a part of these SBOM listening sessions and CISA initiatives, working groups, and I guess an important distinction that's worth making. I was on a call yesterday, or sorry, not yesterday, earlier this week, and someone from 0Asp had joined and was talking about the fact that Cyclone DX, one of the common data formats for generating an SBOM, actually supports the generation of SBOMs for three different use cases. So a standard SBOM, which is components and services in the cloud, something they call a SaaSBOM, which is only services, only cloud services, and the dependencies that those have. And then SBOMs for cloud platform applications. So low code, no code applications in the cloud. So it was interesting, to me at least, because the barrier in adoption isn't generating them itself. It's more in this kind of producer consumer relationship in terms of open questions that exist, right. The frequency that they need to be generated and shared, right. Is it every minute, every single time something changes or a major change? Another question that popped up was uniqueness. So if I'm a producer, do I need to generate and share a unique SBOM in the event that every single one of my consumers of that application is consuming slightly different iterations of components and services in my cloud environment and then sharing it. Do I need to share it in a unique way with every single person? So it creates this massive amount of overhead that I don't think either want to deal with. So it will be interesting to see how it plays out between those two parties.

PAUL ROBERTS
Right. And in some ways, the whole concept of an SBOM kind of presupposes that the software in question is relatively stable. Right. Which, in the case of agile cloud-based applications, isn't the case. They're changing all the time, maybe even on a daily basis. The kind of makeup of the service itself, which raises some really critical questions about what that SBOMs, even if you have it, how much it it adheres to what's actually being deployed and run.

CHARLIE JONES
Yeah. And do you have the resource? Like, if I'm thinking from a consumer standpoint, even if I get an SBOM every single day, every 12 hours, with new components and new services in it that have changed in the background, do I even have the resources to maintain that, investigate those changes? Probably not. That's where automation comes in, and we could probably talk about that later. But the role of automation in managing all of these changes and the thing is, in cloud based app, if you're a consumer yes, multiple SBOMs, being on top of the components and services that you're consuming at any given point in time is important. But you also have hundreds of other applications that you're consuming at once. Right. So if you extrapolate that in cloud services, you can't deal with hundreds of thousands of SBOMs at once. It's just too much without any form of automation.

PAUL ROBERTS
Right. So let's put that problem aside and sort of figure out, sort of say, we're going to all have to deal with that problem one way or the other, reach some kind of compromise on it. Let's just take a look at the SBOM question itself. There isn't right now a mandated SBOMs format that organizations selling to the federal government have to use that presumably will come at some point in the future. I think 180 days is the timeline that's the memo laid out. What are the choices that organizations have right now for SBOMs? And how can you operationalize these? How are organizations expected to make use of these?

CHARLIE JONES
So there's no mandated requirements, like you said, there are some guidelines that were published back in 2021 by NTIA, so the National Telecommunications and Information Administration that have since been taken over by, or being actively worked on by CISA, which define kind of a base level criteria. So the base level components that should exist in an SBOM. And there are things you're probably familiar with, like the supplier name, the component name, dependency relationships, timestamps, things like that, that you would expect to be in every SBOM. But there are certainly things that can be put in an SBOMs that are either marked as there's like a recommended or optional session in the back of the section in the back of the NTIA guidelines or some things that were left out that I do truly think make an impact in inclusion of an SBOM. Especially when you talk about the context of security. So the three things I typically call out, one is vulnerabilities. So I understand the components that are in my software by software bill of materials, but are any of those components vulnerable? And you can take some different characteristics of vulnerabilities. So are any of the vulnerabilities currently exploited? You can use things like the KEV, the Known Exploited Vulnerabilities catalog that's published by CISA. Are any of the vulnerabilities actually mandated to fix? Or are there security advisories that have been published by governments or Five Eyes Nations to fix those vulnerabilities? And then the final one with vulnerabilities is, is the vulnerability actually exploitable in the application? So slightly different than exploitability, but CISA actually noticed this issue very early on in this explosion of vulnerabilities associated with open source and third party components. And they recognize that despite a vulnerability, sorry, a component being vulnerable in an application. So let's say you have Log4j, which has Log4Shell, a vulnerability associated with that component that's actually using your application. It doesn't mean it's actually exploitable imposing material security risk to the consumer. Right. It may not sit in the kind of execution path and therefore may not impact the consumer. So they created this thing called VEx, Vulnerability Exploitability Exchange, something that I actually contribute to and we at ReversingLabs contribute to, but it's essentially a mechanism for producers to define exploitability status, to say, yes, Log4j exists, but it's not actually going to impact you. So vulnerabilities are one thing beyond those traditional kind of components you would expect. The second thing I would say are cryptographic hashes. So those become useful in what we call high assurance use cases for SBOMs. They essentially provide not only producers, but consumers as well, what we call kind of a more robust identifier for the source of a component. And robust Identifiers become important because they allow you to do two things. The first is identify whether component is actually the one you intend to use. So they help prevent against these things called typosquatting attacks. Sometimes they're called dependency confusion attacks, an attack technique that our researchers at ReversingLabs have posted about several times.

PAUL ROBERTS
Supposed to be like a hash value or something like that.

CHARLIE JONES
Exactly. So essentially using hashes of components and identifying whether the components that you're downloading are the legitimate ones you expect and haven't been susceptible to typosquatting attacks. Right. The second thing is helpful in understanding is if you have a hash of a component, being able to associate that with a hash of a file, that we've noticed to be malicious using things like file reputation and intelligence services, something that we pride ourselves in and providing at ReversingLabs. So once again, being able to tell you is there a component within my SBOMs that actually relates and I can tie directly to a malicious file that we see operating in the wild and then beyond vulnerabilities and hashes. The final thing, which I would really like to see this is a little I'm hoping for, but I haven't seen it yet is support status of a component. So is a component actually supported by a maintainer or publisher or has it reached kind of end of life, where we deployed in our environment and six months down the road a vulnerability pops up in it and we have no support, there's no way to fix or mitigate that risk. So what those things, those three things do is allow you to kind of extend past the initial thinking of, okay, I have an SBOMs, I understand what's in it and apply some security context to it. So it's actually valuable to a producer and consumer and saying, okay, I know these components. Are they vulnerable? Are they malicious? Are they the actual components that I intend to use to stop from these types of modern supply chain attacks that we see targeting the supply chain today?

PAUL ROBERTS
Yeah, I mean, that's a really important point, especially with the end of life stuff because as we know, particularly in the federal government space, there is a lot of software that is end of life and a lot of maybe even more granularly components, libraries, what have you, that may no longer be supported but are still being used. Let's talk on the other side. So that's about the producer side. Let's talk about the customer side, the consumption side, which is how are, let's say, federal agencies in this case, or in the private sector, customers supposed to operationalize these SBOMs that they're going to be getting from their suppliers, from their software suppliers. You talked about vulnerabilities and vulnerable components. This all really comes down to some really well established practices about vulnerability management and hardening and mitigation, stuff like that.

CHARLIE JONES
Yeah, I think it's interesting because I've seen a lot of companies kind of frame SBOMs and software DevSecOps practices and kind of secure software supply chain practices as really being focused on the developer. And it's important, right, because a developer can influence a lot of the things that they find in a software package before it's published. If you identify secrets in a software package, you can fix those secrets. If you identify security misconfigurations in a software package, you can harden that software package before you publish it. Same with vulnerabilities, malware components, those kinds of things. It doesn't mean it's not helpful to a consumer in making a risk based decision as to do I want to onboard the software or do I want to go with another provider or do I want to deploy this in a way, in a restricted manner where it sits behind additional firewalls or in a kind of segmented part of my network where I can protect it a little more? So I think the same characteristics and understanding vulnerabilities and components and malware associated with components is still very valuable to a consumer. And one of the ways I've heard it put very well is extending the kind of food analogy that I mentioned before. So people always say, once again, software bill of materials is like an ingredients list in food. But how often from an actual physical consumer standpoint, do you look at a list of ingredients on a food package or cereal box and then decide, I'm not going to eat that? Like, very rarely do you ever do that because a lot of times you don't even understand what they are. So I heard this extension of the analogy to say, okay, I understand what ingredients are in my food. Have any of them been contaminated in any way? Have any of them been recalled in any way? And you can extend that thinking to SBOMs as a consumer. Right. For this software that I'm about to deploy in my environment, are there any indicators that this is actually going to present material security risk into my environment? And it doesn't mean that you can't use that software package. You absolutely can. But you need to make a risk-based decision. You need to accept that risk and you need to mitigate that risk in some way. Whether that be through certain deployment models, whether that be through segmentation additional tooling, additional controls, those kinds of things.

PAUL ROBERTS
Yes, I think it's a useful analogy in this case, for sure. Talk about how you think software bills and materials might be used out there just privately between software publishers and customers. Right. So we have this ideal of transparency and SBOMs are going to be issued publicly by software publishers. Kind of like that list of ingredients, everybody knows what's in our stuff, but some publishers might not want to do that. On the other hand, some of their customers might want to be able to look at an SBOMs either as part of a purchasing decision or just for their own purposes. So how do you think that's going to play out out there in the broader software market?

CHARLIE JONES
That is a very hot and contentious topic amongst publishers...

PAUL ROBERTS
That's what we do here at ConversingLabs, hot and contentious.

CHARLIE JONES
I like it. I think in a perfect world, the easy answer is it's good to be transparent. Right. And what's in your software? It would probably honestly make it very easy or much easier for publishers and consumers if everything was public and it was shared on their website and anyone can download it and like you said, make a risk based decision for procurement. That being said, do I think that will ever happen? Probably not. And there's no requirements to enforce that right now. Right? I think it's ultimately going to come down to right now what the publisher is comfortable with, and also kind of what contractual obligations a consumer can actually enforce because the producer holds the cards. Historically, especially in kind of software supply chain relationships, it's not something that's been built into contracts. The traditional contract may look like a shrink wrap agreement or an end user licensing agreement. So that kind of right to audit.

PAUL ROBERTS
I agree. Yeah. You're just kind of like you're not even reading what's in it, but yes, right.

CHARLIE JONES
Yeah. So I think as the concept and awareness of supply chain risk, software risk specifically continues to gain traction, I think we'll start to see my predictions would be that power starts shifting back to the consumer as SBOMs will be more readily available for consumption once again. It won't be this over the top audit request. So now there's tools out there that if you have the binary, this is what one of our tools, secure.software does. If you have the binary alone, you can generate an SBOM, you can do all the security analysis you need to do without hoping that the supplier is going to provide you that evidence and having to go out and get it. So I think we're starting to see power shifting back into the hands of the consumer to make those risk based decisions.

PAUL ROBERTS
Yeah, I mean, it's kind of interesting in some ways. Obviously, this conversation centers on the federal government and guidelines for federal agencies. In some ways, it's kind of an unusual situation or context because the federal government, of course, is one of the basically the only customers or one of the only customers who actually is big enough and has enough leverage to force companies like Microsoft and Google and Apple to do what it wants just because it buys and licenses billions of dollars of software. But individual companies, enterprises, even very large ones, often don't have that kind of leverage, and yet increasingly need transparency and need cooperation from that software publisher to help them manage their own risk. Right. More maybe than a publisher might be inclined to give them. Right?

CHARLIE JONES
Absolutely. That is a great point. And it's funny enough, there is that exact issue that sometimes referred to as kind of limitations due to structural imbalances in the supply chain that extends to every relationship in the supply chain, not just software suppliers. So DCMS, the Department of Digital Culture, Media and Sport in the UK, they released this call for views on supply chain security towards the tail end of 2021 that I actually contributed to with some of my colleagues. And they came out with kind of these they essentially reached out to all organizations and individual professionals in the UK and asked for some guidance, some feedback on some of the issues that they were having associated with managing risk in the supply chain, more general supply chain security. And they kind of tabulated five key barriers and trends that they were identifying. And one of them was the structural imbalance. Right. So there are some major players in the software supply chain industry and other supply chains as well, that even if you do have contractual rights, like the right to audit, if you want to work with them, you aren't going to be able to enforce those contractual rights because they're going to say, look, I have a SOC Two report, I have an ISO report, I have a PCI DSS report. That's all you're getting. And if you want to work with me, sure you can use that. Otherwise I'm not bending over backwards to do the traditional two, three day onsite assessment and invasive testing. And so organizations really need to once again figure out ways to bring the power back to themselves and do testing on their own fruition, to make their own decisions using data that they can collect themselves. And that's why things like binary static analysis of software is so powerful, because it gives consumers that ability.

PAUL ROBERTS
Absolutely. I think this is a really interesting question. I mean, I think one of the things we were talking earlier, one of the things that might help balance out a little bit is kind of technology that empowers customers to do their own assessments absent cooperation. Kind of asymmetric warfare in a way, sort of saying, giving them some sense of insight into what they're using without necessarily having the cooperation of the vendor. I think it's a really interesting concept. Okay, final question for you, Charlie. I've kept you long enough, but the scope of this for organizations that might be using hundreds of different applications and services is large in terms of managing all of this, all the information from the SBOM, operationalizing it, is there a role here for automation to help ease the burden on already obviously understaffed overburden IT teams?

CHARLIE JONES
Yes. I think automation is a must, right. In order to actually gain traction and achieve some sort of successful integration into your existing business processes and support actual business decision making for generation and consumption. I think it needs to be automated. Right. Modern software packages are too big, too complex, include too many components to do anything manually. And once again, like you said, it's not just the dynamic nature of a cloud application generating hundreds of SBOMs potentially a day, but it's the fact that you're also managing hundreds of pieces of software at the same time. So it's simply not feasible to get any sort of value out of them unless you do it in an automated way. I think there's different ways you can use automation, right? Some feasible ways are like the obvious one, generating an SBOM and tabulating those components. You can also use automation to look at differences between version releases. So when you get different actual SBOMs being able to compare using automation, what has actually changed? So have there been any new components added, modified, deleted new dependencies added within components, those sorts of things. And then the last one that is slightly different is the ability to be notified or alert on changes in component status. So if you generate an SBOMs before you deploy something into production, that SBOM may not change. So even if a component doesn't change, the status of a component may change from a security context. So it may go from a legitimate component. Maybe log four J was legitimate component that was used by people at some point in time and then over time after deployment, it actually goes vulnerable or it turns malicious or something like that. The ability to continuously monitor the components in those SBOMs and alert when something goes from good to bad is also really important. I think that's another huge area where automation can provide some very valuable benefit, especially to consumers.

PAUL ROBERTS
Really interesting stuff, Charlie, and we've seen so much guidance and guidelines and mandates coming out in recent months. I'm sure there's going to be just a lot more discussion about this going into 2023 as federal agencies and software vendors try and figure out their way through that guidance, try and figure out what it means. I hope we could have you back to keep us updated on this.

CHARLIE JONES
I'm glad to be back. Any time I could talk for years and years and years about software supply chain, so unfortunately, it's one of the things I love.

PAUL ROBERTS
Don't get me started.

CHARLIE JONES
One of my hobbies.

PAUL ROBERTS
Hey, Charlie Jones, Software Assurance Evangelist at ReversingLabs. Thanks so much for coming on and talking to us on ConversingLabs. And we'll do it again.