CrashOverride Cofounder Mark Curphey on Using ERM Platforms to Tame DevOps Chaos

Hey guys. Thanks for the throw. We're here with Mark Curfew, who's co-founder of Crash Override.

They just picked up $28 million in seed funding to address the problem of engineering relationship management. Mark, welcome to show. Thank you very much for having me.

Well, What exactly is the problem we're trying to solve here? 'cause it seems like we've been building software for a long time, and despite our best efforts, sometimes it actually gets out the door. But what is the inherent inefficiency that we're seeing in engineering that requires an engineering relationship management platform?

Yeah, sure. So, uh, let me start by kind of telling you the genesis of the company and how we found about that problem. So both John Der and I'm, my co-founder, had, uh, built startups before.

Um, we're a little bit older than older people, and so we approached it a bit differently. Rather than come up with an idea and hoping people have the problem, which is what frankly a lot of people do, you try and convince 'em that they've got a, a problem that was a problem that was coming down their own. We sat and asked people what their biggest problem was, and we took a long time to do it.

And we interviewed a lot of people. And as we started ing those people, what became very obvious is that as people move to the cloud and as people move to DevOps, they had a lost visibility of what was happening. So the, the sort of simple way to think about that is that when developers build software, they think of source code management, essentially as version control.

It's when developer commits their code, they manage all the versions locally. But what happens these days with DevOps is that code then leaves the system. It goes into CICD and it gets distributed around about once it's left, that version control.

No one knows what happens to it, no one knows how it gets changed. No one knows how other things get put into it, what the actual software that runs are or where it gets distributed. So as we started asking those questions, we were hearing horror systems, we were hearing stories about companies that had production outages, and they had no clue what the code was that were running on that production system or who they should go talk to to figure out where the bug was.

We heard other stories that people had issues, significant issues, and they couldn't figure out what it was was because they didn't have visibility into the CICD system. And what had changed, we started hearing about systems where people started, started saying, Hmm, these docker containers were being pulled from somewhere, but we don't even recognize where they are. And the build systems have been using what's called shadow engineering systems, systems that developers have put their credit card in and all of a sudden they had their own infrastructure, their own tools.

So that's what engineering relationship management is. And that's the problem fundamentally that we're, we're solving. And the name ERM came from, we had a like movement that one day, um, front and we hired some, started hiring a sales team as we started building out the go to market.

And when we were interviewing those salespeople, one guy said, this is kind of like CRM, it's kind of like Salesforce. They had the same fundamental problem. It used to be the fact that when people were, were selling, every rep had their own Rolodex.

Every person you know, was managing contacts and things that are connected in, in spreadsheets and on bits of paper. And as a result, the organization had lost visibility. They didn't know what customers that they have, who they should be targeting, all of those types of things.

And so we realized that if you connect all of this data together, you suddenly get visibility and you have got a single source of truth. So that's what it is. It's a single source of truth about everything you have, how it changes.

And so you can go and improve, you know, and frankly operate your engineering the way you want to. Well, let's go with that CRM metaphor. 'cause one of the issues with CRM is nobody wants to enter the data or spend the time to enter that data.

So how does the engineering relationship management platform actually know what's going on and where does it collect the data from? Yeah, so we're in a lucky situation with building software engineering. The, the way it happens, of course, is through automation.

So what crash override does is we've developed essentially deep build inspection. So what that does is actually sit inside the CICD, it's not run as part of it. We actually are able to sit inside a building and watch everything.

We then connect up to the AWS and we call with you using A-W-S-G-C-P Azure connect up to GitHub. And then, because we watch every change that happens inside the bill process and we know where the code came from and what changed, we know that where it gets shipped, we're able to connect those things automatically. Developers actually don't touch anything.

They don't need to do anything. Every time things flow through, we know about it. Um, and that often includes things that no, that no one did know about.

So for instance, things we found things where stuff happened in the build process and we know, wow, these software containers didn't come from a corporate system, this code didn't come from the company's GitHub, but it's trying to be pushed into production or, Hey, this code was built by the company system, but it's trying to be pushed to a cloud, which we don't actually know. So not only do we understand, you know, the, the, the space that actually people, you know, want to instrument the change, but we also get to see, you know, the, the, the white space will people have to see, um, We hear a lot about bottlenecks and DevOps and everybody kind of nods their heads and says, yeah, we wish everything was ruthlessly automated, but it's not. Is this kind of the root cause of a lot of those model links?

Um, we see a lot of automation, um, for sure. But I think absolutely what you say, it's not automated. Let's face it, engineering is kind of somewhat chaos and a lot of people encourage people, let's go, you know, create our own systems.

We wanna have as least rules as possible, like, you know, run fast and break things and fix them fast and all of those sort of things. So are there bottlenecks for sure. But I think our take on it is that what we're trying to do is help people build the highest quality software and get it out to market as fast as they can.

So essentially promoting innovation, when you understand that visibility, you understand where you can improve, of course you understand where there are problems, but you can shut down those problems to improve efficiency. So, you know, for us that's, that's the kind of, uh, the kind of approach we take. You hear a lot about platform engineering these days, or is engineering relationship management and the move to platform engineering kind of joined at the hip in some ways?

Yeah, and same with DevOps. So you know, we, we look at it as coach cloud, right? So it's like developers creating code, code goes into ci, lots of different things happen, gets shipped out to cloud.

So you know, if you are building a platform deployed out to the cloud, you have to understand the complete spectrum of that stuff. And it's not just the stuff that you produce, it's the open source, it's coming in, it's the tools that you use. So we view it as both, you know, the code that's flowing through the systems, the systems and the themselves.

And you've gotta tie it all together, like the context and the relationships between it all is one of the things that's most important. And that's why sitting in this privileged position inside the CICD is, you know, is how you go do it. And how does get installed in the CICD system itself?

I mean, how, how do you kind of get in there or become embedded in that? Is it a plugin or how does that work? No, so essentially we developed an open source project as we were prototyping this out.

And so that's referred to as chalk. So the best way to think of chalk is it's like inserting an air tag on the code onto the bill system. So not only can you then track it, you know where it's gone, but you also know everything about what it is, what it is doing, and you install chalk at a bit server level.

So it doesn't have to be going stored repo by repo. You certainly can, you can do that through GitHub actions if you want to go do it. But typically you install that at a build process.

And technically the way that works is with, with Docker as an example, once you've run chalk, you essentially alias, um, chalk to, uh, alias Docker at a chalk. So someone wants to go run a dopper command, they actually call chalk chalk, then goes and calls Docker. So we essentially take control of that process, which means then we sit inside the build process, not as another thing that runs that other people could disable and not give us access to, to, to the tool.

And then we then stick a beacon, the air tag onto the container so we know where it's been deployed, whether it's been changed, where it is. Um, and that's ultimately how we instrument things. We've had customers that have run literally you can you go type one line, um, inside, inside the build system.

Every single bill that then passes through it, you know, gets, gets ran and the telemetries inside. And we will get, you know, thousands of, of of bill reports that come back within, you know, 24 hours of some of the large customers. You cannot walk down the street of course, without somebody leaping out to tell you about their great new AI thing these days.

Is there an opportunity to apply AI to this data that you're collecting? We are already, um, both, um, applying it ourselves but also helping people figure out, you know, where they're applying it and get some controls around it. So, you know, an example of how we are doing it is that, um, you have large, large cloud environments.

Well, what is production like? That becomes a really interesting question. And then back to your things like, well that is, if someone marks this thing as being production, we built an algorithm that looks at the patterns of deployment, where code is coming from, who's deploying it, where it's going to, and we're able to infer where production is automatically.

Is it perfect? Absolutely not. Is it damn accurate and damn good and solving problems, absolutely.

Customers that that use that of finding it incredibly useful to map out what is production and, and how, where does code go? What is happening recently, which is also very interesting, is when we think about what code is most important, we have customers with, I think the biggest one has 200,000 code repos. How do you know what's important, right?

How do you know what's actively being developed, how you know what you should be focused on? Like what are, what are things that are deployed out to prod? So as well as that, we do some analysis on the code and one of the things that we've been developing is a thing called Tech id.

And what Tech ID is, is it looks inside of the code to figure out patterns of what's in there, what languages are being used, what SDKs are being used, are you using Stride, they're using Salesforce, are you using, you know, x, Y and Z? One of those things that frankly I've been experimenting with recently that will make its way into the product pretty soon is where are you using Gen AI code? So where are you using rat play?

Where are you using core of all of these things? Because again, like a lot of the instrumentation is essentially surfacing hidden information inside of the mill process. And those tools leave hidden information inside the mill process.

So helping people understand, hey, you have code by the way that has been developed by a third party, they're not inside of your GitHub org. They happen to be using rep lit, and by the way, it's made it into production. These are really important things to people.

Other stuff like do you have a sql er, a SQL schema that was generated by chat GPT that is running in production. That becomes really interesting scenarios and those are the sort of things people are looking to get to Brooks with. So from our perspective, it's not only are we using it to accelerate our own development, but we're looking how can we help customers that are using it to, to do that better themselves?

Hmm. It's no secret that organizations have also been struggling a bit with DevSecOps over the years. Is there some way to use this platform to kinda also discover or find or track a lot of the vulnerabilities that seem to be floating through our systems, but everybody's not quite sure where they are?

Yeah, absolutely. So, you know, we are equally and probably more so an engineering company than we are a security company. Our DNA has been in building security tools, but we've been engineers building security tools.

So, you know, I'd like to think we're, we're somewhat the main experts in this space. What you can, one of the, one of the scenarios that you can do with, with chalk and being instrumented in the CICD is, you know, what process are being run. So not only can you see what tools are being run, you could actually orchestrate them to run underneath the her with no one knowing.

So you could automatically run, you know, tools that do SBOs, find out what open source is there, match them up against the vulnerabilities, you can run static analysis tools inside of that as well. And then of course, because you can correlate it, you understand I've got code that being pushed into production that hasn't gone through a security scan. So those types of scenarios become, you know, very interesting.

Um, there's also interesting and uh, a cost piece of this as well. Some of the security tools license stuff are based on a per seat license and they're very expensive because we know, excuse me, how many people are pushing code to production? I can actually tell you how many people should be licensing that code, and some of them will try and license you based on every single code repo.

Well, guess what? A lot of those code repos actually aren't used anymore. Great.

Go figure out how to assign the money to the right places that you can make improvement versus paying this tax. Well, you shouldn't actually need to go pay the tax. So there's a lot of interesting security scenarios that, uh, that kick in and you know, frankly, some of them we're discovering with working with early customers.

And, uh, yeah, fascinating. You go see it. You mentioned vibe coding and chaos earlier on, and I can't help but wonder if we're gonna have more of these so-called citizen developers building applications and software.

Aren't things likely to just get more chaotic? Look, my wife's lost me to, my wife's lost me to buy coding for the last two weeks, but I'll be perfectly honest, it started two weeks ago. Uh, actually it started a, at a board meeting.

Um, Google Ventures were, um, were one of the large firms that, uh, were participating in the seed round. And as a, as a side conversation, it was like, Hey, this stuff is really increasing, it's just incredible. And so a couple of weeks after that in New York, my wife was out, I'm sat there with a glass of wine like, Hey, let's, you know, let's not watch tv, let me go figure this out.

And since then, you know, frankly she's lost me. It is fascinating far from panacea, gets a lot of stuff wrong all the time, creates all sorts of problems, but absolutely it is able to essentially, you know, it's essentially enabling non-technical people to go go software and it's enabling technical people to be able to create decent software and it's enabling professional developers to have superpowers, right? It's, it's right through the spectrum.

But if we think about that, instead of now having 20 million developers of whoever it is building code, all of a sudden the world is able to build code. If we think about a company, you know, it's typically the development team, now it's the marketing team, now it's the accounting team that can go produce code. So this visibility problem is actually getting significantly worse.

We're at an inflection point. So, you know, the vibe coding thing is absolutely phenomenal, and I fundamentally believe it's changed the world and it's changed the world of how we build software, not really just vibe coding, kind of the, the the non-technical people leaning in, getting the buy, but the gen AI stuff, right? As, as well.

Um, and that's both, you know, also with the ability to build tools. So anthropic last week released a set of prompts to go do security analysis, um, using Claude. It is incredibly effective, like as effective as some of the stats, some of the static analysis tools that we've been using for a long, long time.

So yeah, changing the world, fascinating. And, um, there is absolutely really interesting things that we are, we are, we are doing both helping people use it more efficiently, helping people find out where it is, but as a company embracing it ourselves to accelerate what we're doing and make our products better, What's your best advice to people to get their arms around this thing known as chaos? Because I think in a lot of instances it's kind of like a back ache.

We get used to it and so therefore we don't realize it's an issue until somebody comes along and solves the problem for us. But where should folks get started? Where's the, where's the, where's the point of entry for the journey?

So I mean, look, I'm an early sta early stage startup guy. Chaos is what I love. So, so, you know, may maybe you're asking someone, uh, interested in shutting it down is not necessarily, uh, um, I, I I embrace it and I think the reality is it happens everywhere.

Um, even if you think in large companies, large companies now have pockets of teams in innovation is encouraged in small teams. So to a large, you know, to a certain extent, even teams that, even companies that don't have chaos now are studied to create small teams with chaos. So, you know, the first thing is to embrace it, you know, it probably sounds self-serving, but to a large extent, visibility is understanding, you know, is the first step.

Once you understand what you have, you're able to decide what bits of chaos do you wanna embrace, which bits of chaos do you wanna figure out how to, you know, pull back and put some controls on. So, you know, an example of that is tools, right? So like I said, developers can put their credit card in now and I can have, you know, the biggest world supercomputer A AWS, right?

At the end of my corp card, I can have my own Docker system, you know, that's sat there. I can have my own GitHub org, right? The, the the age of shared security services, you know, is, is a challenging one yet.

So, so from a security perspective, the security guy wants to make sure he's got the right security controls on the right thing, but from the engineering side, they wanna make sure that they have supportable systems, they wanna make sure that, you know, developers can go discover containers. They don't have to go build and maintain their own as an example. So, you know, there are certain things that I think, you know, are, are powerful for efficiency and effectiveness for engineering in, in controlling the chaos.

And there are certain things that you wanna, you wanna let go, right? And you want to, you wanna encourage, like, you know, allowing people to, to explore and, and, and embrace, you know, Claude, like embrace rep lip. Like you do not wanna be shutting that down.

Like even though it may be creating chaos, like it is undervalue grief changing the world, um, but understanding where it's being used and there are other things that you need to figure out, like, okay, now I need to stop putting controls on, on that thing. Um, but you know, it's self-serving, but visibility allows you to go and make those decisions. And I think that's what we, what we see in a lot of organizations.

Well, folks, you heard it here, there is a method to the madness. It might just be called engineering relationship management platforms. We'll see how this all turns out in the months and years ahead.

But in the meantime, buddy, thanks for being on the show. Thank you very much. Appreciate it.

All right, and we'll see you guys next time.