I Built the Detection Era at Splunk. Here’s What I’d Build Now.

By Doug Merritt, CEO and Chairman, Aviatrix [ Join Cybersecurity Insiders ]

If you lead security at a cloud-first enterprise reading this, I want to be useful to you in the next ten minutes. Not theoretical. Useful.

I ran Splunk from 2015 to 2022. I am personally responsible for selling more detection-era infrastructure into the Fortune 500 than I would like to admit. I am writing this column because the math has changed, and the marginal dollar in your 2026 security budget should not go to faster detection.

Here is the case, the data, and the action list.

Three numbers for your CFO conversation

Eighty-two percent. The share of 2026 intrusions that ride valid credentials through legitimate channels. No malware signature, no anomalous lateral movement, no scanner finding. A real account with real permissions, used by someone who is not supposed to be using it. There is no detection product that can reliably distinguish a phished employee from the actual employee in real time.

A median time-to-exploit that has gone negative. Down from 771 days in 2018, attackers are now operationalizing flaws roughly a week before the CVE is published. You are racing a clock that has already finished counting.

6.5x effort, worse results. Across more than 10,000 organizations and 1.1 billion remediation records, teams that increased their patching effort by 6.5x saw the share of critical vulnerabilities unresolved at seven days rise from 56 percent to 63 percent. More bodies and more tools made the patching pipeline worse. This is not a budget problem. It is structural.

Take those three numbers into a budget meeting, and the obvious next question is “so where should the money go?” That is the rest of this column.

What the recent supply-chain attacks should be telling you

Three industrialized supply-chain attacks in the last sixty days ran the same playbook. LiteLLM in March exfiltrated AI/ML toolchain credentials through a legitimate gateway package. PyTorch Lightning and intercom-client at the end of April were live for 42 minutes, all the time they needed. TanStack and more than 170 npm and PyPI packages in May shipped 404 malicious versions in six minutes, carrying valid SLSA provenance from legitimate GitHub Actions runners.

In every case the pattern was identical. A legitimate package. A trusted channel. An unbounded reach inside the victim. None of those attacks failed because of an inadequate detection layer. They succeeded because nothing inside the victim environment bounded what a compromised workload could do once it was running.

That is the gap your architecture has to close in 2026. Not detection speed. Reach.

Reframe the metric

I spent close to a decade selling the value of time-to-detect and time-to-respond. Those are the right metrics when the exploit window is years long. With the window now negative, those numbers tell you something useful only after the fact.

Blast radius is the metric that decides outcomes now. How much can the attacker reach with a stolen credential? How much can the workload send out before anyone notices?

Practically, that means moving the enforcement point. The detection era put it in a central plane. The Containment Era puts it on every individual workload. Each workload carries its own policy for what it can reach and what it can send out. If it is compromised, the radius is already set by the architecture.

In March, a Fortune 500 customer stopped a live supply-chain exfiltration from thousands of compromised pods with no human in the response loop. The detection layer watched it happen. The detection layer was not what stopped it. The architecture had.

Three questions for Monday morning

If your team cannot answer these with confidence, your 2026 architecture has a gap.

Does enforcement govern every workload path, including Kubernetes pods and east-west traffic? Most environments enforce at the perimeter and a few chokepoints. If lateral and outbound paths are not governed at the workload, the blast radius is whatever the attacker decides it is.

If a workload were compromised right now, would your architecture stop the exfiltration, or would you find a log of it tomorrow? Phrase it exactly that way. The answer tells you which era your environment is actually in.

Is your containment architecture independent of your detection stack? If the answer is no, you have a single point of failure dressed up as defense in depth.

What I would actually do

If I were the CISO of a cloud-first Fortune 500 today, here is what would be on the plan this quarter.

Keep patching. Keep detecting. They are hygiene. Stop expecting either to scale to the threat. Build a containment layer that bounds the blast radius of every workload before the next supply-chain compromise lands in your environment. Measure your defensive posture by reach, not by mean time to detect.

The honest line I would say in any room: when prevention fails and detection arrives too late, your architecture is what decides whether you have an incident or a breach. That is the call security leaders are being asked to make in 2026, and I would rather be the one telling you the truth about it than the one trying to sell you something else.

_____

Doug Merritt is Chairman, CEO, and President of Aviatrix. He previously led Splunk as President and CEO from 2015 to 2022.

Join our LinkedIn group Information Security Community!

No posts to display