Tackling Software Supply Chain Transparency with Kusari’s Tim Miller

This is Textron tv. Hey guys, thanks for the throw. We're here with Tim Miller as the CEO for Kaari, and we're talking about how to apply zero trust principles to securing our software supply chains.

Hey Tim, welcome the shot. Hey, Mike. Thanks for having me back.

We've been talking about this now in earnest, I think, ever since maybe the SolarWinds attack. Um, but what makes it difficult because at least in on paper, we wanna lock down our software supply chain, so we should just make them more secure. A little more credentials are secured.

And how hard can this be? So, you know, what is the fundamental problem? Uh, I, I think it might just be a perception or a, a, a missing of the, of applic of applying the principles that we all know to something that's kind of fallen to be a standard practice.

Um, moving to a zero trust environment really is about validating all the time, right? You stop just, it's about zero trust. Don't trust the credentials only.

But with software, uh, a lot of us don't do that still. We kind of keep the artifact in either our production or, uh, repository that we, that we trust and then we push it there, or it's been blessed by some release process and then it's just kind of gone. But time is still ticking and it's still gonna reveal stuff as as it's moving along.

And I think we just forget to do that, to be honest. Um, and then that moves all the way, all the way up the chain up and to open source libraries, like what are you pulling in? Why do you think it's okay?

Why is it okay to move these things along? So I think it's just really about realizing that to apply the same principles that we're doing for like networking to how we really software, I think everybody kind of nods their head when they hear the phrase zero trust and some of the more advanced souls think has something to do with identity and multifactor authentication. But, um, what exactly are we talking about when we say zero trust principles and, and are there degrees of zero trust?

Uh, yeah. I think zero trust is a buzzword just to be a hundred percent clear. But, uh, I think that the idea, right, is there's not one thing that you trust.

You don't trust me as a human to get in and then have full access to something. Um, it's about removing one boundary as the only boundary. So historically you'd get network credentials, you'd be into the network, and then from whatever that you could reach there, you could reach.

And we realized that that's a bad idea. 'cause if you see my credentials and suddenly they pop up being used across the country, that's probably a flag you should pay attention to. So using that identity in context and understanding what it's supposed to be, and constantly validating is really just the, the, the general, the general idea.

Um, so it's not more complicated than that. And then the, the amount of, uh, places that you can apply that identity and can apply that context, uh, the better. So, so there, there's certainly more than one level to this.

It's more of a, I think a, a scale. Um, and I think it gets difficult when things don't inherently have an identity. Like nothing.

A piece of open, open source software, it doesn't really have an identity to it, it's just a binary that you pull down or a, you know, a, a container or something. But there's not necessarily an a a typical identity associated with it. And that's where I think some of the, uh, learning can be applied from all the issues that we've had with networking and things like that.

Well, do I sign it? And then that gives it identity. And at the same time, the machines have identity and the developers have identity.

So there's a lot of identities here. Yeah, I think, again, I think it's mostly putting things in context. Um, one trick that we've, uh, seen being applied pretty frequently is the use of attestations.

So where identities lack, you can kind of, uh, impart that first, uh, link in the chain, so to speak. Um, so where to I to basically assign both an identity and the context about how much you knew about it at the time, and then build the trust from there, or build the build up your ability to validate it from there. Um, so, uh, attestations are great because they can assert that you, at this point in time, uh, knew, uh, either the state of the vulnerabilities about it, knew where it come from, you have the process about it, and you can put a, you can put an expiration on that just like you can with any signature.

And so we really like the idea of taking outta stations, plopping them on your, on your chain, and using that to kind of bootstrap this process to make it not so complicated. Um, and use that, use that as a way to step into, to your point, that that's not you. You're not either, uh, legacy or zero trust.

You're, you're getting there. And that's a good way to start. Um, who's in charge of this?

'cause sometimes I feel like, you know, we expect the people who built the software supply chain and all the DevOps platforms to secure these things, but I don't think they're security experts and inversely the security people aren't app dev experts. And who, and, and who's allocating money to fix this? Uh, well, that's a good question.

I think it, I think it, uh, well we, we've seen it be a little bit split, to be honest. Uh, I think the general idea would be this would come from a security team. Um, but part of the issue is that a lot of the lack of, uh, validation, uh, data that you would need is rooted in just open source stuff.

And there's nobody responsible for that. It's just out there. And so it kind of comes back to you as an org, um, where, where your trust really lies at, at the, at the end of the day, it's unfortunately the, the whole thing.

But we're generally seeing it be come from the security team, be responsible for applying these kinds of principles. And then depending on an org, sometimes they've got a DevOps team that's separate. Sometimes they've got a dev team that kind of rolls in.

Um, but it really has to be both. 'cause you can't just come in and start applying these principles to folks or to tools that you don't have control over or to teams that you don't generally interact with. You also don't want to do this in a way that stops development altogether and suddenly nothing is able to pull down.

So it's gotta be a bit of a give and take. Um, usually the, the DevOps team, when there's a DevOps team, that's gonna be where this falls in terms of the person doing the work though. Yeah.

So everybody will stand around and say, this is an awesome idea and we gotta get a bunch of technologies together. And here you go, figure it out. But the question I have is, I, there's so many little technologies, right?

It's not like I go buy zero trust per se. So how do I wrap my arms around all these pieces that I need to kind quote unquote orchestrate to execute the plan? Yeah.

Well, I think it starts with, uh, understanding, getting your, uh, knowing the pieces that are coming in first and being able to associate some sort of an identity with those lots of tools to do that. You don't have to buy anything. There's lots of ways to go do that.

Six store is a great set of tools to start doing this with many others. Um, but starting to do that basic, Hey, this is what's, this is what's coming into my environment. This is, uh, applying some basic signature practices to those things and then moving forward.

Um, and yeah, it's gonna be, it's gonna be a little bit tricky, but again, I think if you build it up and you start to apply those validations even entirely within the dev cycle, uh, just to start, and then you can start to move into things like binary au and start to use some cool words like, uh, the Google folks use and things like that. Um, but yeah, it, it, it's really not that hard to get started. It's a long journey.

Um, but I think those first couple steps, uh, light up the path, so to speak, for what to do going forward. 'cause it really is, once you have that validation, you start to want it, it starts to remove work from what you're doing. It makes it nice.

It feels really cool to have something locked or allowed because of the context that you gave to it. Um, I, I, I think it starts to build this really cool momentum in the process once you start to get going, uh, and realize how easy it is to just take those first couple steps. Again, I'm not, I'm not claiming that those first couple steps are gonna get you into, uh, the promised land, uh, but it's, you know, it's, it's, it's really, it's really fun.

Sometimes you gotta start with the fundamentals. Um, how much of this is a cultural issue in the sense that are development teams kind of too trusting by nature because they're used to kind of, you know, downloading code where they find it and they're like, Ooh, look what I got. And we're not really kind of thinking through the, uh, motives of some of the malicious people out there.

I I, I think culture's a huge part of it. Uh, and I think one of the easy things to fall into the trap by being dev, I, I know we've all done this spreading code. It's like you get something to work and it's super exciting and then you forget to check, um, or you don't do any, any further digging and suddenly like, oops, uh, there, there, there's a problem.

But this is where that's helpful. This is where it becomes guardrails. So you can be, uh, you can, you can move faster and you don't, and you can start to, uh, trust, uh, your own process now in terms of, Hey, I'm bringing something in.

I'm signing it. It's going to validate this, it's going to validate that you get a little bit more freedom to move quickly once you put in that basic work. But it does, it does apply a little bit of a shift.

And you really do have to be a little bit more paranoid, particularly in the environment that we're all seeing where this, these, these issues are pumping up more and more. Um, so it, it, that's, that's not something you can buy either. You really have to want to do that These stage.

You can't walk down the street without somebody telling you about their great new AI thing. Can we apply AI to this to save us from ourselves, essentially? Uh, I I think AI can certainly help.

I think it could also hurt. Uh, uh, uh, I'm not sure that AI is necessarily the answer to some of these things. Uh, you can certainly use it.

Just speed yourself up. I think where AI application can be great is if, is filling in some of the details on doing something that you're not entirely sure what to do. But the dangerous thing about AI is basically the same, same issue here.

You don't necessarily know the data sources that that's pulling that code or help from. And so you have a, a bit of a similar issue. How are you validating the data that went into the model that's giving you the output so that you know that it's a safe thing to do?

Um, so you still gotta do that same kind of validation. You still gotta be paranoid about it, but I certainly think it can help you move faster, for sure. Uh, I wouldn't call it the golden bullet though.

Do we need to kinda slow down to make sure that our software supply chains are in fact secure? Or is there a way to have our cake and eat it too and keep running at the speed that we're at, but just make the whole thing more secure? Um, so there's the, there's the very common wisdom of slow down to speed up.

Um, but I don't think it has to be that drastic. Again, I think a lot of the basics can just be applied, uh, almost in step. 'cause again, if you view it as a journey and adding one, one piece of validation, uh, is not in and of itself the entire journey, but isn't really gonna slow you down that much a little bit.

It might, it might, you might take a, a side step here and there, but I don't, I wouldn't think of it any different than applying, uh, fixing tech debt to a project that has a feature deadline. Uh, it's a similar thing, right? It's just a non-functional addition to how you're operating.

Um, so you could approach it by fixing your entire process, stopping getting it all right and then moving again. I doubt that's necessary. Uh, again, 'cause folks are dealing with it today, it's just harder.

I think it's more work. Um, and you can do this in a better, smarter way, but little step, little steps are great. Iteration is fantastic.

Get it work in a little bit at the beginning, move forward and keep pushing that, keep pushing it, right? So, so this is not a shift left. This is a shift shift, right?

Start all the way at the left and then keep pushing it. I want you, this is also just part of the, the metrics we track or you know, how quickly did you write the code? How many release cycles?

But we don't have a set of metrics that kind of measures the security of the environment and how we did on that. And the absence of metrics, people don't pay attention to that 'cause they're being rewarding for other things. Uh, so klos were the perfect answer to, to all this stuff.

Um, uh, the, uh, I think it's true. You're gonna, you're, you're gonna get the outcomes that you incentivize. Um, but I think a lot of the metrics are kind of hidden or the, some of the metrics we already use mask this a little bit.

So things like MTT or how fast is it for you to, how fast can you remediate something? How quickly between identifying something and getting that fix out there, is that occurring on a frequent basis? How many repeat issues are you getting?

A lot of those issues are there, uh, and we're just dealing with them in a kind of legacy way. And you can, you, you can really look to, to push those down. If you take a slightly different lens on the problem, stop chasing the, the vulnerability metrics and start chasing how fast you're able to attack things or attack things, is really attacking the problem so fast.

Can you move through your own process? How much, how quickly can you get outta your own way, uh, are all signals that are probably inflating all your numbers across the board in that, in that area? And that's where you can start to tick it down.

So what is, how do I organize this in a way where developers and cybersecurity folks are collaborating? Or is it more about, um, you know, just sending it upright the first time and then getting at each other's way? I, I, I've never seen the latter.

Uh, I, I I, I, I really, I don't know how to do never happened. Uh, not, not in places that I've been anyway. Um, no, I I I really think it's got, it's, it has to be collaborative.

And I think the more the world starts to shift into realizing that security and, uh, development are just kind of two different sides of the same thing, at least in the application development space. Um, it you, it's not a one, uh, it's certainly not a one-time thing. And it's certainly not a, you need, you need a greenfield environment to do it.

Um, but you do like it. To your point before about culture, uh, there is a culture of the, of the organization where that collaboration really has to, has to be closer in order for it to actually be affected. 'cause in debt, you can validate everything you want, but if you're still not pushing it down out to the production, uh, releases and validating that constantly, you still haven't gotten to the place where you're trying to get to.

So it does have to cross that boundary. So what's your best advice then, at the end of the day? 'cause it does seem like a lot of organizations, uh, they acknowledge there's an issue.

They are aware that they struggle with it, but, um, you know, then the next bright new shiny object shows up and they're onto something else. Yeah, again, I would, I would start to hold this as tech debt for yourself. And you can start to make, make that progress within your own project.

And you can start to improve your own processes out that you can affect what is already inside your, uh, ability to control. And then once you can get that working, showing something that works, especially when it's got a security angle to it, to a security team, is gonna be an exciting conversation. They're gonna love it.

It's gonna, it's gonna be a, like showing off a really cool toy, uh, that they're not, that's not gonna be a cab betta. I think that's gonna be a great thing. Uh, and then you can use that to, to, to move forward.

So you can, you can start small. You can start within the sphere that you're in, and you can do that on either side of the, uh, I mean non-existent fence here. But, uh, you, you can do that in the security side too.

Start validating all the releases that are coming. Constantly start applying these identity principles. Start asking, Hey, how can I, how can I get some validation here?

The other thing I started looking into is all the different attestation formats that start looking into the, uh, minimal signing procedures that start to look into, uh, reducing your key usage. And all these can be done, uh, without a ton of effort. Some might be harder in certain environments than others, but none of them are like a massive leap forward.

You can take a little step. Um, I always like to just put some budget for tech debt, uh, in whatever we're doing. Um, so whether or not there's a feature that's really gotta hit a deadline, there's always some tech debt allocation.

And I would just hold this like, like that and see what progress you can make. Even taking little itty-bitty steps, uh, or try to an open source project for yourself. Uh, there, there's lots of different, different ways to get started, uh, without, without needing a whole program for it.

Alright folks, well you heard it here. Hey, maybe the secret to this whole thing is to me, software supply chain security. Cool.

And then worked out. Hey Tim, you can win on the show. I really appreciate it.

Thanks again. Alright, I'm back to you guys and Steve.