Dangers of Unused Software – Mehran Farimani, RapidFort

This is Textron tv. Hey guys, thanks for the throw. We're here with Mayron Far, who's c e o for Rapid Fort, and we're gonna be talking about software bloat and the impact that that has on security.

'cause it turns out we have a lot of software out there that's unused and maybe some of it just is, has too much code to begin with. Meron, how you doing? Welcome to the show.

I'm doing well. Thanks so much, Michael. Thanks for having me.

How pervasive is this problem? I know there's a lot of software that sits on the proverbial shelf, but how much code is out there that's kind of expanding our attack service that we already can't handle? It's quite a lot.

Um, you know, it varies depending on, um, the, the type of, uh, programming language that's been used to build the application, how it's packaged together and so on and so forth. It's clearly possible to build really, really clean, um, uh, workloads, uh, with no extra software. You pick, um, a statically compiled language like go or see or something alike and, you know, make containers that are based on scratch or, you know, vis lesson and you have minimal software.

But as soon as you get into the world of, um, uh, you know, other frameworks, Python, ruby, um, no jss, Java, and so on and so forth, then you in the, uh, in the world of package managers and, uh, then how you take that application, package it into a container, you add an OSS layer on top of it and you end up with, uh, quite a lot of software that, um, is actually not used by the application. It's not necessary for the application to operate. It's, uh, uh, it's, it's a result of how we build and how we package these containers and these workloads.

Um, and also visual machine workloads, um, similarly, um, and it comes from, you know, the numbers vary. Uh, it could be anywhere between 50% to 90% sometime, sometimes even more. Um, we did a large study of, uh, about 1800 enterprise types of, uh, container images, and on average we found about 73% of the software that's bundled in these, uh, containers was actually not needed by the applications.

So those are the numbers that we've seen. So do we need to go back in and either eliminate or rewrite a lot of code to go address this issue and do it in a modern language? Or how do I kinda, uh, address this issue?

These, these are, these are, to be clear, are modern languages. Um, um, they, some of it, some of it comes from just the way that we pull in packages, uh, especially open source. But we build our application with a lot of really useful, great high quality open source packages.

And typically these packages, uh, do a number of things, but the application uses only a subset of those functionalities. And those packages themselves have transitive dependencies where they pull in other packages to do all the a hundred things that they're supposed to do for, but for a given application, there's only a, a, a, a small subset of that functionality that a package provides that's used. And so, um, you know, when we pull in a particular package, we end up pulling the whole bowl of spaghetti in.

And, um, it's often very difficult to go back at a package manager level and, you know, slice and dice that and take it out and, and, uh, uh, you know, not have it included. Sometimes it's possible. Um, the other source of it is, um, you know, when we build container images, we often pick some sort of a base OSS image, whether it's Debian or, uh, red Hat or whatever it is, and those come with their own set of OS packages that are not often, um, completely necessary for the application to run.

Um, you know, the, the workloads could have bash scripts and other kinds of things that you use OSS packages, but, um, only a subset of those OS packages get actually used by the application. So to be able to identify those things, there are various techniques to do that. Um, obviously, like I said, you could use static compile language, you know, leave the job to the compiler to pull in all the necessary code to build the application.

Um, and you could build container workloads that use, um, a, a minimal OS package or no OSS package. But, um, basically, um, but, um, the majority of the workloads that are out there are not built that way. It requires a certain type of, um, discipline and hygiene, certain types of programmers.

Um, and not everything lends itself to a go or a C or a c plus plus sort of a, a development environment. It's a lot quicker to do many things in Python or Node or Ruby or, um, you know, even bash scripts. Uh, you can build microservices on.

Uh, and so if you wanna and maintain your development velocity and, you know, build your, uh, features and you respond to your business needs as quickly as possible, you do want to have a, um, set of tools that automates this process, um, of understanding what those packages are and, and communicate that information either back into the development or automatically get rid of them or lock 'em out, um, somewhere in your pipeline somewhere as part of your deployment. We see a lot more focus these days on securing the software supply chain. So are people aware that this is even possible at the moment because it seems like they're overwhelmed by something that feels like a task that is enormous, but maybe there's a way to get after some of this in a way that reduces the stress?

Yeah, uh, you know, it's, uh, it is definitely, um, interesting to, to talk about it in the, the realm of software supply chain. But, uh, if you think about a software supply chain, the, the, the main way of addressing that is really by signing code and, you know, verifying those signatures and then protecting your bill system. It's not so much about our new software packages and so on and so forth, but it's, you know, did any one medal around with my, with these packages or with the way that I build my software.

And that's kind of a separate problem from, you know, removing blo. Um, of course it's, it helps with that because in the sense, you know, our new software in general presents two problems. Um, one is that it, uh, makes it really hard for you to sort of, um, uh, read a signal from the noise to understand what are your real security issues?

What are your real bugs that are affecting your application? Um, and that's, that's one problem. And the other problem with it is that, that a new software by itself presents a security problem, particularly because there's so much of it.

Obviously it has less risk than software that's being actively executed by your application, but having software that's just sitting around in your infrastructure is still a liability. And if when there's so much of it, then it adds up to significant risk. Um, prac, practically speaking, that is, uh, you know, if you think of, think about, um, it's called live off the land type of attacks where somebody gets into, once they reach your network and they get into your workload, then what's available to them is the entire software that's, that's sort of, um, in that workload and, um, and live off the land attacks, you try to stay as quiet, quiet as possible so you don't get detected by your other tools and and so on.

So you try to use whatever software that's that's been left around to get deeper into your infrastructure and ultimately to your sensitive data. And by limiting that, um, uh, that, that, that, uh, those, by removing those components or locking 'em out, then you limit the cap capability of an attacker to actually move laterally in your, in your infrastructure. And so that's why it's important to, from a security perspective, to get rid of it.

Um, and then in general, if you think about it, um, a new software is, is like dead wood, you know, it's just, you know, you're carrying it, you maintain it on a day-to-day basis, but it's not adding any business value to you. It's not, it's not running your application, it's not fixing anything. It's not, you know, delivering a feature.

It's just on used software, but you maintain it on a, on a regular basis. And that's, that's just, uh, something that seems to be, um, uh, uh, logical to get rid of. So I get the idea that we wanna reduce the amount of bloated, unused software that we're deploying before we get to that point, and we do that in the application development, but inevitably some will get through.

So how do I go about finding that and removing that in a way that's not overly disruptive? Very good. Yeah.

Um, so obviously you could do it. Um, and we do provide what we call our build time tools. So you could do it as part of your development and build and release cycles, um, and have that feedback loop loop into the development cycle and so on and so forth.

Ultimately, if you think about what developers optimize for is to, you know, address business issues and develop new features and fix, um, you know, customer problems and so on and so forth. We don't wake up in the morning and say, I need to, you know, make sure that the, my SQL package that I'm using is, um, is secure because it's, it's in MySQL is somebody else's code at the end of the day. But, um, uh, the, the better motion of that is that if you could make that a, a, a, um, as part of your operation, so if you think about, um, you know, after a software is developed and it's being deployed, can I actually secure that software in in my runtime environment as it's getting deployed?

And that's where we offer also a set of runtime tools that do all of that and give the capability to, to manage that unused software and, and identify it to security teams and infrastructure teams without having to put burden back onto the developers. And I think that's probably the most, uh, promising motion in order to go about getting your arms around it. Now, uh, when it comes to, uh, actually building really small, smaller applications and so on, so on, obviously that has other infrastructure, um, uh, performance benefits and so on and so forth, then that's, that's when things, you know, you could push 'em back into developers and ask them to, to, to act on it.

But for the most part, from a, from a security perspective, there are tools in the market that allows you to actually manage that software blood problem without having to put burden on the developers Who's in charge of this. 'cause sometimes I feel like, you know, before applications are built, the developers are in charge, but after they get deployed, is it the cybersecurity person's job, they take charge of the application security issues? Or is it still a development team?

It feels like it falls in between? Um, uh, I would like to say that it's, if, if the security team has the visibility, the correct amount of information, uh, type of information about their applications, and, uh, if they have the, the, the tools to automate this process, then they're the best people to actually manage it, uh, in a, in a p from a practical point of view. Because, you know, obviously, you know, there's a lot of desire to, to shift all of this responsibility back to developers.

But again, like I said before, we don't optimize for that motion. We don't, as developers, we don't wake up and, uh, and think about, you know, securing other people's calls and other components code and so on and so forth. Um, that's not our focus.

And we get up in the morning excited about finishing up this feature that we're working on and so on and so forth. So, um, ideally, um, for an organization to run, um, you know, fast then and keep developing fast and so on and so forth, I think this is something that should be done as part of the more to the right, more by the security teams than the platform teams. Um, and, uh, with the tools that are automated, obvi obviously not, not, not do it manually.

I know I create a feedback loop then between the remediation efforts after software is deployed and the developers who originally built it. 'cause at some point, um, you want them to learn from the experience, right? Yes.

Very good. Very good question. So, um, Having the kind of visibility about what is used and what's not used shifts the conversation between security and development teams from chasing CVEs and, and software vulnerabilities to, to one of code quality.

And as developers, we do care about code quality. We might not care about cvs, but we, uh, in, in open source packages, we do care about quote quality. So that, from that perspective, I think that, um, that is, that is a very, very, uh, valid discussion to have with development teams.

Here are all these packages, I, I've, I've observed this, this application for, you know, through your test cycles and maybe for two weeks in, in production, and you're not using all of these libraries that, that are packaged, uh, bundled in here. Um, you know, is, is there a way that we could get rid of 'em because we don't need to maintain these things. And by the way, here's a set of tools that you could get rid of 'em, um, and so on.

So, so we, we'd like to see that motion more and more. But, you know, we are still very early on, first of all, into this insight and also to see how enterprises and commercial organizations will actually end up, uh, developing processes around it. Do you think AI will have a role in this process?

It may be making it easier to find the code or suggestions for removals, or how do you kind of think the the world of the man machine interface is gonna evolve? Um, uh, there's certainly a place for it. Um, and particularly if you think about that, you know, there is, there is a portion of this task that could be done and is being done by some companies, uh, the development level where, you know, you, where you have access to the source board and you could create call graphs and you know, and, and then obviously you could, uh, apply some machine learn models to improve, um, the accuracy of those, those estimates and so on and so forth.

Um, but, um, at the end of the day when we, what we end up deploying in the, in the, in an infrastructure, it's not just the application, but everything else that goes around it, it's the OSS layer. What, however that container, that workload was built post the application being built, and, um, really to get a complete, um, uh, sort of grasp on the, on the problem, you want to be actually analyzing it at, at the image level after the application is completely built and bundled with all the other components. In that perspective, unless you have AI that's a hundred percent accurate, you're back to the same problem.

You almost don't need it because you know, you are watching the application run, you know what it's doing, you are understanding it's interactions and so on and so forth. And it's basically a matter of, uh, whether your tests are complete or whether you observe that application for long enough time to hit, its, its usage as expected usage that then you have a complete view of things. But I think that there, there's some interesting applications of, um, uh, machine learning, um, approaches to improve, uh, the, this entire process.

I don't have my finger on it exactly what that is yet. Okay. Do you think the bad guys are gonna be using AI to discover this code?

It seems like they could probably use it to scan for it, and maybe they'll find a lot more of it and we'll be in more trouble than we think. It's interesting. Uh, you know, uh, the question is that from a practical perspective, you know, how would they actually do that?

You know, do they get into the workload and then they have to download some, some sort of an analysis module to do those kind of things because then they get detected and they get kicked out. So, um, you know, it's, it's, it's definitely possible to do it if you had wide open access and maybe if it's an internal actor that's doing this, these kind of things. But, um, uh, but it's hard to see it in practice, you know, at least in in, in any prevalent way.

So touching on your earlier point, is there any hope for making developers more security conscious? Or is that pretty much something that just never gonna do because well, you know, they're busy with other things? No, no, no.

I think there is definitely a, a generally a, a a, an elevated awareness in the development community about issues around security. And, you know, a lot of that has to do with, at the end of the day, we wanna go put products out there that they're not only useful and solve problems, but they also don't cause problems for people. And so, if you think about it, about it that way, security does become, and this has become increasingly more important, uh, uh, an important part of the fabric of what a developer does on a day-to-day basis, but are they going to focus on solving all of these kinds of problems?

Um, I think that, you know, if you give them the right tools and that you automate a lot of that process, you are more likely to have success. Alright, folks, I think what we're saying here is it's all about reducing the cognitive load on the developers so we can all do the right thing and maybe help the security people, help the developers and get past some of those, uh, historic tensions we've seen. Maron, thanks for being on the show.

Thanks so much, Michael. It was a pleasure. All right.

And back to you guys in the studio.