Related Resources: 

• Software Supply Chain Risk Report 

• ReversingLabs Software Supply Chain Security Free Trial

Episode Transcript

PAUL ROBERTS:

I think we were going to do the questions near the end of the conversation, but ask them at any time. Obviously, as you heard, webinar is being recorded and will be posted on the ReversingLabs media pages afterwards. So if you want to come back and watch it, go right ahead. If you want to share it with your colleagues, go right ahead.

We will follow up this conversation with, yeah, links to the recording and any other relevant content, including a ebook, report, actually that Chris put together on software supply chain risk, that we'll share with you as well. And you can click the live transcript button on Zoom to view closed captions as we talk and go

Okay, kind of agenda. We're going to introduce us. We're going to just talk about the threats to software supply chains and to traditional development groups and practices and why the change in the threat landscape is really warrants a change in approach, a change in technique and a change in tooling for both software development organizations and downstream customers. And, we got two amazing folks here, which we're going to, we're going to introduce in a second. We'll go through kind of the way you need to change your thinking and end with some really strong kind of solid, actionable recommendations for things that you can do to just sort of level up your game, as the threats and risks to your organization change.

Okay. So first of all, who are we? Who is ReversingLabs? ReversingLabs is a company based in Cambridge,

And who are we in this group? We have an amazing lineup for you today. And thanks to everyone for joining. I'm going to start with our guest speaker, Chris Wilder, who's the research director at TAG Cyber. And, Chris, I'm going to let you tell the audience a little bit about yourself before we get going.

CHRIS WILDER: Well, thanks, Paul. And it's fantastic to be here. Thank you so much for

MATT ROSE: Only the cool kids club.

CHRIS WILDER: Exactly. Exactly. So no, this is exciting. I've been looking forward to this for a while, but, I'm Chris Wilder.

I'm Research Director and Senior Analyst at TAG Cyber. TAG is a research and advisory firm that typically we call ourselves the Young Gartner. Our mission is really, we work with about 100 and 130 to 150 enterprises, enterprise CISO security teams to really understand what the vendor community is doing, what kind of technology they should be looking at.

And we help them with understanding what technologies are coming down the pike for things like, , for exactly what we're talking about today, because the software supply chain has become one of the top issues that a lot of CISOs are grappling with today, partly because they're getting pulled kicking and screaming towards DevOps, but it's also something that it's become a very critical imperative within most enterprises on, how do you manage and

It's really becoming a challenge and an issue, not just from a vulnerability perspective, but a compliance and all the above things. So it's becoming a very strategic imperative. My background is 30 years in cybersecurity. I've launched eight different security companies. I spent a lot of time in the intelligence community and, working in, at Fort Meade, but was in the military prior to that. But, the last several companies I've done are all very focused around communications, IOT and, all the fun stuff that goes into that. I've been one of the bandwagon guys for startups. But, that's me. And, thanks again for your time.

PAUL ROBERTS: Great, Chris. Thanks so much. Mr. Rose, welcome and tell our audience a little bit about yourself.

MATT ROSE: Oh, thank you very much, Paul. Thanks for having me. So first of all, please don't call me Matthew. Call me Matt. Matthew is what my mother called me when I was in trouble. So I still have some bad childhood memories about that. If my middle

PAUL ROBERTS: I just called you Mr. Rose isn't, shouldn't everyone just call you Mr. Rose?

MATT ROSE: I say, Mr. Rose is my dad. So, thanks everybody for coming. Again, Matt Rose, I'm the Field CISO here at ReversingLabs, been in application security since 2005, when it was starting out with SAST becoming a thing and DAST becoming a thing. And after having multiple roles, multiple responsibilities, both on the business side and the technical side, I'm kind of, I don't know, the talking head. I have a big bald head and beard and people like to listen to me talk. So that's what I'm doing today.

My background is primarily in SAST. I've worked in the past for Fortify and CheckMarx from beginning through acquisition, but I really am passionate about bleeding edge technology and I really feel that the industry is kind of focusing on software supply chain security because it is a new lens of risk.

It's something that is pivoting away from, , regular AST tooling or application security

PAUL ROBERTS: Ah, thanks Matt. I'll finish up. I'm Paul Roberts. I'm the moderator today and I'm the Cyber Content Lead here at ReversingLabs, where I produce a wide range of interesting content: Blogs, webinars like this ,podcast, really leveraging ReversingLabs, amazing kind of technology and insights into what's going on in the threat landscape, both traditional malware threats as well as increasingly software supply chain threats.

Background for me, journalist, reporter, industry analyst, started covering the cybersecurity beat way back in

It's been a topic I've been really interested in going back more than a decade and keeps getting bigger. So I'm really happy to be here and with these two gentlemen and really excited about our presentation today. So without further ado let us move on to what we're here to talk about, which is, mounting threats to development pipelines and, supply chain risk.

So behind this conversation and behind the report that Chris put together is a survey that we did earlier this year of around 300 IT pros who were working for development organizations or in development organizations around, questions around software supply chain

And the findings of that story were really, really interesting. And again, Chris has written up a really interesting report on it around kind of understanding software supply chain risk. A couple of the really interesting data points that came out of that and got him here on this slide.

One is 87% of the again, 300 plus 320 plus IT pros that we surveyed said that they knew that software tampering can result in security breaches within their organization, but only 37% of those right felt confident that their organization could detect tampering across their entire software supply chain.

I think the gap between those two numbers is really hair raising, and, I wanted to just kind of throw it to, maybe Matt to start with. Let's dig into this sort of awareness, or confidence gap, I guess you could call it, and what is behind it.

First of all,

MATT ROSE: Yeah. I mean, my comments on this, it's kind of interesting to see this, that this is from the same survey, the same group of individuals that 80% of the respondents said that there is an issue with tampering.

Yeah. We know this is a problem. But only 37% are doing anything about it. You have 50% of gap. And why is that? I think it's people are still trying to figure out the best way to actually address software supply chain, because it doesn't matter what you read from different industry analysts, experts, so on and so forth.

They all have a different kind of approach. And I like to think about it this way is. I always like to draw a nice little, you can call it a birthday present, a Groundhog Day present, even a 4th of July present, depends on what holidays you specifically celebrate in your world. But each of these quadrants is something different, and a lot of people would just

And thinking about that, they're probably using one of the tools, but not all the tools appropriate for identifying software supply chain risk. Chris, do you, do you agree with that?

CHRIS WILDER: I do. And, and, well, number one, I think that getting 321 security professionals to actually respond to a survey is a Herculean feat.

But, but I do 100% agree with you. And I think part, a lot of it too, I mean, one of the big telling signs in here is just part of the piece of the research that came out, , 65% of these companies, that extra 37, they don't believe they have the tools to be able to deal with this.

And I think part of it, too, I think you're right, but I think part of it, too, is now we're kind of getting to the point where security has to be part of the software supply chain. And it's 1 of the things that used to be an afterthought, , once you go down the road and then they would have to go back and do the rebuilds and things like that.

I think now we're kind of finding some synergy. And

PAUL ROBERTS: And Chris, in your job, obviously you're talking to folks within organizations all the time. Do those numbers kind of add up or with what you're hearing as you're out there talking to practitioners or CXOs or folks within organizations around their feelings around this, , emerging supply chain risk?

CHRIS WILDER: A hundred percent. I think there's a I hate to use the word skills gap between security organizations and DevOps teams. It's communications gap, skills gap, whatever, whatever you want to call it. And so a lot of CISOs that we work with are really trying to figure out how to interact with these people.

I mean, arguably cyber security professionals are not the best communicators in the world. And I think the only people worse are our developers.

MATT ROSE: How dare you? I'm offended.

PAUL ROBERTS: I was gonna say, except for Matt Rose, who's actually a very skilled communicator.

CHRIS WILDER: But the other side of that too, which is really coming into this conversation, we'll talk about this as we go through this, but the big scary part now is the fact that so much of the software that these companies consume is developed outside of the organizations with third parties.

And so we're seeing a massive shift from, Oh my God, now my software supply chains become part of my third party risk management challenge. And so that's, it's really becoming more of a strategic exercise than anything else. So these jive with us very much so.

And and so I think it's a sadly, it's only going to get worse before it gets better.

Matt, I hope I answered your question, brother.

MATT ROSE: You absolutely did.

CHRIS WILDER: Okay.

MATT ROSE: Spot on.

CHRIS WILDER: So, I see you wiping off the board, so.

MATT ROSE: Got more real estate to draw more stuff, more things.

PAUL ROBERTS:

It's even higher when you look at software supply chain, 12% of the breaches that made up their report had links to software supply chain, software supply chain played a role in the breach. I thought that was pretty astounding. And the additional cost and dollar figures again, for those breaches related to software supply chain was 370, 000, for those organizations. So the stakes are high, right? Matt thoughts.

MATT ROSE: Oh, absolutely. And this wouldn't be a hot button

PAUL ROBERTS: Right, right.

CHRIS WILDER: Yeah.

PAUL ROBERTS: Yeah. Go ahead, Chris.

CHRIS WILDER: Yeah, I was the only thing I was going to add to that is if you start adding cloud breaches, cloud vulnerabilities, if you get breached in the cloud, cause that's a whole new thing that's coming as quickly as software supply chain that you could double the cost of the of a breach if it's a cloud breach, just because of the amount of data and the amount of information that you can filter out of that. I was a little bit surprised I think 12% seems to be kind of low right now. It's definitely definitely rising. But the 1 thing we didn't cover on this is the, which is the meantime to remediation.

And, obviously, identifying the vulnerabilities is 1 thing, but it's still taking 90 days to remediate these issues. And so that's also another

PAUL ROBERTS: Yeah. On this slide, I just threw up some recent supply chain related malicious campaigns, obviously top left corner that should probably be in the magic quadrant actually on this graphic, SunBurst, which is the attack on the SolarWinds Orion product. That's going back a couple of years.

More recently, ReversingLabs researchers have uncovered a number of similar software supply chain attacks, IconBurst, , which was one leveraging the npm platform, targeting users of the icon packages, a whole range of different malicious packages dressed up to look like UI elements that you might pull into your application. SentinelSneak in which they were posting malicious Python Package Index modules designed to look like APIs for a Sentinel One. And NPM Brain Leeches is the one in the lower right hand quadrant

MATT ROSE: Absolutely. And thinking about it this way, all of these attacks are different in nature. There's some consistency in terms of what's happening. But supply chain hacks or attacks are unique.

Like you're talking about compromising the build environment. You're talking about compromising an end user, open source package. So just having one technology to address software supply chain, whether that's

You have to have a complete and holistic picture to understand the risk. And if you're only looking in one area, you're only going to find risk in one area, be that the first party code, the third party code or even the build systems themselves. So really talking about an effective way to identify all these different flavors of supply chain attack, you have to go out and look at that entity as a complete entity and not just a piece of the entity.

All these great tools are out there. I mean, they're designed to do a certain thing. SAST to look at source code, DASTto look at a running application, SCA to look at open source packages. But again, they're just looking at one lens of risk instead of a complete and holistic software supply chain program.

CHRIS WILDER: Yeah, that's very consistent with the advice that we give to our enterprise clients is. Typically it goes going back to the survey 65% of them said that they don't believe they have the tools in house to be able to address these attacks.

Because a lot of times, most security folks, because we tend not to be very proactive in our worlds. We typically rely on very conventional methods to be able to expose threats and deal with vulnerabilities. But a lot of times, this world is moving so fast that you need to continually go back and look at what you have and then always say buy what you can build what you have to integrate for competitive advantage.

But it's really just coming to understand what you've got in the house and figuring out what you need to get to be able to have a holistic approach to dealing with software supply chain. And then obviously it's this whole SolarWinds thing took everything to a whole new level.

Recently CSO from SolarWinds just received is a Welles report which is basically where the SEC comes in and they're investigating the entire company and this could potentially ruin the guy's career. It was really nothing that they did.

[00:19:00] And, and so it was just because they didn't have visibility and they did not take a holistic approach and how they're doing it, and they gave the ability to push controls into even third parties and downstream. But yeah, Matt, I a hundred percent agree with you on this one.

PAUL ROBERTS: Yeah, and I think if you look at those attacks, right, there's so much variation in how those played out. The SolarWinds, we're talking a multi month sophisticated intrusion by nation-state actors where they're studying the actual coding patterns and naming conventions and just dressing up their malicious backdoor to look exactly like SolarWinds code, right? Very difficult to detect that without, if you're not looking for it.

And then you get down to brain leeches, and it's just it's a grubby little npm library. They're just kind of hoping you throw it into your application without realizing that it's actually going to connect you to command and control infrastructure. So it's like we're getting the full

As this problem progresses I guess the thing to talk about now is of course how we can address this problem, right? What specifically can be done to change up our practices so that we're less vulnerable to these types of campaigns?

And, the big the high level takeaway, obviously, is that traditional approaches, traditional tooling and technology are needed, but not sufficient, right? So can't ditch them. You don't want to get rid of SAST, DAST, SCA technologies are highly valuable, but they're not doing it.

I think one of the big things that we need to educate buyers about is just this notion of the things that you've been oriented on for so long around application security, particularly vulnerability management are not sufficient. Dealing with vulnerabilities in your application code is absolutely a priority, but it's not going to solve your supply chain risk problem.

MATT ROSE: Yeah, absolutely. So I think the first thing to talk about, and you mentioned it a few times is, I'll just use a shorthand. Vulns versus malware. And just trying to find this, because people sometimes mush these together. Vulnerability is something an application or piece of software is doing that is not designed. It's just a coding mistake. So the application has an intended functionality, a purpose that is acceptable. And then you talk about vulnerabilities in the application from a development side or a running side with the OWASP top 10 type issues like SQL injection or cross site scripting or data validation or data cleansing, all these types of things.

The application was never designed to be bad. Malware on the other hand is an application or a piece of software or code that its intended purpose is to be malicious. And that's

And then you may even have an open source repository or a binary repository. That's great if you're using all these technologies whether you're scanning source code in your IDE or looking at your code repo for potential updates or potential malicious information or compromise of the build environment.

From a standpoint of software supply chain risk, and this is, I always like to give people a homework assignment thinking about it. When somebody says software supply chain security, are they thinking about malware or are they thinking about vulnerabilities? And most of that white papers, documents, blogs out there are talking about finding issues in one piece of this equation, rather than the potential unknown of malware.

Because I always like to say, if you don't know what to look for, you won't find it.

CHRIS WILDER: Yeah, one of the things we talk a lot about in the threat intelligence world is just because you've been compromised doesn't mean you've been breached. But if you've been breached, you've definitely been compromised.

And it's a subtle distinction. But on the other side of that, I think you're spot on with that. Most people don't even know where to start. And they look at the vulnerabilities because the CVES get published all the time and they're pretty easy to follow if you're disciplined about it, but malware is harder to track because you don't know where it's coming from. And nation states are becoming more and more, their TTPs or their techniques and procedures are all they're changing and they're moving from nation states level attacks to, more smaller attacks on the software supply chain. Why do you rob a bank? Cause that's where the money is. And, a lot of times that's why software is such a, especially the open source software, is a huge target because people don't mean to put bad code out there, put credentials or secrets when they

MATT ROSE: Thinking about this, you have all this tooling to find risk at different levels. It's also the human element of that setting policies correctly, making sure that the integration is pulling from the right code repo. When you're talking about a scanner that's integrated into the CI orchestration layer. So it's not just about people doing bad things, a simple mistake or a leak secret can be a diSASTter for a software supply chain.

CHRIS WILDER: Sure. Yeah. It really is, and one of the big challenges right now, obviously, secrets and keys.

PAUL ROBERTS: So we put together just a little graphic here just to show existing approaches to these problems, right?

So just first of all, sketching out where the compromises are happening, ranging from, source code control to all the way through to deployment, right? This is the whole development and release cycle. And you're seeing current technology, SAST

But going back to that slide with the recent successful supply chain attacks, that doesn't even include incidents like 3CX, the voice over IP provider or JumpCloud, CircleCI, there's just a variety of threats and attacks right now that just isn't covered by this existing group of technologies and capabilities, right?

So you need additional help to solve this problem. Right? So this is a sort of traditional application security testing, not enough. I guess I would ask you, Chris, you're talking to folks all the time, who are in the trenches on this, how are they dealing with this problem now, given again you can only use the technology and capabilities are out there? So how are how organizations dealing with this?

CHRIS WILDER: Not well, yeah. No, by the way, I do. I really like those two

The challenge that a lot of the enterprises are having is they've dumped a bunch of money into SASTs and DAST solutions and they realize that it's not living up to the hype and I wouldn't say there's a lot of hype in it because these are not hypeable type technologies, but they're not living up to what they thought they were, especially as we start adding more endpoints and we start adding cloud and we start adding all these different environments.

So they're playing catch up right now. And so the other side of that too, is typically SAST and DAST doesn't live within the CISO's realm, EDR does. And so now you've got a skills gap between the two organizations that they're really trying to bridge right now.

And I think it's getting there. But as security practitioners, we have to lead this. We can't rely on DevOps to lead this charge because we need to be the ones that are

There's your third party risk management side of this. You've got vendors out there. You've got to understand what can you automate? What can't you automate? And right now we're in this, I wish I had a cool metaphor, but I don't, but we're really playing catch up and we're in this, chasm where we're really trying to figure out what's going on and I think that this chart actually does an amazing job of explaining that.

PAUL ROBERTS: Pointing out some of the gaps there, right? Software composition analysis great for finding vulnerable or out of date libraries, but not going to find something that's designed malicious. And that's typosquatting. EDR, AV, , again, always been the problem. Only knows what it knows, right? It can only spot stuff that's been spotted and identified before as malicious. So it isn't going to spot

This was an issue with SolarWinds, right? Like the Orion. First of all, the Orion binary was not a malicious binary. It was a signed application, but it was huge and, how do you deal with that, getting some of these large, 3CX desktop app is a more recent example, right? So yeah, all these kind of gaps in capabilities and detections and the end result is successful hacks, right?

CHRIS WILDER: Who would've thought thought Sentinel One would be the target of last year?

PAUL ROBERTS: So one of the things that we've been talking about here at ReversingLabs is this notion of shifting up. So we, in the application security space, there's been this conversation about shift left for a number of years, right. Which is really talking about, don't just have your security, bolted on, protect the endpoint, protect the network, you need to move back into with, especially with DevOps and you need to move back into the development process and actually make security much more part of the process of actually creating and distributing the applications

Matt, you've been talking a lot about shifting up, which I think is a great kind of twist on that. But one that bears a little bit of explanation. So if you could talk to us about this notion of shifting up and what you mean by it and what that really entails for companies.

MATT ROSE: Yeah, absolutely. So first of all, I'll think about it this way. The phrase that I think is getting a little dated or is very dated should go the way of the dodo is just shift everything left in security. Well, little secret, you're only going to find things on the left. If you shift everything to the left, what about the recent supply chain breaches that are not on the left in the developers environment because shifting left really means push it into the developers hands. That's great for certain types of vulnerabilities or certain types of security risk, but it's not comprehensive. Think about this process that I still have up on the door up on the board. What happens after all this happens, all this is brought together, you create that package again the birthday present or whatever on,

You have to get above the process and don't live just in the source code repository, or just in the developer's IDE, or just in the tooling associated with CI/CD. You have to get up and look at the entire thing, kind of a final exam approach to truly understand what the risk is, because again, you're only looking at part of it, or only looking on the left, you're only going to find issues in part of it, or on the left.

PAUL ROBERTS: Chris, do you run into this?

CHRIS WILDER: I do, and it's, I was gonna ask you a question about it, but at TAG, we actually have an on staff

PAUL ROBERTS: Hey, we need one of those.

MATT ROSE: I've used Spy versus Spy in my glass boards. I have.

PAUL ROBERTS: That's amazing. Very cool. I love, I grew up with Matt and Spy versus Spy, but anyway. Yeah.

CHRIS WILDER: One of the, one of the cartoons we did, they reminded me of this. Matt, it was like that. Our cartoon is called Charlie Seesaw. I look at that. So Charlie Seesaw is getting ready to go to RSA. And he's saying at the bottom of the elevator, he's looking up and going into the expo hall and big sign on the wall says vendors who shift left go this way vendors who shift right go this way. And unfortunately, as an industry, it's pretty true. We tend to latch on to the word de jure. But I think the question I was gonna ask you, Matt, is, because I've taken what we've talked about in the past about the shift up metaphor.

And, what are you getting? And I'll tell you what the CISOs are saying when I socialize it a little bit. But what are you hearing when you talk to people about that? Just because I think it's, I think it's a novel approach. I

We talked about having it as the Death Star, the Death Star final exam, but yeah, there we go.

PAUL ROBERTS: Well, as we know, the Death Star had a RCE and wasn't aware.

CHRIS WILDER: Yeah, I know. But yeah, what kind of reaction are you getting to this? Because...

MATT ROSE: I think people are actually thinking about it and going, that makes sense.

And the reason being is that all of the things that we're looking at, whether they're vulnerabilities or malware, you have to look at the entire picture and just living in a bubble, if you will, assuming that everything is working correctly, and understanding that, Hey, you want to work smarter, not busier.

And I think that's one of the biggest things where application security or even software supply chain security programs fail is you try and you do a lot of things over and over again, you're kind of stuck in the mud .What's the definition of insanity, doing the same thing over and over again and expecting a different result.

But if you actually shift that to the conversation about software supply chain security, you're basically need

And my analogy associated with shifting up is. Make sure you have a final exam just to double, triple, quadruple check the risks. Because if you're looking for just risk over here, say in the IDE or just here, there's a lot of things happening. Think about SolarWinds, it was a compromise of the build environment, the MS build.

That's right about here, not associated with this side of whatever DevOps tooling you have in place. Right?

PAUL ROBERTS: Yeah.

CHRIS WILDER: That's consistent with kind of what our CISOs are saying right now is that they're looking at the shift up metaphor as a way to actually get a much broader picture of what's going on.

Like you said, the final exam, because really they don't understand even what they're looking at. They can't tell the difference between an SBOM and code documentation. And so that's to them. It seemed like the concept seemed to work to

PAUL ROBERTS: I think that's actually a Forrester term, but I could be wrong.

CHRIS WILDER: I don't know. It's a different, it depends on, yeah, it depends on what it's affirmed as your but, so I think people get a different takeaway on it, but I think the concept, is sound. And when you mentioned the final exam and the Death Star analogy, it seems to, they're like, oh, okay, I can, manage what's happening on Tatooine

PAUL ROBERTS: I threw a link into the chat actually, as an example of the types of things that we're talking about, ReversingLabs didn't did an analysis of the 3CX desktop app, which was the app that was compromised in that supply chain

Matt, you put together a just a sort of rundown of in terms of shifting up what folks should be thinking of. So you had go beyond trust and validate the deployable

MATT ROSE: Let's think about it this way, let's use a brick and mortar type approach. Yeah. A lot of people are worried about their assembly line to build the car. They want to make sure that the robots don't mess up or aren't compromised, that they're actually welding the car together, putting in the engine, all that type of stuff, but at the end of the day, the vehicle is the culmination of all that work, just like a software program that is developing a piece of software for sale or an application for functionality.

It's great if you lock down the assembly line and the tooling, the build system, the code repos,

One of the biggest things I like to talk about is that this thing is constantly changing and there is opportunity for just mistakes or flat out misintended purposes associated with what you're building. So as you think about something going through the process, just looking at the tooling is not enough to actually verify the artifacts.

So think about that car analogy, you built the car, you're still going to test drive it to make sure it actually works and not be like, well, I know that these robots in this assembly line works great, but you got to make sure that the entity works as well.

Chris, do you agree with that or?

CHRIS WILDER: Yeah, I do. I think it's even more important as we start interconnecting more and more of these

And so you have to make sure that the integrity of that supply chain extends outside of your walls.

MATT ROSE: And just think about all the things that are in there from, first party code, third party code, open source tooling, all of it.

CHRIS WILDER: I think the shift up metaphor allows you, it's more of a story about visibility and understanding what you've got to visibility to, to reduce complexity.

And I think that's how we can at least get a little bit more educated, a little bit more in control of what's happening with, between the two organizations.

PAUL ROBERTS: Okay. So with the time we've got left, first of all, I want to just remind the audience, we are taking questions.

We've got a bunch of them that have already been posed. Use the QA feature, you've got two sought after experts on cyber supply chain, use them. They're happy to answer your question. So use that QA feature. Just with the time

So the first is recognize that software supply chain security is an enterprise wide responsibility. That sounds common sense enough, but, Matt, what does that really mean practically? Or Chris, actually. Chris or Matt, what does that really mean practically in the way that organizations right now have partitioned, again, DevOps, DevSecOps from their ordinary security practices?

MATT ROSE: Chris, you want to grab this one or you want me to?

CHRIS WILDER: Yeah, mine will be short and sweet. I recognize it's very different than reality and a lot of organizations do recognize, number one, yes, it is part of the enterprise wide responsibility but most organizations right now are still back at step one is cybersecurity is everybody's responsibility. And so the reality is not there yet.

PAUL ROBERTS: Number two, enhance security across all types of software. Again, common sense sounding, what do we really mean by that?

MATT ROSE: Sure. I think it's just understanding it. People are always trying to think about the next tool or what tool can find better vulnerabilities or be more effective at finding malware.

The tools that are out there, there is risk in all these different layers and lenses, the code, the running application, the open source, all of these things. So thinking about that, you have to basically enhance and have a lens of risk that maps to those specific areas. Cause again,

So you have to go across all of the different areas. And I think the industry as a whole is really mimicking this with, we moved from just SAST and DAST to now, and then IAST and now SCA, and now API scanning, now software supply chain scanning, that is the enhancement to find different lenses of risk at different points.

CHRIS WILDER: Don't forget cloud too.

PAUL ROBERTS: Okay, number three is a big one. Create a detailed SBOM, software bill of materials and use automation. So SBOM is something that's been talked up a lot, particularly these days, the Biden administration, a lot of the guidance that's coming out of CISA, NSA, as well as, NIST is emphasizing, and the Biden administration itself, emphasizing this software bill of materials. Interested in how organizations should be operationalizing that, obviously generating an SBOM for internally developed code,

MATT ROSE: My thoughts are automation is the key there. Just creating an SBOM at a snapshot in time is pretty effective, especially if you're aggressive in terms of your release cycles. So the SBOM has to keep up with the speed of DevOps. It has to be constantly updated. The second thing that I think is important is people just are using SBOM all over the place.

Like here's an Excel spreadsheet, that's my SBOM. Here's this list of stuff, that's my SBOM. It's standardization in a industry recognized SBOM format from Cyclone DX, the SPDX, the SWID, all these different formats based on some sort of consistent pattern. Chris, is CISOs asking about SBOMs just in general or wanting to be more specific in a format?

CHRIS WILDER: Normally, so typically from an SBOM perspective, mostly it's public companies that are asking about it. And the reason why it's specific to public companies is because of the executive order. Typically, what will happen is the SEC will take that executive order and implement

And they did the same thing with zero trust. So, yeah, we are getting a lot of questions about it. I agree with you, Matt, I think, dynamic SBOMs or something you need to have a lot of people poo-poo that but I think dynamic SBOMs or as software changes, especially as we keep building that's going to become something that's more and more relevant and important. The other side of that, too, that we're getting a lot of questions about is, and this actually got this question this week, was a lot of the code that people write can potentially infringe on somebody's patent.

And we're seeing a lot of things, a lot of companies right now, because if you're using open source, you're more than likely, you're probably stepping on somebody's patent at some point in time. And what's happening is a lot of companies right now, especially in mobile apps and those types of areas, they're actually going after companies that bought mobile app security software. If I had a mobile app security software company and I sold my product

That puts companies like Citibank and others at peril for lawsuits, for patent infringement. So an SBOM is going to help out a lot there. And I think it's also going to help a lot more with, as we start integrating more of the software supply chain and CI/CD into compliance and GRC.

Because now you're going to actually have to start showing people what you're building and what you've got and what are the bits and parts and the pieces that go into that and I think that's where it's going to be incredibly valuable and that's really where it's going to get. You're going to start getting a lot of enterprise traction, as opposed to just the, oh crap, we have something else I have to do.

PAUL ROBERTS: Absolutely. So number four was just to understand the importance of remediation for addressing software supply chain risk. I don't, there's probably not much to discuss about that. Basically,

particularly with regard to making SBOMs actionable and embrace automation, I wanted to sort of toss that last 1 to both of you on the automation front. As Chris, you were just talking about as well. There are some real challenges around dynamic SBOMs, and you've got applications that are changing maybe multiple times a day in terms of how they're actually constructed.

What are you hearing from? And as we know, there's a skill shortage and so on. What are you hearing from organizations about? how they want to try and manage the workload of, of addressing this software supply chain risk, and, , keeping on top of SBOMs and keeping on top of this kind of changing risk landscape.

CHRIS WILDER: Most enterprises right now are

So it's pretty remedial stuff. We keep pushing for the organizations to automate more and more and more. And I think they will, especially as they start adopting more kind of machine learning and AI technologies, like, I try not to mention, Joe Sullivan, not to mention Chat GPT. I can't help myself and every single webinar I do. But really right now they're at step one, which is automating policies and changes. And so it's really still very, very reactive, but, it'll get better, they'll start using it for speeding up remediation, speeding up alerts.

PAUL ROBERTS: Okay, can we turn to some of our audience questions? Anonymous attendee: "Given our current application security setup, which includes SAST, DAST, SCA and

MATT ROSE: Okay. Again, what are these things looking for? And I think AI is or just correlation of results from these different feeds is very important.

But if you're thinking about SAST, DAST, SCA APIs security scanning when you're talking about software supply chain, remember there, those technologies are not designed to look for malware. Malware is a major part of the supply software, supply chain risk landscape. And using AI to kind of correlate that information with a feed of malware would round out your program.

PAUL ROBERTS: So really using it as a way to more tightly integrate that kind of threat intelligence feed

Another question you mentioned, shift up, Google is also talking about not shifting left, but they are talking about shifting down. What is the difference between the two and how do you make a difference when adapting, adopting the process within your organization?

MATT ROSE: Chris, you got this. You can shift down.

CHRIS WILDER: I don't even know an answer to that.

PAUL ROBERTS: Also known as downshifting.

CHRIS WILDER: Downshifting. Yeah. I hope you have a clutch. To be honest, I've never heard the, it almost sounds pejorative that I've never heard shift down. I think it's, but I don't question what Google does anymore. But I think the question is from the shift up perspective, I may have completely forgotten the question because I was completely flummoxed by Google shifting down. But I think though that from an enterprise perspective, the whole metaphor shifting up is

But like I said, we're still in this chasm. And once we start getting out of it, it'll change. And I think all the shift up, stay left, shift right all that'll sort itself out.

MATT ROSE: Just make it easy. Shift everywhere.

CHRIS WILDER: Shift everywhere.

PAUL ROBERTS: There's a question looking for the difference in, in modern tool, when we're referring to modern tooling capabilities regarding, they specifically mentioned CheckMarx and BlackDuck who are 2 existing providers out there, what additional capabilities are needed beyond what those offer? Either of you guys want to kind of weigh in on that?

MATT ROSE: Sure I can be quick 'cause I know we're up against time. Again, you're looking for vulnerabilities with those things. CheckMarx is an open source or the uncompiled code. BlackDuck is with the binaries or the open source packages.

But again, those are not designed to look for malware or the potential insertion of

CHRIS WILDER: Yeah. And just real quick on that, we didn't talk a lot about this today, threat intelligence, but we did talk about you have to know what you're looking for, and vulnerabilities are a lot easier to go find in the open, as opposed to malware and malware's much more difficult to get. And like Matt said earlier, if you don't know what you're looking for then you may as well not do it. And I think every organization needs to really kinda revisit and invest in some level of threat intelligence so they can actually at least have a starting point on where to look.

PAUL ROBERTS: We're at the end of our time. I wanted to just take a second and thank Chris

So thank you both so much for that. And also wanted to just remind folks here's kind of summary of some of the points we made that we will be following up this with an email that. We'll link both to the recorded session as well as some additional resources including the software supply chain security risk report that you can download and read and want to thank everybody for their great questions and engagement and look forward to doing this with all of you again.

There will be more of these coming up in the future. So thanks very much.

MATT ROSE: Thank you everyone.

CHRIS WILDER: Great. Thanks everyone.

PAUL ROBERTS: Thanks.

CHRIS WILDER: Travel safe, Matt.