Why The Trust Decision Happens At The Wrong Moment
Enterprise security has a foundational assumption that if we can recognize malicious software quickly enough, we can stop it.
The Detection Model Assumes Reuse
Signature-based and reputation-based systems need prior observation to function. They require an artifact to match something already catalogued: the same hash, the same behavioral fingerprint, the same infrastructure. Even modern behavioral detection frequently works by correlating runtime activity against known malicious techniques or previously observed campaigns.
When threats were reused across targets, that was a reasonable foundation. Today, automation frameworks generate polymorphic variants at scale. AI-assisted tooling rewrites control flow, repacks binaries, and changes string signatures in seconds. Payloads are built for a single target and never appear again.
The observable surface of malware, including hash, static indicators, and execution path, has become disposable. Known-bad is now a historical record, and history loses its value when every artifact is new.
The Window is Smaller than the Workflow
The second problem compounds the first. In many environments, lateral movement and data access can occur within minutes of initial execution. Automation has collapsed the gap between a foothold and meaningful impact.
Security workflows have not kept pace. Telemetry is collected. Alerts are generated. Analysts triage. Correlation happens. Containment follows. By the time a high-confidence alert reaches a SOC queue, the artifact has already run. Persistence may already be established. The window that detection was supposed to close had already closed before the workflow started.
This is the timing problem. Detection is working; however, it is positioned at the wrong moment.
Moving the Decision Upstream
The question that survives both problems is not “have we seen this before?”, it is “what is this code capable of doing if it runs?”
That question does not require a match against prior observation. It requires evaluating behavior before execution, including control flow, dataflow, and system interactions, and producing a verdict before the artifact runs rather than a record of what happened after it did.
As Ken Ammon explains, this is the logical extension of zero trust principles that most organizations already operate. Zero trust says do not extend trust based on origin or prior relationship. Verify before granting access. Applying that to software means no artifact is trusted because of where it came from or how it was built. It is evaluated on what it will do, and execution is granted or denied accordingly.
When the trust decision moves upstream of execution, prevention becomes part of the control model again. Detection and response stay in place. The first decision now happens where the risk is still assessable, before anything runs.
Read Ken Ammon’s full argument in his Forbes article: Security Has A Timing Problem, But Attackers Don’t.
