Build vs. Buy Is the Wrong Question. Ask What Your Team Should Own.

I've worked vendor-side in security for a long time. For most of it, "we'll build that ourselves" was an objection you heard maybe twice a year.

I heard it constantly at Black Hat this year – from engineers, from CISOs, from researchers. And it makes sense. When you can prompt your way to a convincing prototype in a few weeks, building exactly what your environment needs feels within reach.

But a prototype isn't a detection program. The real question isn't build or buy. It's where your team's hours create the most security, and where they're going to work a good partner can do faster.

Every layer has a loop

Strip the vendor language away and a detection program is three layers, each running at its own speed.

Content: turning threat intelligence into hunts and detections. A report drops, a technique gets popular, someone has a hunch. That loop should run in hours, because adversaries do.

Ops: everything that makes content real. Testing, backtesting, deployment, tuning, retirement. That loop runs in weeks and never ends. Being wrong here costs analyst hours and, eventually, trust – the second a detection cries wolf three times, the SOC stops believing it.

Infrastructure: collection, normalization, the SIEM, the lake, and the eternal fight over ingest cost. That loop runs in quarters. Being wrong here costs real money.

The mistake is answering build-or-buy once for all three. Each layer needs its own answer.

Content: the gap is speed, not ideas

Your team doesn't lack ideas. It lacks hours. Every intel report is a potential hunt, and most teams get to a fraction of them. AI drafts help, but a draft is only the start – someone still has to map it to your schema, your tools and your environment. Multiply that by the volume of intel and "we'll build it" quietly becomes "we'll get to it."

This is where a platform built for intel-to-detection earns its place. It turns new threat intelligence into hunts and detections continuously, so your team reviews and decides instead of writing from scratch. Their job shifts from writing every line to deciding which lines ship. That's a promotion, not a demotion.

Ops: content is cheap, validation isn't

This is the part nobody plans for. Teams see how fast AI gets them to a draft and conclude they can build the whole program. Then the drafts pile up – untested, untuned, never run against the environment they're supposed to protect – and six months later there's a repo full of detections and no idea which ones work.

Testing a detection against real telemetry, knowing how noisy it'll be before you ship it, catching drift, retiring it when the technique dies – that's an engineering harness. It's the same capability at every company, just wired into your environment, and it's exactly what to look for in a partner. The bar: build, test and ship against live data, not a sample that's weeks stale because the pipeline lags.

Infrastructure: stop moving data

This is the pipelines, collection and storage everything else sits on. I know, I know. You have a guy. He's great. He's also the only one who understands the pipeline, and he's interviewing.

You've already paid for this layer, more than once. The smartest detection investments right now don't add another place to send your data. They work across what you already run: no new pipeline, no rip-and-replace, no new ingest bill. Your data layer is not where you win. Don't make it the thing your next tool depends on.

When code is cheap, you buy the team

Here's the part that changed my own thinking. If anyone can prompt their way to a working prototype, code alone isn't what makes a vendor valuable. So what are you actually paying for?

The people on the other end of the deal.

A detection misfires at 2am. A new log source breaks your parsing. A technique shows up that nothing in your stack covers yet. The code doesn't solve any of that. A team does – and because the ops loop never ends, you're not buying a product once. You're signing up for years of working with those people. What matters is how fast they understand your problem, how smart the fix is, and whether they show up when it's inconvenient.

So the partner is a buying criterion in its own right, not a checkbox at the end of procurement. Before you sign, find out:

• How fast do they move when something breaks in your environment, not the demo one?
• Are the people you talk to detection engineers, or a ticket queue?
• Will they tell you when their product is the wrong answer?
• Does what they learn from working with you come back to you?

Get good answers and the vendor stops being a line item. They become an extension of your team.

The rule

If I had to fit this on a whiteboard: own the judgment, partner for speed. The decision about what runs in production with your name on it stays with your team. Everything that slows that decision down – drafting, testing, wrangling data – is fair game for a partner who moves faster than you can build.

Where Mars Security fits

Fair disclosure: I advise Mars Security, and this is the problem they built for. Mars continuously converts threat intelligence into executable hunts and detections across your existing security stack. No data ingestion. No tool replacement. It hunts across your log sources, cloud and endpoints without moving a byte, deploys in hours, and lets your team build, test and ship detections against live data.

What that looks like on a normal Tuesday: a campaign report drops in the morning. Mars turns it into hunts across the tools you already run. Testing against your live telemetry turns up a backup job that looks exactly like the lateral movement in the report. Your team decides the exclusion is safe, ships the detection, and watches it for a week. Nobody touched the pipeline, and the judgment stayed yours.

Intel to detection in minutes, not months.

If your team is spending more time building machinery than making decisions, see how Mars works at marssec.ai.

Aaron Mog is an advisor to Mars Security.