Open Source Tracking in Software Supply Chains with Kusari’s Tim Miller

This is Textron tv. Hey guys, thanks for the thrill. We're here with Tim Miller, who's CEO for Kaari, and they're a startup company that just raised $8 million to address this thorny software supply chain security issue that's been out there.

Tim, welcome to show. Uh, thanks for having me, Mike. So what is the core problem here?

Because we've been talking about this forever and a day, and I don't know, we're making a whole lot of progress, but why do we need a new company in this space, and what is a problem that we're solving? Uh, yeah. No, it's a great question.

Um, so I think funda fundamentally, the problem really hasn't changed at all. Just the scale and the speed at which everyone is moving has increased. And so the traditional approaches are, uh, are are, you know, failing to scale with the same speed that everyone else is.

Um, fundamentally I think software is, supply chain security is really about knowing what you have. And a lot of traditional approaches take a single project view of the world, when in reality, most organizations have hundreds if not thousands of projects altogether. And when you really put yourself in the shoes of an engineer at a, at a software development shop of any scale, trying to get ahead of that problem requires much more than a traditional, um, you know, plugin or scanning tool.

Uh, you really need a lot more information at your fingertips. Uh, and that's really, I think, the problem that's been, that's been missed or avoided because it's pretty complicated. Uh, in all honesty, uh, software develop, software environments are messy.

How does that therefore plug into my say, DevOps workflow? I mean, where do you fit in that spectrum of things and, and, and where are the handoffs? Yeah, so I think to put in perspective, where we come into play is trying to simplify the supply chain, uh, problem allow folks to see the gaps and understand what they have and make more pragmatic decisions.

So that's the context in which we will answer that question. Um, but typically as a, as a DevOps folks, if you put yourself in the, in the shoes of someone trying to fix something or like the first 10 minutes of what happens after log four J uh, you know, V two comes out, um, the first thing you're trying to do is find what's going on. And that's a incredibly difficult problem for a lot of folks.

You end up with this, uh, approach of patching, the first thing you see running your software through your CICD systems, waiting for everything to come back and just hoping that the scans come back ne negative, and hopefully they do. Um, but a lot of the time it's not like that. It's more complicated.

Software dependencies are not one layer deep. They're many layers deep. And what you really need to understand is where things came from in order to make a tactical and confident decision.

And that's really where I think, um, we're trying to play or we're trying to help folks. Um, but really it's about tying that information all together. You've got a lot of it, but you just don't know how to act on it or you're confident in it or anything like that.

So it really ends up being an information management problem for, for these people. So in the same sense that we may have a business intelligence app, we need a security intelligence app for application development. Yeah, yeah, it's a good way to think about it.

Um, and, and again, you can, you can imagine that the amount of things that any one, uh, software team is dealing with is, is crazy. It's, it's a lot of, it's a lot of information to sort through. They don't necessarily know where things came from or who put it there or why.

Uh, so the context around things really ends up being something that folks have very little of. Uh, and so the more that you can help with that, uh, the, the quicker you can react to things and the less time you spend searching and, and, and waiting for things to go, and you just make the change and get back to your day job. And a lot of times the dependency that might be affected isn't even something that I as a developer have control over.

It's a component that somebody included inside the app, but at the very least, I'll know where to start making my emails to and kind of get that process rolling. Right. Well, yeah, at the very least, you want to know where it came from, um, and that that can help you and help inform you whether you have control over it or not.

Uh, if it's critical enough, you might want to know that, uh, and then get control over. There's all sorts of different ways to to attack, to attack that problem. But yeah, know, knowing tends to be the first step of solving any of these things accurately and, and solving 'em correctly, uh, or at least creating a, a mitigation plan around it.

Um, so at the very least, you know, you need to do that, uh, and then, uh, and then go forward from there. Also seems like a lot of times the issue at hand is a component that's an older version of something, and I already have the new version of that, something located somewhere in a repository, and if I replace A with b, I could solve my issue and hopefully not break something along the way. But to your point, it seems like we don't even know what we have.

Yeah, I mean, it's a shockingly basic problem. Um, but it really is a problem. And oftentimes you, you may even have both versions of something in your stack and, uh, they're, they're just at different places or they're deployed differently or, um, but yeah, in order to get your head around it, and particularly to be proactive, you really need to understand what that, what that, uh, tree looks like and, and where those things are all coming from.

And then, uh, and then try to reduce the complexity on yourself going forward. But, uh, yeah, it's, it's a really, uh, shockingly hard problem to answer what exactly am I working with? Alright, so you picked up $8 million in funding to get started.

What comes next? Where, where are you guys on this journey? Um, so yeah, to date, we've been, uh, working on the open source project guac.

We've been working with Google, uh, Purdue University, um, city, uh, a bunch of great folks on, on that. And so far we've been getting great traction on the open source approach to solving this problem. Uh, next we'll be pivoting into making sense of that data and helping folks navigate what to do going forward.

Um, so to help identify gaps, uh, to, to know what to do in any of these situations, uh, 'cause that in and of itself can be complicated. Um, so working on our, on our, on our own product launch to, to get ready for that, we'll be investing in, uh, and engineering that. And hopefully towards the second half of this year we'll be, uh, ready to show that off.

So is that essentially a curated instance of the open source project and is maybe tailored for a specific business? Or what is the relationship in your mind gonna be between open source and what you're offering? Yeah, so you can imagine that the open source guac project provides you the transparency and visibility into the data that you have.

And for a lot of people, that's enough. And we'll continue to curate that and keep that source, uh, keep that core open, uh, and then what you do and how to navigate that, what to do about any of that data is where we're gonna come in and help, uh, provide the buttons to fix things for you. Uh, and, and just generally take that, make answer the so what about any of those, uh, all that data and, uh, and just make that part easy.

Um, so it's really simplifying the problem and taking, taking away the co the, the complicated nature of navigating the supply chain issue. Do you think AI has a role to play in this someday? I mean, I could imagine me coming into your little console and typing in, show me the three things that are likely to get me fired today, and maybe you'll Oh, yeah, absolutely.

Um, so there's already been some really interesting prototypes, uh, around that. Um, you know, so some, some folks created a, a little prototype tool called Guac ai moly, and it did exactly that. It, it, it sat on top of guac and allowed folks to answer the question, Hey, do I have this vulnerability in any running containers?

And where to come from and seeing that interface is, is, is amazing and, uh, really excited about where that can po potentially go. So absolutely, it will have a, we'll have a big role to play in this, particularly in how folks interface with the problem. I think one of the dirty little secrets about software is that we have this massive amount of technical debt in terms of vulnerabilities that fortunately or not heavily exploited, maybe only a single digit percentage of them are, but the bad guys will probably get around to 'em.

What's your assessment of the current state of application security? I know we can draw a line in the sand and say, you know, from here on out, we'll get better, but do we gotta go back in and fix all that stuff that's already out there? Um, so I, I think the current state is, is, is just missing a couple key pieces.

And I, I think that's really where we're coming in. So I don't think it's fundamentally broken, but at, at, at, at a, at a basic level, uh, a a lot of the inform, there's been a big information gap between security teams and application development teams. They tend to, they tend to not share information very well.

Uh, and so there's this information silo that exists that, that exists that the current tooling hasn't really helped enable. Uh, and so really I think if we can tie all the data, get together, have one source of truth for what's actually going on, both on the vulnerability reporting and on the, on the folks who can actually do something about it on the dev side, I think that's really the missing, the missing piece. Um, 'cause fundamentally, as a, as a dev, when you're trying to fix something, you have an entirely different tool set than what the folks who, who told you you have something, uh, going, going wrong, uh, or at least, at least at a certain scale.

And so really bringing those two things together in a real practical, uh, way, I think is, is the missing piece. Um, but yeah, it's, it's only gonna get harder as things speed up. Can we get to some sort of kumbaya moment between these teams?

Because historically, the cybersecurity people would be like, here's your list of vulnerabilities in a spreadsheet. And then the developers would be like, well, thank you. And then they'd go look for all this stuff and discover that 99% of it's not running in a production environment or is not internet facing, and then they, um, mutter under their breath and then they stop paying attention to the cybersecurity people.

At least that's my experience and how it works. So, you know, can this get better? We certainly believe so.

Um, I, I think one of the fallacies is that you need to do something drastically different. You need to completely restack, uh, in order to, in order to have that kind of, uh, interaction. And really, I think it's just about breaking down the walls and sharing the information in a way that's practically usable for both.

Um, but it really starts off on, on unifying how both of those different sides of the house look at the data, um, because it really is a data problem. And, uh, and then from there you can make it practically usable, uh, for, for, for both folks. Uh, I think that's really been the, the difference is a lot of tooling either focuses on the vulnerability reporting and forgets devs or focuses on the updates and forgets that people have to pay attention to where these things came from and how to report them and understand the, the, the workflow around the, the issues themselves.

Um, so I think, so that's what we're here to do, Right, folks? Well, you heard it here. Software supply chain security is just like any other, IT problem, it starts and ends with the data.

If we get the data right and everything else becomes reasonable, Hey Tim, thanks for being on the show. Thanks a lot, Mike. All right, back to you guys in the studio.