Insights

CodeHunter Behavioral Risk Brief cover for the GitSpawn AI agent flaw, September 2026

Behavioral Risk Brief: Malicious .git Configs

/in /by

the claim

Governance frameworks that treat workspace-trust prompts and sandboxing as sufficient protection create systemic risk when an agent’s own routine background operations bypass
both entirely. Zero Trust for Code addresses this by requiring a pre-execution trust decision on every command a repository can trigger, not only the ones a user’s approval prompt was designed to catch.

the incident

Manifold Security disclosed eight flaws across seven AI coding agents, including Claude Code, Cursor, Codex, and goose, where a repository’s own Git configuration file can name a command
that executes automatically when the agent performs an ordinary background operation, such as checking git status to determine the current branch. The command runs outside the agent’s
sandbox and without any approval prompt, in some cases before a workspace-trust dialog is accepted, before the user has authenticated, or on the first keystroke. Exploitation only requires
that a repository arrive with its .git directory intact, which happens through a shared archive, sync folder, or USB drive, though not through an ordinary clone. Fixes have shipped for goose,
Cursor, and one of the two flaws found in Claude Code, while Hermes Agent, Qwen Code, Grok Build, and a second, separate Claude Code path remained exploitable at the time of publication.

the governance failure

The governance failure is not that a malicious repository could be crafted, but that the execution point defeating every safeguard was a routine, background action the agent performs for its own housekeeping, rather than a step a user or a trust prompt was ever positioned to review. Workspace-trust dialogs and sandboxing exist specifically to gate what an agent does with a new repository, and this class of flaw runs before either applies.

This is compounded by how ordinary the triggering behavior is. Checking which branch an agent is on or which files changed is not a suspicious or unusual action, it happens automatically, every session, without a developer ever noticing. A control built around scrutinizing deliberate or unusual agent behavior has nothing to flag here, because nothing about the triggering action looks any different from a routine operation.

The underlying breakdown is the absence of a trust decision that covers an agent’s own background subprocesses, not only its visible, user-facing actions. As one researcher put it, the vulnerability sits in the ordinary plumbing underneath the agent, not in the model or in anything new, meaning trust granted to an agent’s core functionality never extended to the commands that functionality could be tricked into running.

the regulatory and business exposure

  • Arbitrary code execution on developer machines through routine agent operations, bypassing approval prompts entirely.
  • Exposure triggered before user authentication or trust approval completes, in some cases on the first keystroke.
  • Multiple agents from different vendors sharing the identical flaw, pointing to a systemic pattern.

what your auditor will ask

  • How do you validate the safety of an agent’s background operations, not only its visible, user-facing actions?
  • What controls detect a repository configuration file that names a command for the agent to execute?
  • How do you verify that workspace-trust prompts actually gate every code-execution path an agent has, not just some of them?
  • What evidence do you maintain that agent tooling was evaluated for this class of flaw across all vendors in use?
  • How do you account for repositories arriving through channels, such as shared drives, that preserve configuration an ordinary clone would not?

A consistent signal is the disconnect between what a trust prompt was designed to gate and what an agent actually executes before that prompt is ever shown. A safeguard positioned at the wrong point in the process protects nothing.

zero trust for code value

Zero Trust for Code introduces a trust decision that covers every command a repository can trigger, including an agent’s own routine background operations, rather than relying on a workspace-trust prompt positioned at only one point in the process. This means execution is evaluated on what a command actually does, regardless of whether it arrives through a visible action or a subprocess the agent runs on its own.

This directly addresses the governance weakness this disclosure exposes: the assumption that a single approval gate covers all the ways a repository can cause code to run. By requiring a pre-execution trust decision independent of where in an agent’s workflow a command originates, organizations can catch exactly this class of flaw, one where the trigger is ordinary housekeeping rather than a deliberate, reviewable action.

The result is a governance model where trust is evaluated at every execution point an agent has, not only the ones a vendor’s trust dialog was built to gate, closing the space this vulnerability class relies on across multiple, otherwise unrelated tools.

governance action brief

  • Establish governance controls that evaluate command execution across an agent’s background operations, not only its visible actions.
  • Require a pre-execution trust decision for any command a repository configuration file can specify.
  • Treat workspace-trust prompts as one control among several, not confirmation that every execution path is gated.
  • Monitor for repositories arriving through channels that preserve configuration an ordinary clone would strip out.
  • Maintain a record of agent tooling evaluated against this vulnerability class across every vendor in use.

 

sources

Analysis based on reporting from The Hacker News (September 2, 2026) on Manifold Security’s GitSpawn disclosure, CodeHunter Labs evaluation of governance gaps in background-operation
execution trust, and alignment with NIST 800-53 and NIST SSDF integrity control objectives

Download the PDF here.

CodeHunter Behavioral Risk Brief cover for LiteLLM, August 2026

Behavioral Risk Brief: LiteLLM

/in /by

The Claim

Governance frameworks that treat a package’s presence on an official registry as a sufficient assumption of safety creates a systemic risk when publishing credentials upstream of that registry are compromised. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a package does once installed, independent of whether it arrived through an official, expected channel.

The Incident

Two versions of LiteLLM, an open-source AI gateway connecting applications to multiple model providers, were compromised and briefly live on PyPI. Version 1.82.8 included a file that Python automatically processes at interpreter startup, meaning it executed whenever a Python process started in that environment, regardless if anyone had explicitly imported LiteLLM at all. The compromised releases collected environment variables, SSH keys, cloud credentials, Kubernetes tokens, and database passwords, encrypting the data and sending it to an attacker-controlled domain unrelated to the project. How the malicious releases reached PyPI is disputed among investigators, variously described as a poisoned build process, a direct upload that bypassed the project’s official CI/CD workflow, or the use of a publishing token stolen through a separate, related compromise.

The Governance Failure

The governance failure is not that a popular open-source package was compromised, but that the mechanism delivering the malicious payload required no explicit action from anyone who installed it. A file that executes automatically at Python’s interpreter startup runs regardless of whether LiteLLM was ever imported, called, or knowingly used, which means the standard question a security team would ask, being “Do we use this package?”, is the wrong question entirely.

This is compounded by how the package could reach an environment in the first place. The advisory underlying this incident notes that an unpinned transitive dependency, potentially pulled in by an agent framework or orchestration tool a team never directly selected, could deliver the compromised package without anyone making a conscious decision to trust it. Whether a team knowingly uses LiteLLM matters less than whether anything on the host installed it at all.

The underlying breakdown is the absence of a trust decision that accounts for automatic execution and unpinned transitive dependencies together. Investigators still dispute exactly how the malicious releases reached PyPI, and that dispute does not change what happened next: an artifact executed on arrival, independent of import, independent of direct selection, and independent of which explanation for its origin turns out to be correct.

The Regulatory and Business Exposure

  • Credential and secret exposure across cloud, SSH, Kubernetes, and database access on any host where the package executed.
  • Delivery through unpinned transitive dependencies, exposing organizations that never selected the compromised package.
  • Disputed root cause among investigators, leaving the actual point of trust failure unresolved even after disclosure.

What Your Auditors Will Ask

  • How do you account for packages that execute automatically at interpreter or runtime startup, independent of explicit use?
  • How do you validate the behavior of transitive dependencies your teams never directly selected?
  • What evidence do you maintain of package behavior when the root cause of a compromise is disputed among investigators?
  • How do you determine which of your environments installed a compromised package before it was identified? •
  • What controls detect execution that occurs before any explicit import or invocation takes place?

A consistent signal is the disconnect between whether a team believes it uses a package and whether that package is actually present and executing somewhere in its environment. The two are not the same question, and only one of them determines exposure.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point a package actually executes, evaluating its behavior directly rather than depending on whether it arrived through an official registry or a trusted publishing channel. This means execution is assessed on its own terms, independent of registry status and independent of whether an explicit import or invocation ever occurred.

This directly addresses the governance weakness exposed by the LiteLLM compromise: the assumption that knowing whether a team uses a package is the same as knowing whether that package is present and executing in its environment. By requiring a pre-execution trust decision that accounts for automatic execution and transitive delivery alike, organizations can evaluate behavior regardless of how an artifact arrived or whether anyone chose it directly.

The result is a governance model where trust does not depend on resolving disputed questions about origin, thus closing the space this incident relied on when investigators themselves could not agree on how the compromise occurred.

Governance Action Brief

  • Establish governance controls that evaluate package behavior independent of registry status or publishing channel.
  • Require a pre-execution trust decision for code that executes automatically at interpreter or runtime startup.
  • Treat transitive dependencies with the same scrutiny applied to packages a project directly selects.
  • Monitor for package presence and execution separately from whether a team believes it uses that package.
  • Maintain a record of execution evaluated at runtime, independent of unresolved questions about how an artifact arrived.

Sources

Analysis based on reporting from The Hacker News (August 12, 2026) on the malicious LiteLLM PyPI releases, CodeHunter Labs evaluation of governance gaps in automatic-execution and transitive-dependency trust, and alignment with NIST 800-53 and NIST SSDF integrity control.

Download the PDF.

A financial services compliance officer reviewing ICT risk documentation against a regulatory deadline.

The Question Black Hat Keeps Circling This Week: What Will This Code Actually Do?

/in , /by

Black Hat USA 2026 has a number attached to it this year that is hard to ignore: 35 of the 121 Briefings on the schedule, close to 29 percent, are directly about AI security, AI red teaming, or AI-assisted offensive research (Straiker, “AI Agents Take Center Stage at Black Hat USA 2026”). That is not a niche track anymore. It is close to a third of the entire conference.

The number tracks with what is happening inside engineering organizations, including the ones building the AI tools themselves. Anthropic reported in June that more than 80 percent of the code merged into its own codebase is now written by Claude rather than by engineers, up from low single digits before Claude Code’s 2025 launch, with engineers merging roughly eight times as much code as they were two years earlier (Anthropic, “When AI Builds Itself,” June 2026). When code volume grows that fast, human review capacity does not grow with it. That gap is exactly where SOC triage backlogs come from.

Every Tool in Your Stack Still Guesses

Here is what none of those 35 Briefings changes: the tools most SOCs rely on to evaluate a suspicious artifact are still probabilistic.

An EDR platform scores a file against known patterns and behavior signatures and returns a confidence level, not a decision. A sandbox has to execute the file to observe what it does, which takes time and can be evaded by anything built to detect sandbox conditions or wait them out. A threat intelligence feed is only as good as what has already been seen and cataloged somewhere, which is exactly the coverage AI-generated and polymorphic code is designed to fall outside of.

Signature-based controls carry the same ceiling for a simple reason: when every payload is unique, there is no hash to check and no prior observation to match against, and AI-assisted tooling now generates malware variants on demand, built for a single target and never repeated.

Each of these tools is useful. None of them answers the question a SOC analyst actually has to answer before closing a ticket: what will this artifact do if it is allowed to run?

Probabilistic Plus Probabilistic Does Not Equal Deterministic

The instinct when one probabilistic tool is not enough is to add another one. Stack an AI-driven alert summarizer on top of the EDR. Add a second threat intel source. Layer in an autonomous triage assistant.

Every one of those additions makes the queue faster to move through. None of them changes the underlying math. Averaging or chaining together several confidence scores still produces a confidence score. It does not produce a fact, and it does not produce evidence an auditor or a regulator will accept as a documented decision.

That distinction is not a technicality. It is a timing problem as much as a math problem. By the time a high-confidence alert reaches a SOC queue, the artifact has often already run. Detection is working, it is just positioned at the wrong moment in the workflow, downstream of the risk instead of upstream of it.

What a Deterministic Verdict Changes

Pre-execution behavioral analysis evaluates what an artifact is capable of doing before it runs, without detonation, and without relying on a signature or a prior sighting. That behavioral finding gets mapped to MITRE ATT&CK and the Malware Behavior Catalog. The verdict, allow, block, restrict, quarantine, or require review, is what that evidence produces, not a starting assumption.

This matters most on exactly the files this year’s Briefings are worried about: code with no prior observation history, because it was generated by an LLM an hour ago, or code that mutates on every build so no two copies share a signature. Those files are precisely where probabilistic tools have the least to say and where a behavioral verdict has the most value. It is also where composition-based trust signals run out of road. SBOMs, signing, and provenance answer what is inside a build and where it came from, not what it can do once it executes, and an AI coding agent can generate code that works exactly as intended while still introducing consequences nobody authorized.

This Is a Workflow Question, Not Just a Tooling Question

The practical effect on a SOC is that the artifacts driving this year’s Black Hat AI coverage, AI-generated code, agent-produced scripts, autonomously mutating payloads, stop being special cases that need a senior analyst and a sandbox queue. They get evaluated the same way, and the same way, as every other artifact in triage: analyzed for behavior first, verdict second, documented automatically either way.

Black Hat will keep publishing bigger numbers on AI security every year for a while. The number that should matter more to a SOC Manager is not how much of the conference is about AI risk. It is how many of this week’s flagged artifacts your team can answer for with certainty, and how many are still sitting on a probability score.

CodeHunter Behavioral Risk Brief cover for WEL1DROPPER, August 2026

Behavioral Risk Brief: WEL1DROPPER

/in /by

The Claim

Governance frameworks that rely on manual code review to catch malicious packages create systemic risk when an artifact is deliberately built to survive that review. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a package does when invoked, rather than solely depending on a reviewer’s judgment of what the code appears to contain.

The Incident

Researchers identified nearly 800 malicious npm packages, published under AI-generated or typosquatted names, that deliver a downloader called WEL1DROPPER. Unlike prior campaigns that trigger automatically through install-time lifecycle hooks, these packages instruct developers in their documentation to manually load them with “require()”, meaning execution depends on a developer following the package’s own stated usage. Once invoked, the downloader identifies the host operating system and processor architecture and retrieves a matching payload from a set of cloud-hosted endpoints, falling back to DNS-based delivery if the primary method fails. The packages also include a file resembling a legitimate telemetry SDK that the actual entry point never imports, existing only to appear as ordinary analytics code during a quick manual review while the real downloader logic sits elsewhere in the package.

The Governance Failure

The governance failure is not that malicious packages reached the registry, but that trust in these packages depended on a developer’s manual judgment of what the code was doing, and a review process this campaign was specifically built to defeat. A reviewer scanning the package for anything alarming would encounter a file that looks exactly like routine telemetry code, while the actual downloader sits elsewhere, unexamined because nothing drew attention to it.

This is compounded by how execution itself was moved outside the reach of most existing controls. Many organizations have adapted to lifecycle-hook attacks by restricting install scripts, an increasingly common solution. This campaign requires no install hook at all, it activates only when a developer follows the package’s documented instructions and calls “require()” themselves. A control built around blocking automatic execution has nothing to intervene against here, because the execution was never automatic in the first place.

The main issue is the absence of a trust decision that evaluates what a package does at the moment it runs, independent of whether a human reviewer found anything suspicious beforehand. A decoy file designed to look ordinary succeeds precisely because human review depends on something appearing wrong to the reviewer. As long as trust is granted based on what a package appears to contain rather than what it does when executed, an artifact engineered to look uninteresting defeats the control by design.

The Regulatory and Business Exposure

  • Cross-platform compromise of developer machines through a payload matched to the host operating system and architecture.
  • Manual code review defeated by a decoy file specifically designed to appear as ordinary, non-suspicious functionality.
  • Reliance on install-script restrictions as a mitigation, a control this campaign was built to operate entirely outside of.

What Your Auditors Will Ask

  • How do you validate what a package does when explicitly invoked, not only what it does automatically at install?
  • What controls detect a decoy file included specifically to pass a manual code review?
  • How do you account for malicious packages that require no install hook and no automated trigger at all?
  • How do you verify that a developer following documented usage instructions is not executing unreviewed, unauthorized behavior?
  • What evidence do you maintain that a package’s behavior was evaluated at the point it runs, independent of manual review outcomes?

The disconnect between what a manual review is capable of catching and what an artifact is engineered to hide from it. A package built specifically to look ordinary upon review says nothing about what it does once a developer follows its instructions.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point a package is actually invoked, evaluating its behavior directly rather than depending on whether a manual review found anything suspicious beforehand. This means a package earns permission to run based on what it does when called, regardless of how ordinary or unremarkable its code appeared during review.

This directly addresses the governance weakness exposed by the WEL1DROPPER campaign: the assumption that human review is a reliable checkpoint against packages specifically engineered to defeat it. By requiring a pre-execution trust decision independent of review outcomes, organizations can evaluate what a “require()” call actually trigger, even when the surrounding code was built to look ordinary to a reviewer.

The result is a governance model where execution is assessed on its own behavior rather than on a reviewer’s judgment. Thus, closing the space this campaign relied on when it engineered its way around manual scrutiny entirely.

Governance Action Brief

  • Establish governance controls that evaluate package behavior at the point of invocation, independent of manual review outcomes.
  • Require a pre-execution trust decision for packages triggered through explicit developer action, not only automatic lifecycle hooks.
  • Treat install-script restrictions as one control among several, not sufficient against non-automatic execution paths.
  • Monitor for decoy or unused files included in packages solely to appear ordinary during code review.
  • Maintain a record of package behavior evaluated at execution, separate from any manual review conducted beforehand.

Sources

Analysis based on reporting from The Hacker News (August 7, 2026) on the WEL1DROPPER npm campaign, CodeHunter Labs evaluation of governance gaps in review-evasive execution trust.

Download the PDF.

""

The Real Cost of “Is This Safe to Run?”

/in , /by

An EDR flags an unfamiliar binary on an endpoint. Nothing about it matches a known signature. It is not obviously malicious, and it is not obviously safe either. Somebody on your team now has to answer one question before anyone can move on: is this safe to run?

That question sounds small. In most SOCs, answering it well takes two to four hours per artifact, and it happens dozens of times a week.

Where the Hours Actually Go

The manual triage path most SOCs run today looks something like this:

Sandbox detonation. The artifact gets run in an isolated environment to observe what it does. This requires execution, takes anywhere from minutes to hours depending on queue depth, and can be evaded by malware built to detect sandbox conditions or delay its behavior until it is out of one.

Manual reverse engineering. If the sandbox result is inconclusive, which is common, a senior analyst opens the binary directly. This is the most expensive hour in the SOC, spent on work that does not scale with headcount.

Threat intelligence lookups. Useful for confirming known-bad, and close to useless for anything unknown: a file that has never been observed before, a polymorphic variant, or code an AI tool generated a few hours ago with no prior history anywhere clears these lookups by design, not by accident.

Ticketing and documentation. After the technical work is done, someone still has to write up a rationale that will hold up if an auditor or a regulator asks about it later.

Add it up across five to eight browser tabs and a couple of tools, and two to four hours per artifact is the realistic floor, not the ceiling.

The Cost Isn’t Just Time

The hours are the visible cost. The less visible cost is what those hours are made of.

It is senior analyst capacity, spent on triage that is largely deterministic once someone does the work, rather than on the investigations that actually need judgment. Hiring more analysts does not fix this, because the bottleneck is not headcount, it is how much of each analyst’s day gets consumed by the same repeatable question.

It is MTTR, which is quietly becoming a metric boards ask about directly, not just a SOC internal number.

And it is alert fatigue in its most literal form: most of what gets flagged is not malicious, but every flagged artifact costs roughly the same two to four hours until someone proves otherwise. The real threats are hiding in that same queue, getting the same treatment as the noise around them.

What Changes When the Verdict Comes in Minutes

Pre-execution behavioral analysis looks at what an artifact is capable of doing before it runs, without detonating it. That behavioral finding, mapped to MITRE ATT&CK and the Malware Behavior Catalog, is what produces the verdict: allow, block, restrict, quarantine, or require review. The verdict is the output. The behavior is what actually got evaluated.

This is a different kind of answer than a sandbox or a threat intel feed gives you. Those tools return a probability. A deterministic verdict is a decision, backed by evidence a person can actually review, not a score someone still has to interpret.

For a SOC running this workflow today, the practical change is that the two-to-four-hour question collapses to minutes, on the same artifacts, integrated downstream of whatever EDR is already flagging them (SentinelOne, CrowdStrike, Microsoft Defender, Carbon Black).

Why This Matters Beyond the SOC

The behavioral evidence produced for each artifact does not disappear once the ticket closes. It becomes the governance record: the documented answer to what was evaluated, what it was found capable of doing, and why it was or was not allowed to run. That is exactly what an auditor asks for after the fact, and exactly what most SOCs currently have to reconstruct from memory and Slack threads instead of producing on demand.

We have written before about how automation complements SOC analysts and about what happens when alert volume overwhelms a team’s capacity to keep up. This is the same problem, sized in hours.

The next time an artifact lands in your queue, time how long it actually takes your team to produce a defensible answer. That number, not the alert count, is the real cost of the question, and it is the number worth fixing first.

""

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 Behavioral Risk Brief cover for Ghostcommit, July 2026 (65 chars)

Behavioral Risk Brief: Ghostcommit

/in /by

The Claim

Governance frameworks that treat automated code review as sufficient validation create systemic risk when trust is granted based on what a scanner can see rather than what an artifact
will do once an agent acts on it. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a merged artifact actually does, not on whether it passed a review process
built to catch a narrower category of risk.

The Incident

A pull request attack shows how an AI-authored convention file can smuggle instructions past code review by hiding them inside an image. The technique, called Ghostcommit, embeds
exfiltration instructions as plain text inside a PNG referenced by an AGENTS.md file, the kind of file coding agents read automatically and treat as standing project policy. Because tools like
CodeRabbit exclude image files from review by default, and Cursor’s Bugbot does not process image files, the pull request merges without objection. Nothing happens at merge time. The
payload only activates later, when a developer asks the coding agent to complete an unrelated, routine task in a separate session. The agent reads the merged convention file, follows its
reference to the image, opens the repository’s .env file, and writes the contents into a new code constant disguised as a build value.

The Governance Failure

The governance failure is not that a review tool missed a malicious pull request, but that trust was granted to a merged artifact based on the narrow set of risks a reviewer was built to catch, rather than on what that artifact would do once an agent later acted on it. A pull request that passes review is treated as safe going forward, even though the review only evaluated text content and never assessed what would happen when a different tool, operating under different assumptions, executed instructions the artifact contained.

This is compounded by how convention files function inside agentic development workflows. Files like AGENTS.md are designed to be read automatically and treated as authoritative project policy, which means anything referenced from them inherits that same standing without a separate trust decision. An image cited as a build specification carries the same authority as an explicit line of code, despite never being evaluated as one.

The underlying breakdown is the absence of a trust decision at the moment an agent actually acts on repository content. Review at merge time answers whether a reviewer objected to what it could see. It does not answer whether an agent, executing days or weeks later under an entirely different toolchain, will trust and act on content the original review never evaluated in that context.

The Regulatory and Business Exposure

  • Exfiltration of credentials, API keys, and connection strings through routine agent activity unrelated to the original pull request.
  • Merge-time review certifying an artifact as safe without evaluating what an agent will later execute against it.
  • Inconsistent outcomes across coding tools and models, undermining any assumption that review status is a durable safety signal.

What Your Auditors Will Ask

  • How do you validate what an AI coding agent will do with a merged artifact, independent of whether that artifact passed code review?
  • How do you account for content types, such as images or binary files, that your review tooling does not evaluate?
  • What controls detect an agent reading and acting on repository content outside the task the developer actually requested?
  • How do you verify that review approval reflects an evaluation of execution behavior, not just visible text content?
  • What evidence do you maintain that a merged artifact’s behavior was assessed at the point an agent acts on it, not only at the point it was reviewed?

A consistent signal is the disconnect between what a review process was built to catch and what an artifact is later permitted to do. Passing review answers a narrower question than the one that determines actual risk.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point an agent is about to act on repository content, evaluating what that action will do against defined policy rather than relying on whether
the underlying artifact previously passed code review. This means an image, a configuration file, or any other referenced content is assessed on the behavior it produces when acted upon, not on
whether a reviewer built for a different purpose objected to it.

This directly addresses the governance weakness exposed by Ghostcommit: the assumption that merge-time review is a durable safety signal for actions an agent takes long after that review
occurred. By requiring a pre-execution trust decision, organizations can prevent an agent from exfiltrating credentials through a routine task, regardless of what a prior review process did or did
not evaluate.

The result is a governance model where an agent’s actions are evaluated against policy at the moment they occur, closing the distance between what was reviewed and what is later executed
rather than assuming the two remain aligned indefinitely.

Governance Action Brief

  • Establish governance controls that evaluate agent behavior at the point of execution, independent of prior code review outcomes.
  • Require a pre-execution trust decision for any action an agent takes based on repository content, including convention files and referenced media.
  • Enforce execution policies across coding agents and IDE tooling that read project files automatically as standing instructions.
  • Treat merge-time review as one input among several, not as a durable safety determination for future agent actions.
  • Maintain a record of what an agent was permitted to act on, even if that content was previously reviewed.

Download the PDF

Sources

Analysis based on reporting from BleepingComputer (July 11, 2026) on the Ghostcommit technique disclosed by the University of Missouri-Kansas City’s ASSET Research Group

CodeHunter Behavioral Risk Brief cover for PolinRider Campaign, July 2026, for the regulated-enterprise CISO

Behavioral Risk Brief: PolinRider Campaign

/in /by

The Claim

Governance frameworks that treat software supply chains as trusted by default create systemic risk when trust can be transferred, inherited, or re-established without independent validation. Zero Trust for Code addresses this by enforcing behavioral controls at execution, ensuring that trust is continuously verified rather than carried forward from prior assumptions.

The Incident

North Korean threat actors linked to the Contagious Interview campaign have published 108 malicious packages and extensions across npm, Packagist, Go modules, and Chrome ecosystems as part of an operation known as PolinRider. The campaign combines maintainer account compromise, repository modification, malicious package releases, and developer-focused delivery techniques to establish access within development environments. Researchers identified 162 malicious release artifacts and nearly 2,000 compromised GitHub repositories associated with the activity. In some cases, malicious VS Code tasks executed automatically when a project folder was opened, enabling code execution through trusted development workflows.

The Governance Failure

The governance failure is not the publication of malicious packages, but the absence of controls that continuously validate software trust throughout the development lifecycle. Organizations often rely on repository reputation, maintainer history, package popularity, or prior approval decisions as indicators of integrity. These signals establish trust once but rarely verify that trust remains valid as ownership changes, updates are released, or dependencies evolve.

This challenge is amplified by modern development practices that automate software consumption at scale. Packages, modules, extensions, and project dependencies frequently enter environments through trusted workflows without meaningful review of the actions that they are capable of performing. As software ecosystems become increasingly interconnected, a single compromise can appear through development environments, build systems, and downstream applications while appearing operationally normal.

The underlying breakdown is the lack of enforceable policy governing what imported code is allowed to do after execution begins. Once software is accepted into the environment, organizations often have limited control over how it accesses credentials, interacts with repositories, modifies configurations, or executes additional payloads. This creates a condition where trust decisions become persistent, while risk remains dynamic and capable of evolving over time.

This pattern has played out before across different ecosystems and threat actors. For a related look at how trusted developer access becomes the primary attack vector, see Taking Down the Botnet Doesn’t Answer the Harder Question.

The Regulatory and Business Exposure

  • Compromise of developer environments through trusted software supply channels.
  • Exposure of credentials, source code, and intellectual property assets.
  • Increased risk of downstream software contamination across build and deployment pipelines.
  • Loss of assurance in trusted models.

What Your Auditors Will Ask

  • How do you detect unexpected maintainer changes or ownership transfers in trusted software packages?
  • How do you identify development tools performing actions outside established development and deployment workflows?
  • What controls detect repository updates that introduce obfuscated code or concealed execution paths?
  • How do you validate that package behavior aligns with its documented purpose and intended functionality?
  • How do you verify software provenance and ensure trusted artifacts are not exhibiting anomalous or unauthorized behavior?

A consistent signal is the disconnect between software provenance and software behavior. Artifacts that appear legitimate based on source or history begin performing actions that exceed their expected operational scope.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point before software is allowed to execute, this ensures that imported code, dependencies, and development tooling are evaluated against policy before any action is taken, rather than monitored for intent as events unfold. Rather than relying on maintainer reputation or package history, it validates whether an artifact should be permitted to run at all.

This directly addresses the governance weakness exposed by PolinRider: the assumption that trusted software ecosystems remain trustworthy over time. By requiring a pre-execution trust decision, organizations can prevent compromised packages from ever reaching the point of accessing sensitive data, modifying environments, or launching secondary actions, regardless of the channel they arrived through.

The result is a governance model where trust is decided before code runs rather than inferred from provenance, reducing reliance on software history alone and ensuring that supply chain compromise does not translate into permitted execution.

Governance Action Brief

  • Establish governance controls that validate software behavior independently of repository trust.
  • Require continuous verification of package updates, maintainer changes, and dependency lineage.
  • Enforce execution policies for development environments, IDEs, and build systems.
  • Monitor for hidden execution paths triggered through project configuration and automation features.
  • Treat developer workstations as high-value environments requiring behavioral enforcement controls.

Sources

Analysis based on BleepingComputer reporting (July 3, 2026) on the North Korea-linked PolinRider campaign, and CodeHunter Labs evaluation of governance gaps in post-compromise execution and persistence control.

Download the PDF. 

CodeHunter Security Brief cover for StegoAd Campaign, June 2026, for the regulated-enterprise CISO

Security Brief: StegoAd Campaign

/in /by

The Claim

Governance models that treat official marketplaces as trusted control boundaries assume that validation at admission ensures safety over time. When software is permitted to execute based
on initial approval rather than continuous verification, trust becomes static while behavior evolves. Zero Trust for Code addresses this by enforcing control at execution, ensuring that approved software cannot perform actions outside defined policy.

The Threat

Microsoft removed 119 malicious extensions from the Edge Add-ons store tied to a campaign known as “StegoAd.” These extensions seemed to be common legitimate tools, such as ad blockers, VPNs, and translators, and functioned normally to build user trust. Malicious payloads were concealed within image and font files and remained dormant for days after installation. It activated only after bypassing multiple evasion checks. Once active, the extensions enabled credential theft, session hijacking, ad fraud, and remote code execution, affecting an install base of up to 2.6 million users.

The Problem

The governance failure lies in the reliance on pre-publication validation as a sufficient control, without enforcing constraints on behavior after deployment. Review processes focus on visible code and declared functionality, but do not account for hidden execution paths embedded within non-executable assets or delayed activation patterns. This creates a gap where software passes acceptance criteria while retaining the ability to execute unauthorized actions at a later time.

This issue is compounded by trust inheritance within official ecosystems. Software distributed through approved marketplaces gains implicit credibility, reducing scrutiny from both users and organizations. Attackers exploit this trust by designing software that behaves correctly during initial evaluation, then transitions to malicious operation after predefined conditions are met. Because governance decisions are tied to admission rather than ongoing behavior, this transition occurs outside any enforced control boundary.

The underlying breakdown is the absence of continuous behavioral governance across the software lifecycle. Once software is installed, there are no enforceable limits on how it interacts with credentials, sessions, or external systems. This allows malicious functionality whether it be hidden, delayed, or remotely delivered, to execute without restriction, demonstrating that trust assigned at installation does not translate into control at runtime.

For a deeper look at where the trust decision breaks down across the software lifecycle, see Applying Zero Trust to Software: The Gap Between Provenance and Permission.

The Impact

  • Unauthorized execution within trusted browser environments at scale.
  • Credential and session compromise leading to account takeover risk.
  • Financial impact through ad fraud and transaction manipulation.
  • Erosion of trust in marketplace-based validation and approval systems.

What to Watch For

  • Extensions or software exhibiting delayed activation after installation.
  • Legitimate features paired with unexplained background network activity.
  • Use of non-traditional assets (images, fonts) in execution workflows.
  • Software maintaining normal function while generating anomalous outcomes.

A consistent signal is the misalignment between approved functionality and observed behavior. Software continues to meet user expectations while simultaneously performing actions outside defined operational boundaries.

Zero Trust for Code Value

Zero Trust for Code introduces enforcement that operates independently of how software is sourced or approved, ensuring that all execution is validated against defined behavioral policy. By evaluating actions before completion, it prevents software from performing unauthorized operations whether it is trusted, approved, or widely distributed.

This directly addresses the governance gap exposed in this campaign: the lack of control after acceptance. Instead of assuming that vetted software will behave as intended, Zero Trust for Code ensures that only permitted actions are allowed to execute, regardless of origin, reputation, or prior validation.

The result is a governance model where trust is not static but continuously enforced, closing the gap between approval and execution and preventing delayed or hidden functionality from operating outside control.

CISO Action Brief

  • Establish governance policies that extend beyond software admission to continuous execution monitoring.
  • Enforce behavioral constraints on all applications and extensions, regardless of source or approval status.
  • Treat marketplace-distributed software as untrusted until behavior is validated in context.
  • Monitor for delayed or conditional execution patterns across endpoints.
  • Centralize decisioning to ensure that approval does not override enforcement.

Methodology & Sources

Analysis based on reporting from The Hacker News (June 29, 2026) on Microsoft’s removal of 119 malicious Edge extensions tied to the StegoAd campaign, supported by Microsoft research
CodeHunter Labs evaluation of governance failures in marketplace-driven software trust models.

Download the PDF

Zero Trust for Code enforcing pre-execution security by analyzing software behavior and preventing unauthorized code execution

Identifying the Unknown: How MSPs Expose Zero-Day Malware at Scale

/in , , /by

 

Read more

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

How MSPs Can Grow Cybersecurity Services Without Adding Headcount

/in , /by

As cyber threats evolve and client expectations rise, Managed Service Providers (MSPs) are under growing pressure to deliver high-impact security services without ballooning operational costs. Scaling up traditionally means hiring more analysts, investing in additional tools, and spending countless hours on manual threat investigation. But in today’s market, that’s neither sustainable nor scalable.

Read more