Podcast: SafeBreach × Anvilogic—From Found to Fixed: Gaps to Live Detections

# The Cyber Resilience Brief ## SafeBreach × Anvilogic: Closing the Loop Between Validation and Detection Engineering *A SafeBreach podcast* **Host:** Tova Dvorin (SafeBreach) **Guests:** – **Koby Bar** — Senior Vice President of Product, SafeBreach – **Mackenzie Kyle** — Chief Product Officer, Anvilogic **In this episode:** SafeBreach and Anvilogic discuss how their integration turns simulated attacks that evade security controls into deployed, continuously validated detections. SafeBreach owns the *validation* step of exposure management; Anvilogic owns *mobilization / remediation* through agentic detection engineering. Topics include the five steps of exposure management (scoping, discovery, prioritization, validation, mobilization), SafeBreach Helm, Anvilogic’s detection “blueprints,” continuous validation, and detection engineering backlogs. — **Tova Dvorin:** Welcome back to The Cyber Resilience Brief, a SafeBreach podcast. Today we have a special episode featuring SafeBreach’s own Senior Vice President of Product, Koby Bar, and the Chief Product Officer of Anvilogic, Mackenzie Kyle. Koby, Mackenzie — we’re happy to have you. **Koby Bar:** Thank you, Tova. **Mackenzie Kyle:** Thanks for having me. **Tova Dvorin:** Tell our audience a little about yourselves, and then we’ll get started on what we’re doing together in detection engineering and validation. Who wants to go first? **Koby Bar:** I’ll kick off. I’m Koby Bar, SVP of Product at SafeBreach — about four years with the company. I come from a background in email security and have been doing product management for the past sixteen years. I’m happy to be here to share what we’ve been building. **Mackenzie Kyle:** Thanks for having me on. I’m Mackenzie Kyle, Chief Product Officer at Anvilogic. I’ve been with Anvilogic since the beginning — around 2019 now — so it’s been a while. Before that, I ran the Security Operations Center for a large financial institution for a number of years, so I come from more of a practitioner background. I moved into product and then into building agentic workflows for security operations in the SOC. It’s been a lot of fun. **Tova Dvorin:** So we have two product and cybersecurity experts in the house. When we talk about exposure management, we like to think about it in five steps: scoping, discovery, prioritization, validation, and mobilization. SafeBreach handles the validation side, and Anvilogic generally handles the mobilization, or remediation, side. We’ll mostly have Koby answer first and then get Mackenzie’s take, following that natural order — validation is step four, mobilization is step five. Sound good? **Mackenzie Kyle:** Sounds good. **Tova Dvorin:** Koby, from your seat: what’s the customer problem that made SafeBreach’s partnership with Anvilogic worth doing, rather than just another integration checkbox? **Koby Bar:** Great question. The problem isn’t that teams don’t know where the gaps are — plenty of tools will hand you a list of gaps. The problem is what happens next. Validation and remediation live in two different worlds. We’d run a simulation, prove that an attacker behavior slipped through your controls, and then that finding goes into a backlog and dies. It happens in a lot of organizations, because turning it into a deployed detection is slow and usually requires a senior engineer in the loop. What made this worth doing is that it closes that loop. A simulated attack that evades your controls becomes a deployed, tuned detection in your own environment, and then we rerun the same attack to prove it fires. The gap goes from found to closed and verified. **Tova Dvorin:** Mackenzie, same question from your side — what made SafeBreach the right validation partner for Anvilogic specifically? **Mackenzie Kyle:** It’s a perfect fit, in my opinion, because we sit on two different sides of the process, and it’s somewhat of a sequence, like Koby was saying. When you run a lot of validation and you’re finding detection gaps — or gaps in your environment in general — it’s one thing to identify them. It’s another to build those detections, test them, deploy them, maintain them, version-control them, and handle everything downstream that makes sure your gaps are actually covered by a detection control. So it fits nicely: as validation simulations run, gaps are identified, and that information can be passed to our agentic capabilities to help fill the actual control gaps on the detection side. That helps organizations improve mean time to detect and their ability to maintain detections. And once you have detections running, continuously validating them is a whole other problem — which SafeBreach is great at solving. It gives analysts confidence not just that they deployed a detection and filled the gap, but that a week or a month later it’s still working as expected. There were so many times in the SOC where we had rules we thought were deployed, the red team did something, and we realized we didn’t actually have it covered — either someone changed the rule and broke it, or a feed changed downstream and broke it. So continuous validation even after the detection is running is awesome, and that’s why it’s such a good fit. **Tova Dvorin:** That makes sense. It sounds like when you have large or even medium-sized enterprises, you have so many tools in your stack that you have to understand what actually works — and you’re working together to do that for detection engineering. Can you walk me through what actually happens in this integration? Koby, what happens when a SafeBreach simulation finds a gap and it flows into Anvilogic? **Koby Bar:** I’ll start with our side of the flow. We execute a real attack behavior — say, lateral movement or an infostealer technique — safely in your production environment. That’s SafeBreach’s bread and butter. When it evades detection, we don’t just hand you a MITRE ID and wish you luck. We know exactly what ran on which host and what it left in the logs. That fidelity is the whole point. We’re not guessing at what the detection should look for; we hand over the actual artifacts of what got through, so the detection is built against the evidence, not a hunch. That last step is where Anvilogic really shines — I’ll hand it to you, Mackenzie. **Mackenzie Kyle:** That’s a perfect segue into what a detection engineer needs to build a detection. Oftentimes they’re reading articles on the internet and don’t have the log evidence — the things you really need to build and test a detection. Once that kicks off on the SafeBreach side, the test results come in, the misses occur, and all that information is packaged and sent to Anvilogic. We have what we call a blueprint inside our product — a multi-step agentic workflow that reviews those detection misses, proposes a design for a new detection, builds it, lets an analyst test it, and then deploys it into production. Organizations can run this in full agentic mode without a human in the loop, or they can decide where to place review steps before anything gets deployed. Getting the actual log evidence of what the simulations did is very hard to get just by Googling, so that’s a key piece of why this works so well. **Tova Dvorin:** So it’s not just SafeBreach validating the detection on the first run, sending it to you, and then revalidating in a continuous loop — it’s also putting guardrails in place. That’s key right now for enterprise customers with AI: they can decide how much automation they actually want. People often say AI is like a dial rather than a switch — they want granular control — and it sounds like Anvilogic is going in that direction. **Mackenzie Kyle:** For sure. A big thing for us from very early on is flexibility for our customers. We produce agentic workflows that serve as sensible defaults, but we let organizations edit them and build their own, because everyone has a slightly different process — especially large organizations. We want to adapt to those processes. **Tova Dvorin:** That makes sense. Let’s talk about the value. Can you give an estimate of how much time and effort this integration saves a customer using both products? I know it’s early stage, but if you have numbers, we’d love to hear them. **Koby Bar:** Typically, deploying detection engineering without this integration takes days to weeks, with all the process involved — identifying the gap, having the logs we mentioned, and so on. This takes it down to seconds or minutes. That’s the difference in terms of saving time and the ability to deploy detections at scale and validate them continuously. It saves time on the entire workflow: defining which detections are relevant, deploying them, creating the rule in the SIEM, and then continuously testing them. That’s priceless — a real game changer for detection engineering. **Mackenzie Kyle:** You said it perfectly, Koby. The backlog of detection tickets that detection engineering teams have to work through is usually significant. Being able to keep up — deploying new detections based on real evidence in your environment in minutes versus days or weeks — is key, and it alleviates a lot of the pain teams have with those backlogs. **Koby Bar:** Absolutely. **Tova Dvorin:** Let’s zoom out. Koby, where does SafeBreach Helm fit into this? We’ve talked a lot about blueprints and the agentic AI on the Anvilogic side. You and I have talked off mic about how this might let a team of two do what a team of two hundred used to do. What can a mid-tier analyst do now that used to need a senior detection engineer — or five? **Koby Bar:** I’m glad you’re asking. Helm is our new shiny object. A few words on it first: Helm is our AI infrastructure layer over the CTEM platform. It has three agents behind a plain-English interface — the analysis agent, which ranks exposures by looking at real-world risk; the validation agent, which proves which exposures are actually exploitable by running real attacks; and the SecOps agent, which turns that into an actual fix. Turning a valid gap into a detection used to need a senior engineer at every step — knowing which gaps matter, proving they’re real, deciding the fix, then writing and tuning the rule. That took days to weeks. Helm collapses those first three steps into a conversation: a mid-tier analyst just asks a question and gets a prioritized, proven answer. Then Anvilogic handles the last step — the SecOps agent knows how to tell Anvilogic that this detection needs to be deployed. So it’s a game changer in your ability to analyze the data, understand which simulations are relevant, and close the loop with the SecOps agent and Anvilogic. **Tova Dvorin:** Makes sense. Mackenzie, from the Anvilogic side, what’s the hardest part of detection engineering today that this may or may not fully solve yet? **Mackenzie Kyle:** The hardest part of detection engineering is keeping up — not just with the threat landscape, but with the business landscape. Organizations are constantly evolving. Ten or fifteen years ago when I was doing detection engineering, I was looking at mainframe logs and operating systems that don’t exist anymore. Now everything is cloud-native — there are pods, Kubernetes, this vast landscape of infrastructure — and that’s very hard for people to keep up with and learn. So as validation tools identify these threats, the more specific information someone can get on where the threat is, how to detect it in the future, and how to document it so the next analyst understands it, the better. Having the log evidence Koby’s been talking about — making it easy for someone to know what bad looks like — is super important, not just for detection engineers building the detection right, but also on the triage side, so that when someone sees an alert it’s actually what the rule was intended to detect. It has to be extremely difficult for detection engineers now — and for triage and response teams — to keep up as the business landscape evolves at an even faster pace than the threat landscape in some cases, just in terms of the technologies being used and how people run critical applications. That’s the hardest part we’ve seen across our customer base. **Tova Dvorin:** We’re recording this a couple of weeks ahead of Black Hat, which we’re all excited about — we’ll be talking about this together there. If a CISO approaches either of you at Black Hat about this partnership, what’s one question they should ask to get proof this is real and not just more AI marketing hype? **Koby Bar:** I’ll take this first, and I’ll assume the CISO is a SafeBreach customer. I’d ask: of the detections SafeBreach validated over the last month, how many were actually closed with a deployed detection that then gets validated? We have clients running millions of simulations — every year, every week — using SafeBreach, and the question is how many actually turn into validation rules. Then I’d ask, after using this integration, how much faster it was compared to before. So it’s a question of volume but also quality, because revalidation is a very key aspect of this integration. **Tova Dvorin:** Makes sense. Mackenzie, anything to add? **Mackenzie Kyle:** I’m going to steal Koby’s answer — that’s what I’d ask too. If you’re running a lot of attack simulations and they’re producing valuable information about where you have control gaps, and those gaps just get put into a backlog of detections that either take a long time to build or don’t get done at all, that’s risk you’re just letting sit there. And once you have detections deployed, you can ask: how often are they actually validated? That’s a significant problem even after detections are running — making sure they still work. People spend a lot of money on detections and detection engineering, and there are a lot of signals being generated, so it’s hard for analysts to tie it all together. SafeBreach does a great job of giving you valid, evidence-backed information on where the gaps are, and then you need to turn that into something usable for the detection controls at the organization. **Koby Bar:** Couldn’t agree more. **Tova Dvorin:** Is there anything you two ever disagree on? Because this is downright suspicious, in the best way. **Mackenzie Kyle:** Not in this space, apparently. **Koby Bar:** No, it’s a true better-together story. There’s a lot of collaboration in the cyber world, but not much of it is really meaningful to the day-to-day. This one delivers real value, and it was driven by the mutual clients we share — they asked for it. So it wasn’t a partnership built on anything other than the real value clients were asking for. Sometimes it’s just a match made in heaven. **Mackenzie Kyle:** Exactly. **Tova Dvorin:** To wrap up: say someone’s listening the week before Black Hat, or during Black Hat, or they’re just looking for a detection engineering and validation solution. What’s one thing you’d tell a CISO, red teamer, or SOC team to go check in their environment this week? **Mackenzie Kyle:** I’ll take a stab and you can build off it, Koby. The one thing I’d encourage folks to look at: when you look at your entire estate — especially in large organizations, where you might have hundreds of thousands or millions of endpoints — it’s very difficult to protect all of them with the same rigor. So my recommendation is to scope your environment in a way where you understand your critical business processes, and build very solid detection plans around those critical assets. Instead of covering the entire estate with the same rigor, focus on the areas most important to the business and do a lot of threat hunting, detection engineering, and validation there, so those are protected with more fidelity than the rest of the organization. Threat hunting and detection engineering on critical infrastructure is an area I always liked to explore back when I was a practitioner. **Koby Bar:** Thank you, Mackenzie — that got my creative juices going. I’d say that even in mature stacks, the behaviors that routinely slip through are identity abuse, lateral movement, AI-driven infostealing, and so on. This week, pick one you’re confident you’d catch, and actually run it against your controls instead of just auditing your rule list. There’s a tendency for detection engineers to go over the list and get peace of mind, but almost every team finds at least one they thought they had covered and didn’t. So don’t check whether the rule exists — check whether anything fires when you actually run the attack. That’s the big difference. Don’t just audit your rule list; see it in practice. **Tova Dvorin:** Important takeaways. Thank you both so much for your time, Koby and Mackenzie. Listeners, if you’ll be on the floor at Black Hat, find us at our booths — I’ll drop them in the show notes. Until next time: stay safe with SafeBreach. **Koby Bar:** Thanks. **Mackenzie Kyle:** Thank you. Bye.