How to Leverage SBOMs to Reduce Software Supply Chain Risk

Hello, everyone, and welcome to a talk on how to leverage s bombs to reduce software supply chain risk. We're gonna be looking at some challenges and opportunities in securing the software supply chain today, and we're gonna have a heavy focus on SBoms, our software bills of materials. And how you can use those, as well as what else you might need in addition to the SBOM. So very briefly, a quick introduction about me. I'm Jason Ortiz. I'm engineering manager at Finite State. I have spent the vast majority of my career in cybersecurity in one way or another. A graduate of Purdue University, And then before Finance State, I spent most of my fifteen year cyber career in government at both NASA and NSA. And then I jumped out and joined an exciting startup in the supply chain security space, and that is finite state. Let's jump right in because this is a relatively short talk and we have a lot of materials to cover. So just wanna lay the groundwork a little bit here on why attackers really love OT or IoT. There's a couple of sort of big picture ideas that we get in IoT or OT that we don't typically get, in a traditional IT environment. And one of those, of course, is access. You no longer have control of physical access of the resources. IoT is everywhere. Operation technology is everywhere. You can't simply lock servers in a room anymore. So physical access can no longer be guaranteed. And software defined physical functions and critical environments plays a big part of this as well. So you may have software components that control physical things, machines and gates, and, that allows for a much larger attack surface. You also have an surprising lack of coverage on the security side, application security tools, manage detection response tools, network monitoring, all of those traditional things that we've heard up, heard of in the security space over the last fifteen or twenty years, don't really cover connected embedded devices very well. You can't run an agent on a on a tiny embedded device for the most part. So those things have little security coverage. They also have relatively low security priority for manufacturers of those devices. Since we're looking at security as a risk management problem, if your device, your product is not at risk of sales from a security perspective, you're probably not going to prioritize security of that particular product. We also have very a lot of difficulty in patching and updating those things. They they can be ubiquitous. They can be connected and not connected. They can literally exist just about anywhere and infrequent patching and updating as a result of that. On top of all of those sort of more traditional views on security and what challenges IOT present, we also have this huge new thing we're gonna talk about today, and that is the supply chain security, and taking a look at all of the opportunities for vulnerabilities and configuration errors to essentially enter the ecosystem before a device ships. In addition to that, we have extremely limited visibility into those supply chain issues. And that's what we're really gonna try to address with the S bomb today. So for the business side of it, you know, that was kind of the technical side of it, but if we think about the business aspect, since this is a risk management problem in terms of cybersecurity, What are we using those products for? Well, obviously, we're using them to collect data in most cases. Now, this is this can be b to b, this can be end of consumers using them. You have some in your home most likely businesses are certainly integrating them and they're doing so in order to connect data on process is how things are functioning and using that data then to make automated business decisions to improve those processes to adjust financial forecasting, technical forecasting, it all plays a big factor into the risk management decisions. So with that high level of integration of connected products and understanding whether or not those connected products are secure, Most of our security teams are probably asking themselves this billion dollar question right now. And that is if a new CPE were disclosed today, that impacts some of the products or the products you use in your organization. How long would you would it take you to find out which product and which versions of those products are impacted, and potentially even an add on here, can you even remediate those if you do discover them in a timely fashion. So I've got it. We'll start an APAC program. We'll start testing on the left, and we'll figure it all out. But where does apps are truly fit in in the overall cybersecurity framework? Does it cover all of our bases? Isn't the only thing we need? Of course, everyone is probably shaking their head no right off the bat. Apppsack is a great tool, but it is just one tool. It does not consider context. It doesn't consider exploitability, for example, if you find a vulnerability, How exploitable is that vulnerability? It doesn't consider things like network context or configuration context because it doesn't know about those things. Those things are all to the right of all of our application security analysis. In addition to that, you know, application securities heavily geared toward web and mobile applications and really struggles to kind of, produce value in the embedded lives languages, R tosses, etcetera, and those sorts of fields. So without that, without the the focus on the connected products and the supply chain, without context. It becomes really difficult, within a product security or supply chain security framework to prioritize any of your findings with an application security only approach. So I've mentioned the supply chain a couple of times now. Here's the point where we really need to look out where vulnerabilities enter the supply chain, in a connected product. So this is kind of the heavy developer slide. If you have a software development shop, this is where they're going to live and work, and this is where they're gonna be introducing vulnerabilities along the way. So starting all the way on the left, obviously open source. Almost everything we write in code, is based on some layer off of some open source packages, libraries, etcetera. And of course those contain Cves, especially when we use multiple versions of open source. From there, we can move into what we call third party software. So this is vendor source software. So it's outside of your control as an organization. It functions very similarly at open source except that it's coming from a specific organization, as part of the product that you might have purchased. Those all potentially have vulnerabilities that may be undiscovered and undisclosed as well. Then, of course, you have your first party, code. This is where your engineers internal to your organization have written a new software specific to that device or the use of that device. And naturally, just like in the third party case, they can create security issues, mostly unintentional, unless, of course, it's an insider attack, and then it could be a potentially an intentional introduction of vulnerabilities. So all of those things live in the development shop and the development arena And we can address a lot of those kind of on the left hand side of analysis. But then we also have configuration and updating and patching here on the right. Not to mention, once you actually compile everything together and ship the product, all of that analysis that you did on open source packages, for example, may have changed in in terms of what's actually dynamically included in the product software. So digging into that a little bit deeper, we looked from the technical perspective on where those vulnerabilities can the supply chain. But now let's take a look at the business perspective of that and see where a lot of that code comes from. So all the way on the left of this chain, we're gonna look at a software supplier. So this is literally an organization whose job it is supply software, hence the name software supplier. They build general purpose software components that are typically incorporated into other things. In this scenario, about seventy percent of all the code that they use is gonna be first party code to the software supplier. They are creators of software in this particular chain. Even so, thirty percent of that is typically not created by the supplier. It's probably built off of existing library from other supply software suppliers or off of open source. Now as we move to the right, we're gonna get to a greater number of organizations that fall under each one of these chain links. So there are a handful of software suppliers there's a handful more component suppliers. And these are groups organizations that build complex hardware systems that act as entire components in other products. The component suppliers were looking at about forty percent first party code. So now we're already under half of all of the code in that product as created by the component supplier themselves. Sixty percent came from open source software supplier, that third party part of the chain. Once we get to more common organizations, device manufacturers, these are the organizations that are building the entire system, typically the thing that another business or a consumer would purchase Only about twenty percent of all of the code in that device at this point was created by the device manufacturer. So four fifths of all the code at this point in the device is no longer first party code to the manufacturer. Of course, once you get to the asset owner, that is the the one that has purchased that specific device from the manufacturer. It's under five percent, maybe even under one sent in a lot of cases. It's almost entirely opaque. We don't know what that code is almost all of the time. So you can see as we move to the right in this chain, understanding what is in our software becomes harder and harder And we also have more and more organizations that fall into the right. So the problem sort of grows exponentially once you hit the device manufacturer in the asset owner in this particular view. So let's take a look at some of the common security program constraints and how we're gonna solve those with S bombs and with product security. Obviously, we everybody is familiar with vulnerability management and penetration testing at this point. This is how we sort of assess risk, at a high level. But they all have their draw. They both have their drawbacks. In terms of vulnerability management, we have a limited ability to determine where vulnerabilities exist in products and software especially when high profile vulnerabilities are released. Log four j is a great example of this. It took months for some organizations just to determine what products they were using were actually impacted by a log for chain vulnerability. On the pen testing side, of course, We do a lot of great pen testing work, in the security community in general, but very little of that is actually for reverse engineering of binaries or firmware or any sort of scaled automated software analysis. So that is a big blind spot We don't even if we don't even know what's in our software, how are we going to reverse engineer it? We also kinda look at some of the other things that we do from a from a procurement and vendor risk assessment perspective. Mostly questionnaires, paper based. They don't focus on validation of security vendor provided products for the most part. The bottom line is validation of security risk is very, very difficult, especially as you move toward the right in that chain, toward the asset owner side of the chain. Now how do we bridge the gap between what we're doing now and what we're doing with application security and a true product security life cycle? Well, I've mentioned it a couple of times. If we don't know what's in our software, how can we secure it? So we obviously need to figure out what's in our software. What is the best tool we have do that right now, an S bomb, a software bill of materials. So if we start requiring software bill of materials or S bombs from all of our suppliers, maybe we can bridge this gap a little bit. So why would you want this s bomb sort of generally Obviously, we've touched on that top point there what's in your devices. It brings visibility into the software that's actually there. It can also help figure out what sort of risk is tied to that software. So it helps eliminate some of the blind spots we have in terms of risk with those individual software components that are included in the device. And then, of course, you can also leverage your SBOM to try and have an accurate database of all the information so that you can apply that with emerging threats like log four j. Wouldn't it be great if you could just pick out a software component and say, search a database and say, where in my ecosystem does that component exist? Because I know that that component is impacted by log four j. An SBON can certainly help do that. It's not the end of the story yet, and we'll get there in a minute. So what does it actually look like? What's an s bond look like? For the most part, it looks like a list of software components that are in your particular product. Now there's all sorts of hierarchical views of that. You can break products down into artifacts and subsystems. But ultimately you end up with a big list of all the individual components. And on top of that, you get some other neat things that go along with it. And one of the things that you can get go along with just the list of software components is you can actually tie those two vulnerabilities as well. There's lots of different types of vulnerabilities, CVEs and CWEs, the weaknesses are are fairly common but you can tie those directly to the software components in your SPA and then from there, all you need to do is database that information to make it queryable, searchable. So if we're really looking at how the SBoms impact our overall security life cycle, it obviously provides us visibility But it can also help bolster some of our threat response as I mentioned. So you are able to scale, automate some of the testing, of your software if you know what's actually in it. You can identify some of those specific vulnerable, packages. The ones that have the most vulnerabilities or the most critical vulnerabilities are likely the ones that you need to remediate first. That also helps a lot when meeting compliance standards. You can also leverage an S bomb in terms of procurement and empower you if you're trying to procure third party devices. Or products, as something that you can basically take a look at and and determine what security your organization requires out of that product and out of the software that's integrated in that product. Last, of course, it also will help you test the actual software that's present in those products, instead of relying on questionnaires. But the S Farm alone is not quite enough. We still have to provide a lot more rich data around the supply chain visibility that we get from an s bomb. When we get an s bomb from a vendor, how do we know whether or not we can trust the vendor? How do we know whether or not the SBOM is accurate? Were configuration issues part of that vulnerability analysis or not? And then, of course, we still have to figure out how to take the information from an S bomb, and make sure that we can, database that, search that so that we can apply, you know, post deployment changes, like when a new vulnerability comes out. So AppSec and SBoms together still aren't enough to manage your overall supply chain risk. What is enough to manage your overall supply chain risk is holistic end to end software supply chain solutions that wrap all of those things together in sort of one view. So what does that look like? Well, as you might guess, just with the cyber security framework, It looks like an entire life cycle. It's not a point in time thing. It's something that we have to do continuously, and it's a continuous iteration. So I'm gonna run through each one of these things individually. So I'm gonna go through this slide really quickly, but the life cycle for product security and supply chain risk management in general sort of broken out into six steps. Discovery, assessment, prioritization, remediation, response and improvements. And let's jump into each one of those. So the discover step This is where your SBOM comes into play. This is where you're gaining control over your software supply chain by understanding what's all there. We need to understand what software is there, what those dependencies are, what the components look like. We can do that through binary analysis We can do that through source code analysis, some combination of those. But essentially, we need to understand everything that's there so that we can analyze the risk for all of our first party, third party, and open source software in our ecosystem. This is where the S bomb gives us a ton of visibility in this discovery phase, but only in this discovery phase. As soon as we move on to the assessment phase, suddenly, we have some things that might fall outside of the purview of an s pump. There is still some overlap. For example, the CVEs and CWEs, those things can be incorporated in the SBOM and brought into any sort of SBOM platform in a number of ways. But what about zero day vulnerabilities? Do you have any ability to detect the likelihood of a zero day in your compiled source code? This step right here is all about tying those individual components that you have in the s pump with specific vulnerabilities. And you have to be able to do that as fast as your dev ops teams work. Now as fast as you're pushing new things in your product, you have to be able to tie those vulnerabilities to all of the software components that are in those products. So that can be a pretty daunting task at that speed. But you have to be able to do it. Otherwise, you're gonna be out of sync. Your your assessments and vulnerabilities and risk is gonna be out of sync with what what's actually in the software and the SBOM. If you can't do it at that speed. So what do you do after you get those assessments. This is where the SBOM sort of, fades from the picture and we need to do more. We need to enhance the data and the visibility that's given to us in the SBOM. So we have software components. We have some vulnerabilities for those components. Now we really need to prioritize those in a way that makes sense for remediation later on. So how are we gonna do Well, the first and foremost down there in the bottom left of this triangle is sort of the obvious thing that I would say most organizations are currently looking at, and that is the vulnerability context. This is your straight up vulnerability severity. What is the CVS S score if you're looking at a Cve? Those things, are published along with the CVs and and you can take the into account the vulnerability context fairly easily with most vulnerabilities, not with all, but with most. You literally can just take a look at the score. Is it a critical Cve? Is it a high severity Cve? And so on and so forth. But that's only one third of the whole prioritization, story. We also need to prioritize based on the exploitability context and the threat context. So let me jump down to the bottom right hand side. The threat context essentially describes how likely a vulnerability is to be exploited. So that is basically what level of development is an exploit? Are we looking at a POC exploit? Are we looking at something that's already being exploited in the wild? If it's the latter, then your threat context goes way up in terms of how likely that vulnerability is to be exploited. We have to take that into account as well when we prioritize. Finally, this top one here is one that I think very few organizations are doing, and that is we have to understand the exploitability context as well. That is essentially figuring out whether or not a vulnerability can actually be exploited in the context of your environment inside of your network system, etcetera. Is that component even used the component that's vulnerable? Is it even used in your compiled code. It can be present, but not actually ever executed, which means the exploitability context goes way low since can't be your, you know, code that's unreachable in a compiled, binary obviously cannot be exploited. So we have to take all three of these things into account when we do our prioritization in terms of what we need to look at next and that is to remediate. Obviously, this is the most challenging step, I would say, for most product security teams, is given the wealth of data we've gathered from the S bomb and from the exploitability, the vulnerability context. Now what do we do about it? We need to create we need to be able to create action items for our teams to go and remediate our products so that they actually become more secure. Of course, there's a number of ways that we can do this. Most do it through a ticketing system them and through actionable reporting. But the bottom line is we need to have concrete guidance, a concrete ranking of all of our vulnerabilities and which ones we need focus remediation efforts on first. Now the fun part, if you have all of that data, And you're able to do those first four steps really successfully, then there's absolutely no reason, that you shouldn't be able to respond in the case of a changing threat landscape. So let's say we have a new vulnerability released now and you should your team should be able to respond and immediately identify where that vulnerability exists in your products. And then, of course, once you know where, you can go through the whole life cycle again all the way through to remediation. To make sure that you can fix those quickly and effectively. Going back, you can see in these little tables in the diagram log four j's is is another perfect example here. There are many examples, but considering a critical vulnerability, that is definitely exploitable. Maybe it's even exploitable already being exploited already in the wild, which where is that in your product portfolio, you should be able to answer that question extremely quickly if you've done everything right up until this point. Finally, the last step really just ties it all together. If you're doing all of those five things well, you should be learning a lot. And you should be able to improve over time. You start building dashboards, you start looking at long term trending metrics, and start getting to, compliance frameworks over time and you really put yourself in a position to show that over time the risk in your product portfolio is continuously decreasing. That's the ultimate goal of supply chain security in the first place. So I mentioned this a couple of times. Now that we kinda walked through all of the supply chain security life cycle. We are big advocates of testing throughout the in higher development life cycle. So when I say we wanna test at the right, that doesn't mean we wanna do that at the expense of test throughout the entire life cycle. But we want to include that in our testing so that we're not missing anything. The benefits of shifting right in terms of when we're testing and when we're looking at some of this supply chain analysis is that we get to test exactly what we're shipping. If we're testing, the, the full supply chain of what's in our software supply chain of what's in our products right before we ship it to customers, then we are testing exactly what our customers are receiving. If you're not doing that and you're only testing further left and you're doing your risk management based on decisions solely further left, then you're probably missing software that's introduced during the build process or even the testing process or potentially the integration process and you're certainly missing changes that are introduced by software and introduced after those testing rounds. Ultimately, the holistic software security program tests throughout the life cycle. So this is an addendum. Shifting right is not a replacement for testing where you're currently testing. It is an addition to testing where you're currently testing. Ultimately, product security and and managing your software supply chain risk, it has to be a life cycle. We've heard about some really important tools. The SBOM is kind of the one of the major points during this talk. And it is a very, very important tool to software supply chain security life cycle. But it is only a tool. You saw when we broke down this life cycle that it really plays predominantly in two of those six phases. So we still need to accomplish things in all of the other four. The SBOM is a great tool and it can help us bridge the gaps between application security and product security life cycle. But it's not the only thing that we need to be doing. We still need to be looking at those vulnerabilities, prioritizing them, remediating them, and then leveraging all of that data that we've accumulated along the way, so that our teams can quickly respond when things outside of our organization, change such as new vulnerabilities being released. You'll notice We've seen these two, diagrams a couple of times already in the talk, but you'll notice it is a striking similarity between the products security life cycle and the cyber security framework that's well publicized by NIST. And that's because they are similar in thinking. And that the product security is a subset of overall cybersecurity best practices. That's everything I had for you today. I hope you enjoyed the talk, and I hope you have a great rest of the day. Thank you.