Gomboc Automates Trusted Vulnerability Remediation

Hey, everyone. We're back here at Platform Con. Hope you're enjoying our coverage.

We're having a great time. We have a little like petit here. Yeah.

The corner with a 270-degree window view- Can't beat the view here ... you can't. " From north to east to south.

It's crazy. Anyway, my next guest is my friend, Ian Amit. We were talking off camera.

I first met Ian at the very first Security B-Sides Las Vegas. Mm-hmm. If I'm not mistaken- A few years ago.

A few, well, let me tell you how few years it was. Don't they know it was. No, but- I think Black Hat was still at Caesars.

It was, yes. It was not yet at Mandalay Bay. It was at Caesars, yeah.

And so that gives you an idea. But anyway, we'll be at Black Hat. It's another month- Right ...

month and a half away, but less than a month and a half. Ian's done so many different things in a very stellar career in security, but he's founded a company called Gomboc. That's G-O-M-B-O-C.

ai? ai. Ai.

And we've had him on before at Platform Con and on Zoom kind of Techstrong TVs. He's here at Platform Con. Actually, Ian and I were on a panel this morning talking about the vulnerability apocalypse, yes or no, and what we could do about it.

But, Ian, first of all, welcome back to Techstrong TV. Thank you. My pleasure.

I gave you a little buildup, but feel free to embellish, tell people about you, and more importantly, about Gomboc. Sure. So again, personally, my background has always been in security.

I've been a hacker since I can remember myself typing or being able to tinker with machinery of sorts. I've spent most of my career in security in the offensive side of things, pen testing, red teaming, hacking, running security research teams, and eventually found myself kind of gravitating towards the other side. And, as Alan mentioned, a couple of CISO roles in my past, which led me to where I'm at right now.

" And, after realizing that's not the case, started Gomboc. And, yeah, it's been a hell of a ride since then. Absolutely.

So what was the problem? So the problem was essentially, and we've talked about that in the panel before, realizing that from a security perspective, we know almost too much. We have great monitoring.

We have great detection. We have ability to see what's going on and kind of quantify the risk and evaluate it and prioritize it. Great.

But when it comes to actually addressing it and fixing the problems, we're running into a bottleneck. First and foremost, it's not our responsibility. So it's DevOps, it's R&D, IT, whatever it is.

And second of all, let's say that prioritization is not the issue. There's a bottleneck. For every 10 vulnerabilities we find or kind of ask to address, IT or DevOps can only fix one in a best case scenario.

So realizing that that is the bottleneck, that there aren't any good solutions for proper remediation, and the automation mechanisms that existed mostly focused on the process, on shoving more alerts and enriching the alerts. But didn't really address the core issue of someone needs to review this, someone needs to contextualize, to bring in a DevOps kind of architect, platform engineer perspective into it, and apply good old-fashioned engineering into the fix itself. So that's kind of the initial focus.

We initially focused on infrastructure as code because honestly, it's easier. It's not really code, it's more of a script. It's very structured.

And it enabled us to identify that space, hone in on what is needed to solve that problem systematically in a way that engineers would accept it. And that's really the key because, again, based on my experience, if you give an engineer a reference implementation or an example, it's like, "Great. You didn't solve my problem.

" So the focus was really engineering the production quality fixes, remediations that engineers can accept. So that's what we've built. We've built a deterministic AI model that can address and resolve and solve security or misconfigurations in initial infrastructure.

We're going to talk about moving beyond infrastructure in a second. Right. It's almost like it's an oxymoron, a deterministic- AI ...

AI- I know ... solution. I've heard that many times, and I want to say not to be blunt, but Alan knows me already.

You're blunt. " Right. Yeah.

And it's probably not me. But it's actually not an oxymoron. Deterministic AI existed since AI was invented.

We're looking at decision trees. We're looking at knowledge graphs. These are all deterministic AI models.

Absolutely. They're pattern recognition. Exactly.

We- LLMs are not the only AI models ... you just did it. I think we- We focus in on the gen AI- Exactly ...

chatbot thing. Right. Our friend John Willis, who was on the panel with us.

Yeah. John wrote a book on the history of AI going back. Right.

Phenomenal book, yep. Yeah. And at the end of the day, it is about pattern recognition- Mm-hmm ...

and learned behavior from that. Right. So, the people who say, "Well, AI's non-deterministic," well, your gen AI is.

Exactly. And the problem that we're facing these days is mostly a marketing problem. Yeah.

Or, a result of a marketing effort. Those gen AI models are dominating the discussion these days. Everyone's talking about them, everyone's using them, and it's almost like we're fighting an educational challenge of explaining to people this is not the only AI that exists.

I gave examples when I was speaking at BSides San Francisco last year about AI models that have been in use for years, that are being in use right now with every airline that flies above us. These are deterministic models- Every day ... every day, that prevents planes from crashing into each other and can actually resolve conflicts in the air automatically.

These are AI models. They're deterministic. They make planes not go boom in the air.

But you know I've read a little bit about those systems, and the interesting thing is they're not sort of zero sum. I tell you, the lunar module, right? If you ever read the story- Right ...

of that very first, Neil Armstrong. Had a human not been there- Right ... and we let the AI or, like- Correct ...

it would've aborted because it was too confined- Right ... into a set of parameters. Again, that's where the human and AI interaction really kicks in.

You can teach an AI to handle certain situations, but these are the situ-- Again, specifically when it's deterministic- Right ... these are the situations it can handle. And again, this is a great kind of leeway into how to move from IAC into more general code.

You do need a level of fuzziness, so to speak. Okay. Because deterministic only can go this far.

Right. Back to the lunar module. You teach it to land in a certain place.

Guess what? That place is no good. When something happened- Right ...

and that place is no longer relevant, it doesn't know how to solve that problem anymore. And that's where the human came in. By the way, the entire lunar module was in 64 KB.

I know. Okay? This is what you're dealing with.

You didn't have a gig or a- Oh, yeah ... terabyte card. 64 KB, but it made those deterministic- Calculations and decisions, and yeah, everything was programmatic and it could- What was the best thing to do?

self-correct itself to, again, to a set of known parameters and framing. But once you go outside of that, that's where the human kicked in. And again, that's what we're doing today.

So back to our discussion. Right. We had a deterministic model that worked for IAC.

That's easy. You can frame the conversation, so to speak. You can frame the parameters of how to solve infrastructure issues fairly easily using a deterministic model.

Now the question, what happens when you expand that to a more general language like Java or Python or Rust? And that's where the fuzziness kind of comes in. So, the big surprise, or not so big surprise, you cannot just solve it with a deterministic model.

You need to introduce a human-ish kind of understanding and contextualization because the language can get a little fuzzier, and that was our latest kind of advancement- Really ... where we introduced an agentic flow that combines generative AI, LLMs, and our deterministic models. Uh-huh.

And that loop essentially can, if trying to simplify it, the non-deterministic model can frame the conversation, can frame the discussion, and understand, "All right, I've got a problem here. " It doesn't try to solve it by itself because, as we all know, non-deterministic models produce non-deterministic results. Mm-hmm.

So if you run the same problem with that model twice, you're going to get two different answers. " That's not a great- That's not- Again, that's not an engineering acceptable solution. No, that's conflict.

Exactly. That's not confidence inducing. So what we did is combine that with a deterministic model.

Essentially, we stopped the non-deterministic engine at some point and told it, "All right. " So we're achieving two things here. One is consistent, repeatable, accurate results.

Mm-hmm. And two, way, way less token spend. Yeah.

Which is- Which is, that's the topic of the day. Exactly. So let me just, I want to make sure the audience is clear.

So we move from infrastructure as code to other kinds of code. Correct. Yep.

What other kinds of code are you supporting these days? You name it. We're currently supporting over 40 languages.

Really? Hey. Including, again, the most common one, Java, Python, Rust, JavaScript, TypeScript code.

That kind of stuff. The expansion there is fairly easy. And the key is that we don't really have to write the rules.

We don't have to write the policies. These can be written ad hoc throughout that agentic loop. So even for problems that we don't have a policy or a rule base to address, we can just show the agent, the agentic flow, the result of a finding, of an alert, of a report, or whatever it is- It is going to contextualize it and ad hoc create a policy, a playbook, on how to address it using a deterministic model, and from that point on, every time we'll run into that same problem, we will have a playbook to deterministically solve that.

Just insert one time and that's it. Exactly. Ian, in our audience out here, who should be paying attention here?

Who should be going to check this out? So obviously, platform engineers. They're the ones that are getting kind of the brunt of the tickets, the request for resolution.

But I would say it's also everyone in that spectrum between platform engineers and security engineers, security people. We don't want to be the department of no. Okay.

We've talked about that, and I'm still talking as a security practitioner because you can't- You can't leave it behind ... get that out of me. Yeah.

Yeah. Security has to be involved in the process. They can't just own the detection.

And- And it can't be involved by saying, "No, you can't do that" either, though. Exactly. Exactly.

And throwing tickets over the fence and throwing kind of, "Hey, here's a best practice," doesn't help. Right. You've got to be part of the solution.

And we're seeing, by the way, we're seeing in a lot of organizations, the lines between security and operations are getting blurry, and in a lot of organizations, they're actually being consolidated into a single department, especially now with AI making everyone a developer. Right. Right?

Making everyone a- A builder ... mini security expert. Those forces are kind of combining, so both sides.

And we have customers that the security department bought the solution and introduced it to DevOps, to platform engineering. We've got our customers where it kind of grew from the op side who said, "Look, this is going to save us a lot of time, a lot of money, a lot of our efforts so we don't have to dig through documentation- Yeah ... " So let me ask you as a business person.

Right. You're a CEO now. I've done a couple of companies.

Does that make it harder for you? Right? Yes.

Who's my persona? Who's my customer? It is.

It is. It is. How am I entering this organization?

Am I coming through the front door? Am I climbing through the window? Am I parachuting down the chimney?

Right. Look, I'm a former red teamer, so it's all of the above. You know all of them, yeah.

And so, the approach is basically identify in the organization who cares most about this. " Sometimes that's the door. That's the front door.

Today it is. Today it is. Tomorrow it might be something else.

" Yeah. It's an evolution of organizations understanding where the pain points are. And we've had customers that came to us from a AI kind of optimization perspective.

They're looking for AI solutions to augment their workforce. And after a few kind of unsuccessful attempts, they came to us like, "You claim to solve this. " And then they bought the solution.

So yeah, it makes it harder to identify. There's the old rules of, "Oh, I'm selling an antivirus. " These are gone.

Those are done. These are gone. So you have to identify- Yeah.

Today's world ... each organization, who's responsible, who's got the leverage, who owns the pain, and go for them. Well, it's funny, the last interview I was doing, that was one of the things.

The gentleman was a CTO, and we had this discussion. You don't shop for a solution till you know you got the problem- Right ... the pain.

You got to feel the pain. Exactly. Yeah.

" Right. " Right? Yeah.

Who could use this? Are you feeling the pain? Right.

Yeah. And I think that, again, that's part of product fit. It's part of the whole process of startups and running companies.

Yeah. Ian, I want to thank you for coming on. No, absolutely.

Thank you for having me. ai. ai.

There's a community edition you can download for free, use for free. It doesn't cost us almost anything because, again, we're not even spending your tokens. Right.

The only advantage is that you're going to cut your token spend, especially when you're addressing issues that you already have in your environment. So feel free to take it for a run, and if you like it, we can talk more. Raise your hand if you're concerned about token maxing.

All right. Ian, always a pleasure. Thank you, Alan.

Pleasure. We're going to take a break. We're here at Platform Con.

We're coming back to you with more.