Why Machine-Speed Development Needs Machine-Speed Security Decisions
When Code Installs Itself, Trust Decisions Have to Move Upstream
CodeHunter CEO Ken Ammon has a new piece in the Forbes Technology Council, “Supply Chain Attacks Are Forcing Threat Detection To Focus On What Code Can Do.” His argument: the way most enterprises decide whether software should run was built for a slower world, and automated development has left it behind.
The trust model changed underneath us
Ken opens with the structural weakness the Shai-Hulud 2.0 supply chain attacks exposed. Attackers did not need a phishing email or a developer willing to run something manually. They compromised trusted packages so malicious code executed automatically during dependency installation. The delivery mechanism was the normal development workflow itself.
That matters because of how much of that workflow no longer involves a human. Autonomous coding assistants and agentic development tools now download, resolve, and execute dependencies in seconds. Code moves through pipelines, third-party packages are imported automatically, and containers deploy across cloud infrastructure at machine speed. Software can be installed and running before anyone has looked at it.
Prior observation is too slow a filter
Traditional controls like signature detection and reputation scoring depend on having seen a threat before. By the time a malicious artifact is identified and cataloged, automated systems may already have pulled the dependency, executed the loader, and exposed API tokens or cloud access keys. As Ken puts it, machine-speed development workflows are colliding with human-speed security processes.
Enterprise security has historically invested far more in observing suspicious behavior after execution than in deciding whether untrusted code should execute at all. When alerts arrive after the fact, they explain damage rather than prevent it.
Evaluating what code can do, before it does it
The piece makes the case for behavioral intent analysis as the practical way to move the decision upstream. Instead of asking whether code resembles known malware, intent analysis examines what an artifact is capable of doing: its execution paths, system interactions, privilege use, network communication, and persistence behavior. Those behaviors get evaluated against security policy before the code runs.
Ken maps out where those decision points belong: development pipelines where build artifacts are generated, CI/CD systems, artifact repositories and package ingestion points where third-party software enters the environment, and runtime environments where executables launch. At each stage, the surfaced behaviors drive a deterministic policy decision the system can enforce automatically: allow, block, quarantine, or require review. The same artifact evaluated under the same policy produces the same outcome, which is what governance, compliance, and audit work actually require.
The operational payoff
This is Zero Trust for Code in practice: execution treated as a gated decision rather than an assumed outcome. And the piece is clear-eyed about what that does to security operations. When artifacts are evaluated before execution, many routine investigations disappear. Analysts spend less time triaging ambiguous alerts and more time on genuine threats. Late-discovery incidents, where malicious activity surfaces only after code has been running in production, become less common. In many cases delivery gets faster, because decisions that once required manual investigation happen automatically.
The question Ken leaves readers with is the right one for any organization running automated development workflows: not whether an artifact has been seen before, but whether its behavior should be trusted to run.
Read the full article on Forbes.
