Keeping the Pace: Building a Resilient Software Supply Chain Together

Thomas Pace: Ben, What are you hearing from clients? When they realize how much of their software, they've never actually inspected after they. After they buy it. Generally speaking, it's a holy crap moment, right? Because they certainly don't understand the risks associated. A lot of times they don't know where to begin because the problem is so vast.

Ben Denkers: Really, I would say most of our customers think they are doing something. However, once they understand the scope of the problem, right, they realize that they're not doing enough. Then it becomes a question of how do they do more with the resources that they have? What are the tools they're using today, like the genre of tools that they're using that they think are doing something that is not enough.

Thomas Pace: Like, do you have a sense of that?

Ben Denkers: Yeah. I mean, I think they. . I mean, I think the genre of tools is different, specific to industry to a certain degree. Right. You have kind of the more traditional means, as it relates to how you're managing SBOMS or how you're doing, certain. Tasks within code itself. Right? Dynamic analysis, things of that nature. Right. Maybe even static analysis. But it's a fairly a manual process today. And generally it's point solutions, right, that are taking some, some form of executable or code and doing some analysis and looking for issues within it. The problem is, is it's not scalable, right. On the challenges, it's really only looking at a few pieces of the overall risk as it relates to, you know, the device, the application, whatever it may be in scope.

Thomas Pace: And so that would be for the first party code, piece for the third party code. Are you seeing kind of the same thing we're seeing where, people are maybe putting an overreliance and too much confidence in things like vulnerability scanners and EDR and things like that that aren't traditionally built for this software supply chain problem.

Ben Denkers: Yeah. I mean, if you're talking about more downstream. Absolutely. Like most organizations don't even have visibility, right? I mean, that's right. I mean, at best they are it's a it's a trust exercise as it relates to some sort of, you know, hey, we do this right in a document trail that is highly ineffective and doesn't mean anything. To be quite clear.

Thomas Pace: The illusion of third party risk programs, as we like to call it.

Ben Denkers: Do you have an information security policy? Are you doing these types of tests right? All of which, you know, it's probably not truly happening, and it's definitely not happening to the degree, even on the customers downstream. Downstream. Right.

Thomas Pace: The self attestation pinky promise that we like as we like to call it.

Ben Denkers: For sure. So, how do you first identify this gap? Why can you exist? Why can existing tools solve for it?

Thomas Pace: I first identified this gap at the Department of Energy when I was there, and I was being asked to help determine what assets and devices were impacted by a certain vulnerability, which meant I needed to figure out what that component was that had that vulnerability. And I immediately realized that we just didn't have a way to figure that out for compiled code assets like things that were already deployed and already out there running. And then you can't mess with the availability of ICS devices in particular. And so then we had to start reverse engineering firmware and things like that to try and figure out where these components and what components are in this thing. And so, that was just a huge gap, because we just couldn't answer those questions in any meaningful way. And then when I was at Cylance, when I was, working with you and for you for a good while, doing a lot of the work we were doing on the IoT firmware, an embedded team, you know, we were working with big automotive manufacturers and ICS manufacturers and medical device folks, and all of those people and those very large organizations had a desire to know this stuff. And all we could do was a handful of devices per analyst per year. And so the scalability piece was not there. The automation piece was, inconsistent. And so to me that there was that kind of confluence of experiences that helped me identify this gap and have the insane decision to try and go and fill it all on my own.

Ben Denkers: And what was the reaction from the customers when they, when you brought this problem to them?

Thomas Pace: Yep. Most of them have a, a visceral reaction is probably the best way to say it. You know, they are, it's a lot of information. You're giving them a lot of net new risk data that they feel like they have to action and make a decision about every little thing. And it's really our job to talk them off the ledge in a lot of ways and be like, listen, everyone has this problem. This is not a new problem. This is an industry problem. But without this visibility and acceptance, it's never going to get solved, addressed. But it's like everything, right? You're always going to have this, crossing the chasm dilemma where you're going to have the early adopters who are just all in and want want to be on the on the innovative edge, and then you're gonna have people who, no matter how much value you can generate, are going to adopt something later in the stage. But, you know, as time has gone on, even over the last 4 or 5 years, acceptance of this data has become, you know, significantly greater, which, you know, thankfully, is the case, especially with what's going on now with the trivia incident and the light limb incident recently. People are realizing, okay, I have to have visibility into these things because the attackers are going upstream. The attackers are really shifting left, and there's this, illusion that if the attackers are shifting left, well, then so should we. Partially. But if the attackers are shifting left, that's more of a reason you need to shift, right? Because if that stuff has been pushed into production all over the place, you can shift as left as you want to go. The horses out of the barn. You need to go figure out where those components are in the final built products that are now downstream, and you can't do that from source code analysis tools. So, Ben, where do you see organizations getting stuck after they generate their first SBOM?

Ben Denkers: What do they do with it? How do they contextualize it? What's the point? Okay, great. I have this SBOM now. And, you know, does this solve my problem? Does this reduce my risk? How does it reduce my risk? What are the other things that I need to be thinking about? Generally some version of that. Right. It's like, okay, great. We did this because we had to. Now what. Right. And so helping them understand, you know, from especially from a, you know, product security perspective. Right. What they need to do, you know, that is almost always the next question. Okay, great. We've got this that way.

Thomas Pace: Yeah. Yeah. I mean, I, you know, I have an entire presentation that's called I have an SBOM. Now what? Literally. And it talks about that exact dynamic because it's taking a while to kind of figure this out, I guess, actually, which might be kind of a silly observation, but, you know, building the technology that's capable of reverse engineering these things and generating SBOMs and enriching them and all of that is a very it's a non-trivial problem, for sure. But what we've kind of realized is the real challenge is what you do with this data. Once you have it, how do you operationalize it? What integrations do you need? What value prop can you create that's net new for all these different use cases like third-party risk and incident response and threat hunting. So it's a it's probably the most important question in this space. And it's one that, I think is being answered in a much better way than it was in the past. So. . .

Ben Denkers: Yeah, I mean, in a lot of times we're seeing like organizations that have binaries and they have applications that they're developing and having to create from, you know, having to review the source code, things of that nature. What's the difference from your perspective when building or generating an SBOM from a binary versus source code? And like, how does that fit into the overall ecosystem?

Thomas Pace: I think there's a place for both. In fact, I know that there's a place for both. You know, we're never someone that's going to advocate for you should not do source code analysis or generate us from some source code. That's, it's kind of a silly opinion to have. But the advantages of doing it from compiled code is, I mean, just number one, it's the actual thing. The actual thing at the end of the day. It is the product you have. It is the thing you are installing. You're not installing source code, you're installing this application, this firmware image, this container, this whatever. And so, any issues you identify from the compiled code analysis, you have a level of certainty you're actually there. Not to mention, your vendors aren't giving you all the results of the issues they find from a source code perspective. Right? That's just like, that's just not the way that works. And so, the other things you get are essentially other artifacts that are just don't exist in source code. So things like public keys, private keys, certificates, credentials, misconfigurations, all of this, other these other things that end up getting, added in and built in through the development process. And this is even more true when you're talking about things that are basically operating systems, like firmware images and, containers and things like that. Without that operating system context, you're just missing a significant amount of other artifacts and analysis that you can't get from source code alone.

Ben Denkers: I mean, I think ultimately helps you understand, like if you don't see those things, you're not going to be able to understand your risk profile.

Thomas Pace: That's right. It's an incomplete picture of the overall risk of a given thing at the end of the day. And so like I said, we're not saying that you should stop doing application security or any of that. That's that's not that's not rational. But it is just a it's a different net, new set of data that allows you to answer a different set of questions than you could previously ask. So Ben, how does the NetRise platform change the way, you know, you envision your team, your analysts, you know, your consultants, you know, approaching an engagement, you know, with some of your customers.

Ben Denkers: I think simplicity and scale, for the, you know, for the for the first part. Right. And then adding additional visibility to that risk picture that we were talking about. Right. I mean, I think, again, you know, the security programs are always built around things that are like puzzle pieces, right? And and SBOM is one puzzle piece, right.? And so to be able to expand that out in that process, out in order to be able to have the visibility into all of the things, either, you know, to the left or right becomes important. Right. And I think, from a solution perspective, what you guys provide allows that visibility and that scale.

Thomas Pace: You know, Ben, you're you're on the commercial side, obviously, but Booz Allen Hamilton is a massive federal prime contractor. What do you think the lessons from the federal space are that can translate directly into that commercial enterprises?

Ben Denkers: Oh, I mean, I think they are certainly concerned about, understanding as much risk across the entire board. Right? The, you know, the entire playing field, so to speak. And I think, you know, being able to understand and and manage SBOMs and really, truly dig into them to identify what the risks are become very critical because, again, you may be building a solution or a software platform to do something, and you need to understand what the risks are associated with that and manage it at scale. You know, from a federal perspective, you're talking about hundreds of thousands of systems, at any given moment that have some potential firmware or, are running an application that could potentially, you know, have a hidden issue or vulnerability, right? And being able to identify that and know where your weaknesses are allows you to essentially build a much more resilient, or allows you to build, you know, a resilient plan to address that. Right?

Thomas Pace: Yeah. What's interesting is the federal space actually was more the leader, but, typically the federal government's not the most innovative and rapidly, adopting, group of organizations as it comes to cybersecurity. But in this case, they're the ones who really set the tone going all the way back to May of 2021 with Executive Order 14028. And even recently with the OMB memo that came out around how the government should view software assurance writ large. And so it's nice to see that happen and that the commercial sector is kicking that, like taking that baton and continuing to run with it, because I still think that the commercial sector is going to be where a lot of the solutioning happens, like the acknowledgment of the problem is probably the most important thing. And the federal government gave us that. But I still think the solutioning is going to happen in the commercial sector and then make its way back into the federal space, just because it's a lot easier to build on commercial solutions.

Ben Denkers: I think you're seeing that. I think you're seeing that today, right, with the adoption of the you know, how quickly the federal government is adopting commercial solutions. To your exact point, because it certainly will make their lives a much easier if there's commerciality and and there's, you know, we have the problem solved, so to speak. And I think that's a great thing. Yep.

Thomas Pace: Yeah. I think commercial organizations are, you know, some commercial organizations have the exact same essentially risk profile as the federal government. You know, if you look at fortune 100 companies, they most of them are essentially critical infrastructure at the end of the day. Sure. And even you look at telcos and large financial services and, power and utilities and large scale device manufacturers like the federal government relies on those organizations to do basic things. And so, certainly there is a different risk tolerance in commercial versus the federal space. But at the end of the day, I think the issue is generally the same. One of the big differences, I think, is that the federal government is a bit more allergic to, like foreign influence and foreign components and things like that, where the commercial sector is just like has to deal with that. Just due to the nature of being a business and not a governmental entity. So I think that would be one of the big things.

Ben Denkers: I mean, you certainly have, you know, different risk profiles, different risk appetites depending for even within the commercial, sector itself, right, within the verticals. I mean, you look at the impacts of, of the financial systems organizations are much different than in health care. Right. And the things that they care about are different. I think it's it's a, you know, that's a perfect example of the federal government is concerned with national security and, and everything that entails, whereas other organizations have their own priorities. The point is, is that having a solution and understanding the the risk landscape, this, you know, from a product perspective, being one of them is very important. Regardless. Then it helps you drive and adjust what where your program goes and adjust maturity where it needs to be adjusted. I mean, I think most organizations in general, from a commercial perspective, supply chain, supply chain management, risk management means something completely different either way. Right? You're not even talking about SBOMs.

Thomas Pace: You're talking about, like, logistics?

Ben Denkers: Contracts, right. Like, logistics stuff. Right? Whatever the case may be, you know, you're talking assetations. It was like we talked about it at the beginning. I mean, that's how they view the world in a lot of cases. You know, it's even if you go down to the manufacturing layer, right, in terms of those are building things, they don't even necessarily care. Right. Because what ends up happening is, is if they're creating devices generally or using firmware or whatever, you know, whatever the case may be, that's usually being supplied to them by a vendor. Right? And that vendor, it becomes that vendor's problem. And, you know, there's the conversation about did you find this issue? Okay, great. Then why would we pay for this? You're paying for it. Yeah. So it's like this kick the can upstream. You know, that we're finding just in general.

Thomas Pace: Yeah. I mean, so one of the big issues is with CISOs or even big government agencies or whatever, they there's this discussion essentially around who owns the risk and who owns the liability. Once again, there's been this illusion that the people buying the software or the devices or whatever, can push the risk back on the people building those things. That's not the way risk works. So they can try they can try. You know, the analogy I've used all the time is, you know, if you buy eggs that have salmonella poisoning and you eat them, the person who sold them to you doesn't get salmonella poisoning. You do. And so the same thing exists for software risk. If if there's a issue in a piece of software you buy, the vendor who built it doesn't get infected or whatever you do, you have to deal with that. Yep. And so that finally seems to be occurring to people. As odd as that sounds, because because it's just objectively true. And then even the liability thing, like most, most vendors are signing away liability in a number of ways, like with their Eulas, where, you know, there's been plenty of very big issues in this world, and I'm unaware of anybody being particularly punished for that. But, you know, to me, it's that people are finally recognizing if we don't have visibility into these supply chains, then we're just going to keep getting negatively impacted.

Ben Denkers: Yeah. I mean, how do you how do you how do you account for that risk at a corporate level, right within the commercial?

Thomas Pace: By getting NetRise and Booz Allen together.

Ben Denkers: Yeah, that's a that's a fantastic answer. But the point there again is it's like you can't just accept it, right? Yeah. Yeah. You can't push it down. You've got to do something about it.

Thomas Pace: I think what's changed is previously the options that people had was basically, to acknowledge the problem existed and then basically just choose to accept it because there was no way to do anything about it for the most part. Well, now that's changed. So now you know the problem that big enterprises have is it's become a choice. And once it's become a choice and once your peers are doing it, and once, real value is being generated. You have a much harder problem, a much harder decision to make as a, as a CISO or a leader in the government, because other people are showing that it's possible. And that's kind of the that's kind of the rough phase we are in this in this market, in my opinion.

Ben Denkers: I mean, when we're having our conversation with CISOs or executives in general, and identifying you know, gaps within their security program, product, program, whatever it might be, oftentimes. Right. They may not even realize that this this is a problem, or it is a problem. And, you know, they have chosen not to do anything about it. But I think the point is, is, as we go into organizations, fortune 500 and up, right. Our goal is to help them better understand the risk profile, so they can make better decisions and whether or not they want to accept it or not. It's something they need to deal with. And it's something that should be identified as part of, you know, any risk plan, right, that you would then, effectively be able to build a more maturity program offer Right? A more mature program

Thomas Pace: You know, we were talking earlier about how people. . . One of the big challenges is how do you operationalize this kind of data, especially in enterprise environments, for third party things? I think that the core use case here is building a software inventory from the ground up, not just a list of applications and things in your environment, but, you know, essentially a list of all the ingredients, all the components and libraries and open source things that make up all of these things in your environment. Once you have that, like possessing that by itself is is not inherently the most valuable thing in the world. That's just an inventory. It's like, what are you going to do with that inventory now? So to me, what happens, what makes this really valuable is all the use cases that are downstream of a software inventory. So now you're enabling third party risk teams to have data driven and evidence based approaches to evaluate software, in a risk based methodology. You can enable your incident response teams to answer questions like, do I have Log4J? If so, where do I have this, compromised trivy component? Where do I have light LLM in my environment, things like that that you just couldn't answer in the past? You provide significantly more gasoline on top of your vulnerability management program, because we're going to find a lot more vulnerabilities and a lot more things that you can prioritize and triage and mitigate or remediate depending on, where they are and how, how helpful the vendor's going to be. Then you have GRC. So how compliant are we now based on this kind of data? How to how do we react from a compliance perspective now that we have a net new set of data that gives us additional visibility into different compliance frameworks and, and standards and things like that. So I think, you know, depending on who you are and where you want to start, I think most organizations are starting with the third-party risk use case, because essentially that gets you access and visibility to this data on the front end and then everything downstream of that, like vulnerability management, incident response, threat hunting is possible because you're getting things as they come in the door. And you can still go after the legacy stuff that's already deployed. Also, people do that too. But I think the third party risk place is probably the best place to start from a operationalization of this data. Moving forward, but I'd love to hear what you think then.

Ben Denkers: Yeah. I mean, look, I think you have to know the game you're playing, right? And so the better visibility that you have of the game board and the potential threats and exposures that your organization is, vulnerable to, right, or potentially vulnerable to, the better choices and outcomes you face. So understanding that even at the tier, to your point, understanding the list of the applications. Right. And and how those all the inner workings, work from, you know, a libraries perspective or whatever, those are all potential vectors, and they're all potential things that, you know, could directly affect a negative outcome towards an organization. And so if you don't even have visibility into that, you certainly need to. And I think that's a great first place to start and then expand from that. You know, ultimately, the better you know your environment, the easier it becomes to then, build the resiliency around your organization. And what's most important. Yeah, that's where we tend to offer to our customers. Right. Is that that ability to help them see through, all of the complications of application security, right? You have enterprise risk security, you have network security, have all these different things, and they all fundamentally rely on that same principle. Understand the battleground, understand the game point

Thomas Pace: NetRise and Booz Allen, organizational resiliency as a

Gary Schwartz: That was awesome. Thank you. I've got a couple questions are coming from the audience. The first question is, I run a third-party risk program, and most of my team is not technical. How do we work with you, either of you, in order to operationalize that program for us.?

Thomas Pace: Now, I'll start off, though I think Ben's element of this is probably the more important one. You know, we provide, very clear playbooks and workflows. And implementation to integrate these things into the existing technologies to operationalize the data, from our, from our platform. We even give, we've even developed, you know, some additional third party risk program policies and procedures that can be used to augment the existing, set of third-party risk programs and policies that you have. But I think the the missing piece, you know, we're not we're not a services company. Is that, having the expertise that can come in and fully operationalize this and, conduct the analysis and take it to the perfect outcome if the organization doesn't have that level of people, is where I think Ben and his team come in.

Ben Denkers: Yeah, I mean, absolutely. I mean, certainly we can help understand or at first evaluate where where the knowledge base is. Right. We can help in a couple of ways. Either get that knowledge base up, up to speed. Or again from an up operate, you know, optimization perspective, help develop tools, techniques, right, to get them where they need to be effective. Right? I think also, you know, you talked about, you know, Tom, you talked about the, you know, kind of, workflow piece, right? Those are things that we can help automate. Those are things that we can help, you know, built agenda capabilities around, those are things that we can help prioritize and, and, you know, make sure that the organization is focusing on, what it needs most in order to accomplish the outcome that it's looking for.

Gary Schwartz: Awesome. Thanks. Next question that's come in is, how do I get access to the binary? And just to upload it to your system?

Thomas Pace: Yes, this this is a it's a really important question. There's a number of ways that we can get things uploaded into our platform. Number one, we build we have a number of scrapers that just go out on the internet and find these things where they're available and help curate and build, our data set on a recurring real time basis. The, you know, other ways as we build integrations with things like patch management solutions or application inventories that exist, pulling things in from systems of record like ServiceNow. We have technology partners who go out and, you know, aggregate all of this information and we can pull from them, into our platform. And then even just changing and updating, as I kind of mentioned earlier, how software gets into the environment over time. So if if you're buying a piece of software before it gets installed, it gets uploaded into NetRise that that is essentially a net new way to get data in. So there's a there's a number of ways, we go about doing this. And then once we're working with customers themselves, they can get access to the things that they're buying and then upload that to us as well, where we might not have that level of access.

Gary Schwartz: That's awesome. Thanks Tom. So the first question that I see over here is, how do I use that information for leverage with like what what what do you have in your to me experience and helping us solve that?

Thomas Pace: So the way that we find our, our customers are leveraging this information with their, their vendors and OEMs is around a number of different approaches. Number one, creating a baseline to understand, what's the risk associated with a vendor in general. And then over time, comparing that to the other OEMs that they're working with and, and trending that to say, is this vendor getting more risky or less risky? And most vendors are incredibly receptive, once they have this kind of data because essentially what they're getting is a, a free assessment and a free security assessment from their customer. And so what tends to happen is the customer has some set of priorities of things that they want to see resolved or mitigated or remediated. And then they send that to the OEM either directly or we do that, oftentimes for our customers. And this is an area where, Ben's team also, supports these efforts, where they're essentially acting as the interface to the OEMs, because it can be a lot to manage, potentially, depending on how big the organization is and what kind of issues, that they are identifying. But those are some of the ways that we, we interface with the OEMs and, and help essentially, you know, this problem is going to get solved from the software buyer's perspective, because if a buyer provides feedback to a an OEM, that OEM is not going to only fix it for that buyer, they're going to fix it for all the buyers. And so essentially you have a, you know, rising tide lifts all boats, scenario here. And that's really the big win for software supply chain security over time.