Strategic commentary and perspectives from CodeHunter senior executive and thought leaders on cybersecurity, Zero Trust for Code, and the industry.

""

The Fourth Question in Software Supply Chain Security

/in , /by

Software supply chain security has matured fast. Most enterprises can now answer what is inside their software, where it came from, and how it was built far better than they could five years ago. SBOMs, code signing, and build provenance made that possible, and Executive Order 14028 pushed agencies, contractors, and enterprises to invest in all three.

In a new byline for Help Net Security, CodeHunter CEO Ken Ammon argues those three answers still leave the most important question open: what can this software do once it runs?

Composition is not behavior

An SBOM tells you the ingredients. It does not predict the meal. As Ken writes, a package can have a clean dependency tree and still attempt credential access, persistence, lateral movement, or data exfiltration. Context decides whether a behavior is routine or dangerous. File deletion is expected in a disk cleanup utility and alarming in an office macro. Credential access belongs in a password manager, not in a package dependency.

Signing and provenance run into the same limit. They verify who published the software and how it was built, which strengthens integrity, accountability, and auditability. They do not verify trustworthiness. Signed software can behave maliciously. A trusted vendor update can be compromised. An AI coding agent can generate code that works exactly as intended and still introduces consequences nobody authorized.

Most security programs still treat origin as the final trust decision. Ken’s argument is that origin is a reasonable first filter and a dangerous last word.

AI is forcing the timing question

The piece points to University of Toronto research demonstrating an AI-powered worm that adapts its attack strategy as it moves through a network, reasoning through new attack paths rather than exploiting a fixed vulnerability. When attackers can generate variants instantly, the observable surface of malicious code becomes unstable, and waiting for recognizable signatures or post-execution alerts to make trust decisions arrives too late.

The June 2026 AI executive order on cybersecurity reflects the same federal concern. The trust model built for slow-moving software does not hold when code is generated, modified, and deployed faster than human review can keep up.

From software identity to software behavior

Ken’s conclusion extends a principle security teams already know. Zero Trust rejected implicit trust in networks, devices, and identities. The same standard now needs to apply to software execution: no artifact should be trusted solely because of its origin, signature, or reputation.

That is the foundation of Zero Trust for Code. Supply chain controls remain essential, but the practical question changes from “do we recognize this?” to “is this behavior authorized?” Answering it means evaluating what an artifact is capable of doing, before execution, against enterprise policy, with evidence a security team can stand behind.

Read Ken’s full byline at Help Net Security: Why SBOMs, signing, and provenance still don’t tell you if software is safe

""

Why Machine-Speed Development Needs Machine-Speed Security Decisions

/in , , /by

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. 

CodeHunter Deterministic Trust Decisions – zero trust code enforcement

Applying Zero Trust to Software: The Gap Between Provenance and Permission

/in , /by

Zero Trust has reshaped how organizations think about access. No user is trusted by default and no device gets a free pass. Every request is verified before access is granted. It is a sound principle, and it stops short of software artifacts.

What Zero Trust currently misses

Zero Trust governs identity, network, and device posture. It does not govern what software does when it executes. An artifact that clears every origin check, signed, sourced from an approved repository, delivered through a trusted vendor, still runs without any evaluation of what it is capable of doing.

That is a gap the current model was not designed to close.

Origin is not authorization

As Ken Ammon argues in his Forbes piece, SBOMs tell you what is inside an artifact. Signing tells you who signed it. Provenance tells you how it was built. None of those answer whether it should be allowed to run.

Consider this: a security team receives a software update from a vendor they have worked with for years. The package is signed. The source is verified. The SBOM is accurate. The artifact also contains routines capable of establishing persistence and communicating with external infrastructure. Every provenance check passes. None of them surface the capability that matters.

Origin answered. Behavior never asked.

The pattern holds across the threat landscape

This is not a hypothetical. The Arch Linux AUR compromise and the WordPress CDN breach both followed the same structure: trusted source, legitimate delivery, malicious execution. In both cases, every origin check passed. In both cases, the behavior was never evaluated before the code ran.

We laid out what Zero Trust for Code actually requires in practice in Zero Trust for Code Starts With Understanding Intent. The supply chain keeps working as an attack vector because the trust model for software execution has not caught up to how attackers operate.

What changes when you evaluate before execution

Behavioral analysis before execution closes that gap. Control flow, dataflow, and system interactions are assessed before the artifact runs. The output is a deterministic verdict, Allow, Block, Restrict, Quarantine, or Require Review, with the evidence documented.

That is Zero Trust applied to software. Trust based on what an artifact will do, evaluated before it runs.

Ken Ammon makes the full argument in his Forbes article, “Security Has a Timing Problem, But Attackers Don’t.”

Read the full piece here

""

Signatures Don’t Stop What They’ve Never Seen

/in , /by

Signatures Don’t Stop What They’ve Never Seen

When every payload is unique, what does your audit trail actually prove?

AI-assisted tooling now generates malware variants on demand. Different code, different hash, same objective. Payloads are built for a single target and never reappear. There is no hash to check, no prior observation to match against, no pattern to recognize. The artifact clears every signature-based control by design.

The same limitation applies to zero-day threats. We broke down why behavior is the only detection method that holds up when signatures have nothing to match against in Zero-Day and Unknown Malware: Why Behavior Wins When Signatures Fail.

That is the technical problem. Here is the compliance problem that follows.

“We checked the signature” is getting harder to defend

When an auditor or regulator asks why an artifact was allowed to run, the answer needs to hold up. Frameworks like the SEC’s cybersecurity disclosure rules and DORA do not mandate specific tools. They require defensible decisions. A process record showing a confidence score below threshold explains what the tool returned. It does not explain what your organization understood about the artifact before it executed.

If the payload was designed to evade signature detection and succeeded, that record shows a control ran. It does not show the control worked. That is a harder position to hold in front of an assessor, and a harder one to hold personally as the CISO signing the disclosure.

What a defensible decision looks like

Behavioral evidence answers the question that pattern matching cannot. What was this artifact capable of doing? Was that evaluated before it ran? What policy was it measured against, and what was the verdict?

That is the documentation the audit conversation is looking for: a decision with the behavioral basis attached. For organizations managing SEC or DORA obligations, that evidence exists before it is needed, not reconstructed after the fact.

Ken Ammon makes the full technical case in his Forbes piece. If signature-based controls are part of your current stack, it is worth understanding exactly where they stop working.

Read the full article “Security Has a Timing Problem, But Attackers Don’t” .

Behavioral intent analysis mapping software code capability to identify risky execution paths before runtime

Why The Trust Decision Happens At The Wrong Moment

/in , /by

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.