Exploits and malware are still subject to the laws of physics

Why AI-powered vulnerability discovery and software exploitation don’t change the fundamentals of durable defense.

AI is going to make it faster and easier to find vulnerabilities and exploit them. Many advanced models including Claude Mythos, trained on code, CVEs, and exploitation tradecraft, will compress the time between vulnerability discovery and weaponization. This is real, and it deserves serious attention. But before we catastrophize, we should anchor to a few stubborn truths.

We’ve always had more malware than detection logic

Signature-based detection was always a losing race. Malware variants and malicious artifacts have outnumbered signatures for as long as both have existed. Behavioral detection improved the math considerably, and for organizations that invest in depth of coverage, it casts a net that most adversaries, human or AI-driven, will struggle to avoid. Still, the gap between what adversaries produce and what defenders detect has always been nonzero. AI widens this gap by lowering the cost for adversaries to scale the production side of the equation, but AI doesn’t fundamentally change its structure.

All software is subject to the laws of physics. An exploit has to be delivered, and if it lands, it has to be followed by more moves. Every one of those moves takes place on hardware, makes system calls, and touches memory, disk, or the network in ways that are observable. An exploit may subvert a given control or suppress an expected behavior at a given stage of the attack chain, but it doesn’t exempt the target system from the constraints, controls, and observability built into the environment.

An exploit unlocks a door, but even chained exploits orchestrated by AI agents are not a skeleton key.

What defenders who are winning actually do

The organizations that are well-positioned today didn’t get there by chasing every new threat category. They got there by making sound architectural decisions and disciplined operational choices:

Minimize attack surface first. Rather than trying to defend everything equally, force activity through a small number of well-understood, well-defended, carefully monitored pathways. This isn’t glamorous, but it is foundational.

Implement zero trust and segmentation principles throughout. Require a combination of device and identity trust as a prerequisite for transactions, enforced at as many layers as practical. An adversary who gains a foothold still has to make moves—segmentation and conditional access make movement impossible, or at minimum, noisy and observable.

Use deception to backstop other defensive controls. Honeytokens, decoy assets, and deceptive infrastructure have two defining characteristics: legitimate users don’t trigger them, and they are exceptionally inexpensive to deploy. Any interaction is, by definition, suspicious. In a world of high alert volume and limited analyst time, that kind of signal is invaluable.

Apply intelligence-led, behavior-based detection and response. The set of adversary techniques that appear in the majority of real-world intrusions is not large. From Red Canary’s 2026 Threat Detection Report:

[O]ver the last five years, we’ve detected at least one of the 10 most prevalent techniques in 46 percent of all detections. Over the same time period, we detected at least one of the top 20 techniques in 63 percent of detections.

The defenders who are winning have optimized for the set of prevalent techniques that almost all adversaries use, building detection coverage against it, investing in rapid investigation workflows, and standing up response capabilities that can act decisively when a threat is confirmed.

The volume problem is real, but also solvable

Attack volume will increase. There is no serious argument against that. More actors with access to more capable tools will generate more exploits and malware variants, more intrusion attempts, more noise.

Defenders who are well-positioned today will still be well-positioned tomorrow. Not because nothing is changing, but because the principles that make a defense durable—attack surface reduction, zero trust principles, high-fidelity signals, and behavioral detection—become considerably more important in the face of increased adversary volume, speed, and efficacy.

The clock has gotten faster. Time-to-detect, time-to-investigate, and time-to-respond all need to come down. AI agents and emerging automation are well suited for exactly this: triage, investigation acceleration, and response orchestration are tractable problems, and the tools are improving quickly.

The question isn’t whether AI changes the threat. It does. The question is whether it changes the fundamental structure of the problem for defenders who are doing the right things. And I don’t believe it does.

Introducing Atomic Scorecard: A test tracking tool for ATT&CK + Atomic Red Team

If you haven’t tested it, it doesn’t work. This foundational thesis drove the creation of Atomic Red Team and the concept of atomic testing for cybersecurity teams. One key lesson from its adoption: testing is more like exercise than an exam. Small, regular tests pay far larger dividends than annual or “big bang” red team engagements.

To encourage ongoing testing, I’ve long maintained a crude spreadsheet for tracking, scoring, and measuring test outcomes. I’ve now converted it into a web-based tool.

What is it?

At its core, Atomic Scorecard is a simple system of record for atomic tests. Like Atomic Red Team, it uses MITRE ATT&CK as the foundation, but it overlays industry threat intelligence, and naturally makes it easy to find atomic tests relevant to each technique.

No account is needed. There’s no database or other backend. None of your test data is stored.

Intelligence-driven prioritization

The most common ATT&CK hangup is that it’s expansive and hard to know where to start. Few organizations have enough threat intelligence to know which techniques matter most. And even then, prevalence data is more reliable than first-party intel alone. Not all techniques are created equal, and from Red Canary’s 2026 Threat Detection Report:

[A] relatively small number of techniques play a role in a disproportionately large number of detections . . . [O]ver the last five years, we’ve detected at least one of the 10 most prevalent techniques in 46 percent of all detections. Over the same time period, we detected at least one of the top 20 techniques in 63 percent of detections.

By default, the tool’s technique rankings are drawn from Red Canary’s annual report, observed across thousands of companies of every size and industry. Also included are Mandiant’s top techniques, sub-techniques, and a complete M-Trends ATT&CK appendix by tactic:

• Red Canary 2026 Threat Detection Report (default)
• Mandiant M-Trends 2026 Top Techniques
• Mandiant M-Trends 2026 Top Sub-Techniques
• Mandiant M-Trends 2026 Complete ATT&CK appendix (top techniques and sub-techniques for every ATT&CK tactic)

You can also upload custom rankings to reflect your organization’s specific threat landscape.

Integration of ATT&CK + Atomic Red Team

The tool is built to move you from documentation to execution in seconds:

• Every technique is linked directly to the official MITRE ATT&CK documentation
• For any technique where an Atomic Red Team test exists, a clickable logo appears that takes you directly to tests that correspond to that technique

I recommend using the Invoke-AtomicRedTeam framework, which makes test selection, execution, and optionally things like prerequisites and cleanup fast and easy.

Tracking and reporting

Testing is less impactful if you don’t record and measure the results. For every technique that you test, you can categorize test outcomes into one of four states:

• Missed: The attack went completely unnoticed.
• Observed: You saw the telemetry, but no alert was triggered.
• Detected: You were alerted to the activity.
• Mitigated: The attack was blocked or interdicted by existing controls.

You can also add notes related to a given technique, since a simple status may not capture important context, or mark a technique as not applicable to your environment.

A simple dashboard at the top makes it easy to see your test coverage and outcomes.

Flexibility and customization

To ensure this tool stays relevant as ATT&CK, Atomic Red Team, and your priorities evolve, the Maintainer tools allow you to update or customize:

• ATT&CK version
• Atomic Red Team coverage
• Technique ranking

There’s also a simple JSON-based backup and restore capability. Export your entire project as a JSON structure at any time. When you’re ready to resume, just import the file and pick up exactly where you left off.

Share your feedback

If there’s something you’d like to see that isn’t included, something isn’t working, or if you’d just like to send some feedback, you can reach me via email: kwm @ this domain.

Ready to start testing? Give it a go at https://atomicscorecard.com

Customer discovery questions (or, better alternatives to “What keeps you up at night?”)

Whether you’re a founder, in sales, an account manager, or in almost any other customer-facing role, the most valuable thing you can do is ask your customers questions, and learn what their goals, incentives, and measures look like.

This is a short list of questions I’ve found lead to substantive discussion (these are geared toward cybersecurity teams, but most are broadly applicable):

Q: How is your team measured?

What I’m listening for:

• Objectives, ideally those that roll up and support the broader organization
• Cybersecurity maturity models or frameworks (NIST CSF, CMMC, C2M2, etc.)
• Compliance audits or certifications (SOC 2, ISO 27001, FedRAMP, etc.)
• Risk measures, commonly specific to realized risks (exposure or vulnerability management, third-party risk, etc.)
• Incident measures related to detection, investigation, containment, and response
• Other basic operational measures, like tickets or cases

Q: Where do your incidents come from?

This is a simple question, but sometimes it lands. If it’s helpful to follow with some elaboration, consider:

• Q: What controls are most useful in helping you identify higher severity incidents?
• Q: What data or tools do you find most useful for investigation? Response?

These can lead to useful insights related to control effectiveness, operational maturity, and incident management. A good organization can tell you how many incidents they have; a great team can speak to trends related to root cause, severity, cost, mean time to detect/respond, and more. Teams that are exceptional at incident management will use incidents as a key lever for driving continuous improvement and change.

Q: What does your roadmap look like for the coming months or year?

Here I’m listening for initiatives that:

• Align with what we do today, where we can satisfy the requirement or meaningfully accelerate progress
• Are on our roadmap, as this helps with prioritization, and reinforces that we have some shared vision
• Include tooling consolidation or platform migrations, which can indicate a natural entry point, or a risk if the consolidation cuts you out
• Aren’t on our radar at all, particularly those that factor into competitive losses

Q: If you could add a single skillset to your team today, what would it be? If you could add an entire team, what would you have them do?

What do they know they want? Usually, they’ll frame it around a specific, acute problem they can’t solve or solution they can’t build in-house.

Note: There’s a subtle but important difference between this type of question and “What causes you to lose sleep?” When asked about fears, a mature team will probably name a specific threat or risk. You can then explain how your product addresses it and hope they connect the dots — but unless that fear is your primary point of value, you’ve gone down a rabbit hole and likely missed the broader product story.