Transcript: SBOMs Explained, with Douglas Schmidt

Daphna: Hello. Thank you for tuning in to this Fast Chat on Software bill of Materials, or SBOM for short. My name is Daphna Krause. Today I'm speaking with Professor Doug Schmidt. Doug is a Cornelius Vanderbilt professor of Computer Science engineering. He's also the Associate Provost of Research and Data Science Institute, co-director, all at Vanderbilt University. Thank you for taking the time to talk with me today. 

Doug: You're very welcome. It's good to talk to you. 

Daphna: So let's jump right in. The cybersecurity and infrastructure security agency says SBOMs have emerged as a key building block in software security and software supply chain risk management. Can you explain what an SBOM is and why it is now included in software security development?

Doug: Software bill of materials, or so-called SBOM is essentially a record, a rigorous systematic record that describes the details and the supply chain relationships of components that are used to build software. These components can be all kinds of different things of course, they can be files, they can be documentation. Often they wanna be source code. And uh, having knowledge of what goes into software systems is important if you wanna be able to manage them effectively, especially with respect to security fixes and vulnerabilities and updates and patches and so on.

Daphna: So what does an SBOM need in order to gain insight into an application or software?

Doug: It should essentially provide knowledge of things like who's the, who's the author of the software that's being considered, uh, the name of the supplier, what, what organization or or company it might come from. Clearly the name of the components are important.

Also important, our version information, either a version string or some type of encoding that indicates which version it is perhaps a, a hash of some times. You can hopefully uniquely identify different versions or changes between versions. Should also be some kind of unique identifier, which could be a hash or, or some higher level way of being able to name the component as well as other information like relationships, license, type, whether it's open source. If so, what type of open source is it closed source? What restrictions may there be on using the software.  Also basically the chain of custody, which is sometimes called the provenance.  Who's had access to this over time? These are some examples of things that should go into describing the elements or components in an SBOM.

Daphna: So an SBOM, we'll just be able to collect all that information essentially. 

Doug: There's a couple different ways to look at it.  Classic SBOMs would be something like a, a recipe of some kind where it lists the ingredients, or maybe a list of ingredients that you could use to know whether you're allergic to certain things or how much sodium there is that type of information is historically very static and might represent the state of the component when it was originally developed. More useful in SBOMs, in my estimation, is also the inclusion of dynamic information. So maybe a, maybe a list of ingredients isn't quite the right. Analogy, but maybe something more like an MRI that someone might get taken every couple of months or every couple of years, that would give an in-depth insight into the inner workings of something, so you can see changes over time, and I think that's particularly important with respect to security because oftentimes, Systems are patched over time, often not at the source code level, but at the object code level. And so being able to keep track of version information that's more dynamic is crucial because over time, the contents of the material that you're keeping an inventory of your, your SBOM is referring to may no longer reflect the initial state of the software when it was released in the first place.

Daphna: So you touched on like a really important conversation right now that's happening in the cybersecurity sphere, the difference between static and dynamic or living. And so the major question is that notion of a living SBOM that we need to move away from the static views of vulnerabilities and shift to dynamic or living SBOMs so what are your thoughts on that line of thinking?

Doug: To the extent that an SBOM is being used as a way to determine vulnerabilities of software that's deployed in the field, it's absolutely crucial to have dynamic information. It would be, again, going back to my MRI scan analogy. If you took an MRI scan of a person when they were a teenager and then didn't update it by the time they were in their middle age  or later years, their golden years, you would undoubtedly miss all kinds of things that have been happening dynamically inside their body. Growth of tumors, various types of decay of organs or other material, bone structure, bone density, and so having an up-to... Conceivably very real-time dynamic view of what's going into a system is crucial. And I think part of the challenge here is when people think of a bill of materials in the classic sense, they think more of something that could be described statically, like contents of a shipping container, which conceivably wouldn't change a whole lot from when it was packed to when it was shipped or when it was opened.

But in reality, as I mentioned before, a lot of these systems, it's not just the software, it's the, it's the runtime representation of said software in the form of object code. And it's crucial that we be able to track that information because that's really where the vulnerabilities lurk. It's, it's not so much the original. Bill of sale or the bill of material, it's what's currently running or currently deployed that really matters.  Another good example might be trying to keep track of the components in an automobile in order to know whether or not the components are subject to recall. Back in the day, this would be things like seat belts or transmissions or the air conditioner or the brake system, the, mechanical pieces.

But as we all know, cars are increasingly software enabled. And so it's also just as important these days to know which version of software your car is running, especially for modern cars, where you can do over the air updates of the software, and so having an up to date notion, a dynamic notion is crucial because otherwise you're really playing with a flawed hand, if you will, to use a card analogy. It's like someone trying to count cards and they only know what the original hand of cards was, but they haven't been keeping track of what's been going on as cards were played on the table and picked up and put down, and so on. So this dynamic view is absolutely crucial if we want to use. SBOM as a representation or as an aid to be able to accomplish more, secure software, software that's going to be free of defects. And of course the other challenging part here is that when patches are applied to software, they don't necessarily fix all the problems. In fact, sometimes patches will fix one problem and then introduce new problems.

So it's a moving target and having a dynamic view that is updated, ideally in some kind of database that can be queried is crucial as opposed to just scrolling these things down on, uh, napkins or pieces of paper and putting them in a filing cabinet.

Daphna: So SBOM in vulnerability management require a catalog of known vulnerabilities. Do you think there's still a place for SBOMs in software security given this limitation? 

Doug: So it's not really clear what the limitation here is. In other words, knowing what threats are out there is necessary though by no means sufficient to be able to do an effective job of trying to patch systems or update them to address those vulnerabilities.

A couple issues here, let's, let's try to unpack them. First of all, the list of vulnerabilities will always be essentially, an estimate, it's a snapshot in time because vulnerabilities are dynamically changing as well as as new vulnerabilities are revealed. So the vulnerability database, assuming we have one, is only as good as its contents, and then we have to find some way of being able to correlate or associate known vulnerabilities with the elements that are in the SBOM, which as I mentioned before also should be looked at dynamically.

And so both of those things are moving targets and neither one supplants, the other, the list of vulnerabilities is crucial to know where to look in the SBOM to figure out if you're, if you have a known vulnerability. But I think, the key issue here is that even if you have a very UpToDate list of vulnerabilities and also a very up to date, Notion of what your, what the contents are of your software and your, your, your SBOM, you're still at risk because there could be unknown vulnerabilities and there could be unknown issues with what's in the SBOM.

And so in some sense, what we really need is, is more than just an inventory or a list of these capabilities. It would be even better if we had some results of running scans or vulnerability assessment tools or other kinds of code coverage tools to be able to get a better sense of the properties of the software.

I don't think we're quite there yet in terms of a technology ecosystem to be able to enable the use of automated tools to inform the vulnerability checking. But that's certainly where we want to head. 

Daphna: So the goal of SBOMs is to add transparency into complicated systems. Why are security systems increasing their complexity when that can cause complications and vulnerabilities?

Doug: I think there's a couple reasons. First, of course, the software systems we build are complex because the requirements and the environments and the external,  threats if you're in a military environment, continue to get more and more complicated and more and more sophisticated and more and more interconnected.

So as systems grow and scale, they often grow in complexity because you have to reflect the requirement growth and the environment evolution in the system implementation. So that's, that's just par for the course as things get more complicated. It's also worth pointing out that more and more systems today are assembled out of components, that are not necessarily developed in-house by one group. They're very, very often assembled from off-the-shelf components, some of which are open source, some of which are not, and they're often... they often use very sophisticated frameworks and platforms like Android or spraying or various JavaScript environments and so on for enterprise web applications.

And so on, and e-commerce applications and these platforms themselves are very complicated, and they have many, many, many parts. In fact, leaving out the whole issue of vulnerabilities, just trying to get these systems to build and deploy and run properly is hard enough. But I don't think we're going to see a world where we're gonna get rid of all these complexities because the, the growth in requirements and environments keeps evolving and very rapidly.

So at one level, it's, it's not surprising that we would have this challenge. I think that the real question is, do we introduce new... attack vectors, new threat vectors by publishing our bills of material. And the answer is yes, you can introduce new threat vectors, but it all depends of course, on how widely propagated the bills of material are. Is that something that's only known to some certification group or some quality assurance or security threat assessment group within an organization? Is it something that's more broadly published? And I think another thing to consider here is that the, the attackers oftentimes can quickly discern the versions and the components we're using, whereas oftentimes the people building the system are precluded from doing this.

So, It's, it's really,  what, what we sometimes call an arms race,  where people who are bad actors can leverage our tools against us, and we simply have to remain eternally vigilant to update our systems, patch them, do the best we can to keep abreast of vulnerability, databases, and best practices and techniques to try to make our software secure and resilient and scalable.

Daphna: So when you're creating the list of everything that goes into like the recipe for your system that's being used for regulatory components and like certification or it's just the developer side or the DevSecOps side? 

Doug: I think it depends on the type of system you're developing. If you're building a simple system that's really not subject to regulatory control. Maybe a personal website, for example, that you want to use to promote what you do, or  social media site, those types of capabilities, the SBOMs and so on are used more just to make sure that you're not doing anything gratuitously harmful to your software as you start getting into more high confidence domains, things like medical devices or military or  cyber intelligence worlds where you have classified information, then it's very likely that this information goes into a broader regulatory regime to try to assess whether the people who built the system have followed the best practices that are part of that regulatory regime. So I think it really depends on the context in which the systems are being built as to how mission or safety critical it is, or how classified it is, versus whether it's just intended to provide entertainment or read only access to information about a person or an organization.

Daphna: Doug, thank you so much for your time. And to our listeners, thanks for sticking around. For more information about Rampart AI's resilient application solution head to www. rampart-ai.com. Until next time, stay secure.