Insights

Security analyst reviewing multiple alerting dashboards to understand risky software behavior and prevent unauthorized code execution before it runs

Between the Alert and the Verdict: Where SOC Hours Go

/in /by

An EDR flags an artifact. That part takes a second. What happens next can take hours, days, and sometimes even weeks.

An analyst opens a sandbox to detonate it. Pulls up threat intel to check for prior sightings. Starts a manual reverse engineering pass if the first two come back inconclusive. Opens a ticket to track the investigation. Two to four hours later, there’s a verdict, and it’s rarely as defensible as the next audit will require. That range isn’t a guess: CodeHunter’s own research puts the realistic floor for a defensible answer at two to four hours per artifact, not the ceiling, once sandbox time, manual reverse engineering, threat intel lookups, and documentation are all added up.

Multiply that by volume. IT security teams are fielding an average of 11,000 alerts a day, and roughly 22 per analyst actually warrant a close look. The other 10,978 still must be triaged enough to know they’re not the ones that need further investigation.

Some of this volume increase traces back to how fast code is entering the environment now. AI-assisted development means more artifacts get written, reviewed, and shipped faster than any one team can manually vet.

While this may seem like an alert volume problem, it’s actually a capacity issue – and one that can’t be fixed simply by adding additional analysts.

The Actual Bottleneck

Every tool sitting between the alert and the verdict today produces a score, not a decision. The EDR says an artifact looks suspicious. The sandbox says it exhibited a pattern. Threat intel says it hasn’t been seen before. None of that provides a deterministic answer to the one question that actually matters: should this be allowed to run?

That question is what a person is currently answering by hand, artifact by artifact, for hours at a time. It’s also the exact step that can be automated without touching anything else in the stack.

What SOC automation looks like here

CodeHunter sits downstream of the EDR. When an artifact gets flagged, CodeHunter analyzes what it’s actually capable of doing: what it touches, what it calls out to, what it modifies, what it’s trying to gain access to. That behavioral read is what produces the verdict, not the other way around. Allow, block, restrict, quarantine, or require review, with the specific behavior that led to it attached.

The result for a SOC team is the same triage step that used to take two to four hours, done in minutes, on every artifact, not just the ones a senior analyst has time to get to. Nothing about the surrounding workflow changes. The EDR still flags. The ticket still opens. The step in between just stops being manual.

The part that shows up later

Once that verdict exists, it doesn’t disappear after the ticket closes. Every artifact evaluated carries its own record: what behavior was found, and why the verdict landed where it did, mapped to MITRE ATT&CK and the Malware Behavior Catalog. That record is what turns into audit evidence, board reporting, or an answer to “how do you know” without anyone having to reconstruct it after the fact. It’s a byproduct of doing the triage step correctly, not a separate project.

What this changes for a SOC team

Senior analysts stop spending their shift on work a machine can do faster and more consistently. The backlog that used to grow every time the headcount stayed flat now starts to shrink instead. And the next time someone asks why a given file was allowed to run, there’s an actual answer, not a memory of what the analyst was thinking three weeks ago.

None of this requires ripping out an existing tool or building a new automation platform from scratch. It’s one step, done automatically, in a workflow that already exists. The hours between the alert and the verdict are the part of the SOC day nobody budgets for, and everybody loses time to. It’s also the part the easiest part to automate first.

Sources

The Real Cost of “Is This Safe to Run?” — CodeHunter, August 5, 2026. Source for the two-to-four-hours-per-artifact figure and the sandbox/manual reverse engineering/threat intel/ticketing breakdown.

Alert Fatigue Is Killing Your SOC. Here’s What Actually Works in 2026. — Torq. Source for the 11,000 alerts/day, ~22 per analyst warranting investigation figures.

2026 GenAI Code Security Report — Veracode. Source for AI-assisted development increasing the volume of artifacts entering environments.

Zero Trust for Code — CodeHunter. Source for the MITRE ATT&CK / Malware Behavior Catalog mapping and verdict-type (Allow/Block/Restrict/Quarantine/Require Review) language.

CodeHunter Behavioral Risk Brief cover for Arch AUR Repository, August 2026

Behavioral Risk Brief: Arch AUR Repository

/in , , /by

The Claim

Governance frameworks that treat package adoption as a routine maintenance mechanism create systemic risk when that same mechanism can transfer control of a trusted package name to an attacker. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a package does after any change in control, rather than extending trust indefinitely once a package has been established.

The Incident

Attackers began adopting orphaned packages in the Arch User Repository and pushing malicious follow-up commits. The campaign began with the package “openconnect-sso” and expanded to over 120 confirmed malicious packages, including established tools such as boringssl-git, icloudpd, and windscribe-cli-v2-bin. Arch Linux first used disabled package adoption on July 30 to slow the takeovers, then disabled all AUR pushes entirely on August 1 after the activity continued through newly created accounts. The payload is a Rust-based infostealer that exfiltrates browser data, credentials, and cryptocurrency wallets, and spreads further by harvesting SSH access from infected machines. This is the third wave to hit the repository this year, involving over 400 malicious packages and eventually reaching 1,500 by the time the cleanup was complete.

The Governance Failure

The governance failure is not that attackers targeted an open community-maintained repository, but that the mechanism designed to keep abandoned packages alive carries no verification of what that new maintainer intends to do with the trust they are inheriting. A package’s history, download count, and prior clean commits all belong to a previous maintainer whose relationship to the package has already ended.

This is compounded by how naturally this activity blends into the platform’s own design. Adopting an orphaned package and pushing an update is exactly what the system was built to allow, which means the attack does not require any exploit or credential theft, only patience in waiting for packages to go unmaintained and a willingness to register new accounts once old ones are banned. An organization scanning package contents for known malware signatures would find nothing to flag until after a malicious update had already landed.

The underlying breakdown is the absence of a trust decision at the point of when maintainership actually changes hands. This is now the third such wave in a single year, and each occurrence has been addressed by suspending the adoption mechanism itself rather than by verifying what any given maintainer transition introduces. As long as trust transfers automatically with the act of adoption, disabling the feature is the only lever available once an attack is already underway.

The Regulatory and Business Exposure

  • Credential, browser data, and cryptocurrency theft delivered through packages with established, previously trusted histories.
  • Lateral spread across networks through harvested SSH access on infected developer machines.
  • Repeated incidents addressed only by suspending a core platform feature.

What Your Auditors Will Ask

  • How do you validate a package’s behavior after a change in maintainer or ownership, independent of its prior history?
  • What controls detect malicious activity introduced through a legitimate platform mechanism rather than an exploit?
  • How do you account for risk in third-party or community repositories your developers use outside sanctioned channels?
  • What evidence do you maintain that a package was evaluated again after control of it changed hands?
  • How do you respond when a repeated pattern of compromise is addressed by disabling a feature rather than verifying trust directly?

A consistent signal is the disconnect between a package’s accumulated history and what its current maintainer is doing with it. A clean record under a previous owner says nothing about the version published by whoever holds that access now.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point a package is about to execute, evaluating what it does independent of its maintainership history or how long it has existed in a repository. This means a package earns permission to run based on its current behavior, not on trust accumulated under a maintainer who may no longer control it.

This directly addresses the governance weakness exposed by the AUR campaign: the assumption that a package’s established history remains meaningful after maintainership changes hands. By requiring a pre- xecution trust decision independent of ownership history, organizations can evaluate what a newly adopted or updated package actually does, rather than relying on a platform feature being disabled as the only available response.

The result is a governance model where trust is re-established every time a package changes hands or executes, closing the space a repeated attack pattern has relied on across three separate incidents this year.

Governance Action Brief

  • Establish governance controls that evaluate package behavior independently of accumulated history or prior maintainer reputation.
  • Require a pre-execution trust decision whenever a package’s maintainer or ownership changes.
  • Treat community-maintained repositories as requiring the same execution-level scrutiny as official package sources.
  • Monitor for SSH-based lateral spread originating from developer machines running third-party packages.
  • Maintain a record of package trust decisions evaluated at each maintainership transition, not only at initial adoption.

Sources

Analysis based on reporting from BleepingComputer and Cybernews on the Arch Linux AUR supply chain campaign, CodeHunter Labs evaluation of governance gaps in maintainership-transfer execution trust, and alignment with NIST 800-53 and NIST SSDF.

Download the PDF

CodeHunter Behavioral Risk Brief cover for Joyfill npm Packages, July 2026

Behavioral Risk Brief: Joyfill npm Packages

/in , /by

The Claim

Governance frameworks that treat install-script restrictions as sufficient protection create systemic risk when malicious code is embedded to execute at import rather than install. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what a package does when it runs, regardless of which lifecycle stage triggers that behavior.

The Incident

Malicious beta releases of two legitimate npm packages, “@joyfill/components” and “@joyfill/layouts”, were published to the registry. Rather than relying on a postinstall or preinstall hook, the implant was embedded directly into the compiled distribution bundle. This means it executes the moment the module is imported into a project, not when it is installed. This bypasses the standard defensive flag that disables install scripts since that protection has no effect on code that runs at import time. Once active, the implant resolves its command-and-control address by reading a blockchain transaction, first on Tron and then pivoting to Binance Smart Chain, before deploying a remote access trojan and a separate credential stealer targeting browser data, cryptocurrency wallets, and developer tokens.

The Governance Failure

The governance failure is not that a trusted package was compromised, but that the defensive posture many organizations rely on assumes malicious behavior arrives through a specific, well-known lifecycle stage. Disabling install scripts has become a standard mitigation precisely because so many prior campaigns relied on that mechanism. This implant was built around the assumption that organizations would rely on exactly that control and then move to a stage that the control does not cover.

This is compounded by the choice to resolve command infrastructure through blockchain transactions rather than a fixed address. A hardcoded command-and-control server can be identified, blocklisted, and starved of new instructions once discovered. A transaction-based lookup gives the attacker a way to redirect the payload at any time without publishing a new package version, meaning a security team’s confidence in having identified and blocked the infrastructure may already be outdated the moment it is recorded.

The underlying breakdown is the absence of a trust decision that evaluates what a package does regardless of which lifecycle stage triggers it. Any control anchored to a single execution point, install, import, or otherwise, leaves every other point unexamined, and this campaign demonstrates that attackers will simply relocate to whichever stage current defenses do not reach.

The Regulatory and Business Exposure

  • Bypass of a widely deployed install-script mitigation through code that executes only at import.
  • Command-and-control infrastructure that can be silently redirected without any new package version or registry activity.
  • Exposure of developer credentials, tokens, and cryptocurrency wallets across affected workstations.

What Your Auditors Will Ask

  • How do you validate package behavior at every lifecycle stage, not only at install?
  • What controls would detect an implant that activates specifically because a package is imported?
  • How do you account for command-and-control infrastructure that can change without any new software release?
  • What evidence do you maintain that a package’s behavior was evaluated after import, not only at publication?
  • How do you verify that mitigations built around one execution stage are not simply displacing risk to another?

A consistent signal is the disconnect between where a mitigation was built to work and where an attacker chooses to operate. A control anchored to one execution stage says nothing about what happens at the next one.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point a package actually executes, evaluating its behavior regardless of whether that execution happens at install, at import, or at any other lifecycle stage. This means a package earns permission to run based on what it does in the moment, not based on which stage a defensive control happens to cover.

This directly addresses the governance weakness exposed by the Joyfill compromise: the assumption that disabling install scripts closes the relevant risk. By requiring a pre-execution trust decision independent of lifecycle stage, organizations can evaluate import-time behavior with the same rigor applied to installation, removing the incentive to simply relocate a payload to an uncovered stage.

The result is a governance model where every execution point carries the same trust requirement, closing the space attackers rely on when one stage is defended and another is not.

Governance Action Brief

  • Establish governance controls that evaluate package behavior at mport, not only at installation.
  • Require a pre-execution trust decision independent of which lifecycle stage triggers execution.
  • Treat install-script restrictions as one control among several, not a complete mitigation on their own.
  • Monitor for command-and-control resolution methods, including blockchain-based lookups, that evade static infrastructure blocking.
  • Maintain a record of package behavior evaluated per execution stage rather than assumed covered by a single control.

Sources

Analysis based on The Hacker News and StepSecurity (July 28-29, 2026) on the Joyfill npm supply chain compromise, CodeHunter Labs evaluation of governance gaps in lifecycle-stage execution trust, and alignment with NIST 800-53 and NIST SSDF integrity control objectives.

Download the PDF. 

CodeHunter Behavioral Risk Brief cover for Notepad Plus Plus, July 2026

Behavioral Risk Brief: Notepad ++

/in , /by

The Claim

Governance frameworks that treat a legitimate, signed application as inherently safe create systemic risk when that application can be paired with malicious components it will execute automatically. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what an application actually loads and runs, rather than extending trust to everything bundled alongside a recognized binary.

The Incident

CERT-UA disclosed a campaign attributed to the threat cluster UAC-0099 that delivers a fake Notepad++ plugin to compromise Windows systems. A phishing email leads victims through a shortened link to a ZIP archive containing a VBScript disguised as a PDF, which displays a decoy document while silently retrieving a second archive. That archive contains a complete and legitimate copy of Notepad++, a malicious DLL named NppExport.dll, and supporting tools. The script launches the genuine Notepad++ binary, which automatically loads the malicious DLL as a plugin. That DLL unpacks additional components and establishes persistence through a scheduled task running every three minutes, ultimately delivering a loader called “BURNYBEAR” and a modified payload tracked as “MATCHBOIL.V2”.

The Governance Failure

The governance failure is not that Notepad++ was impersonated, but that the actual application delivered to the victim is the real legitimate Notepad++ binary that is unmodified and fully functional. Any control built around verifying the identity or signature of the executable being launched would find nothing to object to. The compromise lives entirely in what that legitimate binary is permitted to load and execute once it runs and a layer signature verification is never reached.

This is compounded by how plugin architectures function. A trusted application loading a DLL from its own plugins directory is completely ordinary behavior. It is indistinguishable at launch from any legitimate extension a user might install. Trust granted to the parent executable extends implicitly to whatever it loads next, without a separate decision evaluating what that plugin does once it holds the parent process’s privileges.

The underlying breakdown is the absence of a trust decision at the moment a loaded component begins executing, as distinct from when the parent application launches. This pattern is not unique to Notepad++. Any application with a plugin or module-loading architecture creates the same exposure, and as long as trust is assigned only to the parent process, this technique remains available regardless of which application it is built around.

The Regulatory and Business Exposure

  • Persistent access established through a scheduled task disguised as routine application behavior.
  • Resource exhaustion triggered as a fallback if the malicious loader runs outside expected conditions.
  • Reliance on signature checks that verify the parent application while loaded plugins go unexamined.

What Your Auditors Will Ask

  • How do you validate the behavior of plugins or modules loaded by applications your organization already trusts?
  • How do you distinguish a legitimate binary from the components it is permitted to load once running?
  • What controls detect a scheduled task established through an otherwise trusted application?
  • How do you verify that application allowlisting accounts for what a binary executes after launch?
  • What evidence do you maintain that a loaded plugin’s behavior was evaluated independently of the parent application’s trust status?

A consistent signal is the disconnect between the executable that was verified and the code that actually ran. A legitimate binary passing every identity check says nothing about what it will load once permitted to execute.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point a loaded component is about to execute, evaluating what that plugin or module will do independently of whether the parent application is legitimate or already allowlisted. A plugin is assessed on its own behavior, not granted the trust status of the executable that loads it.

This directly addresses the governance weakness exposed by UAC-0099: the assumption that verifying a parent application is sufficient because everything it loads inherits that same trust. By requiring a pre-execution decision for loaded components specifically, organizations can stop a
malicious plugin even when the application launching it is entirely legitimate.

The result is a governance model where trust is evaluated at every layer, the parent binary and everything it loads, rather than assumed to flow automatically from one to the other.

Governance Action Brief

  • Establish governance controls that evaluate plugin behavior independently of the parent application’s trust status.
  • Require a pre-execution trust decision for any component loaded dynamically by an approved application.
  • Enforce execution policies covering plugin directories for widely used developer and productivity applications.
  • Monitor for scheduled tasks or persistence mechanisms established through processes descending from trusted applications.
  • Maintain a record of loaded components evaluated separately from the parent binary’s approval.

Sources

Analysis based on reporting from The Hacker News (July 24, 2026) on CERT-UA’s disclosure of the UAC-0099 campaign, CodeHunter Labs evaluation of governance gaps in plugin execution trust, and alignment with NIST 800-53 and NIST SSDF integrity control objectives.

Download the PDF. 

""

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 Disguised npm Packages, July 2026

Behavioral Risk Brief: Disguised npm Packages

/in , /by

The Claim

Governance frameworks that scan for malicious behavior only at install time create systemic risk when registries are used as free hosting for artifacts that never touch a build pipeline. Zero Trust for Code addresses this by requiring a pre-execution trust decision on what an artifact does when it runs, regardless of whether it runs during installation, in a browser, or anywhere else code is permitted to execute.

The Incident

Researchers at JFrog identified 141 npm packages in May, later growing to 148 by July, published under names branded as student tools to bypass school web filters. The packages carried no install scripts or lifecycle hooks and were never meant to be imported into a project, instead hosting a client-side proxy web app that visiting browsers loaded directly, using npm purely as a content delivery mechanism. Underneath the proxy sat two hidden modules: one fetched remote JavaScript from a mutable, unpinned GitHub branch and executed it with the site’s full origin privileges, while the other opened up to 1,024 WebSocket connections per browser tab targeting a proxy protocol server, exhausting its resources rather than the visiting student’s own device. A second wave of packages published in July restored the adware
functionality while leaving the remote loader in place, still pointed at the same branch.

The Governance Failure

The governance failure is not that malicious packages reached the registry, but that the entire model of software trust assumed a package’s risk lives at install time. Dependency scanners, install-time sandboxes, and lifecycle hook monitoring are built around a single execution surface: what happens when a package is pulled into a project and run through “npm install”. These packages never triggered that surface at all, because they were never designed to be installed as dependencies in the first place.

This exposes a second, more persistent gap. The remaining packages still load a script from a mutable branch with no integrity verification. Whoever controls that branch can change what every visiting browser executes at any time, without publishing a new package version, without triggering a new npm scan, and without leaving any trace in a lockfile or manifest that a security team would think to review. The registry’s admission process, and any monitoring built around package versions, has no visibility into a artifact that can be silently re-armed downstream of the point where every existing control is watching.

The underlying breakdown is the assumption that an artifact’s trustworthiness is fixed at the moment it is scanned and published. Trust granted to a package version does not account for content the package points to but does not contain, and it does not account for a second execution surface, the browser, that operates entirely outside the tooling built to govern developer environments. As long as an artifact can behave one way during review and a different way once deployed, scanning at any single point in time cannot be the control that decides what is allowed to run.

This gap keeps showing up in different forms across different ecosystems. For a broader look at why origin-based trust controls keep falling short, see Taking Down the Botnet Doesn’t Answer the Harder Question.

The Regulatory and Business Exposure

  • Execution of unreviewed, remotely mutable code within enterprise or school network browser sessions.
  • Resource exhaustion and denial-of-service impact carried out through end-user browsers rather than compromised infrastructure.
  • Continued exposure to artifacts that can be altered after publication without triggering any package-level review or re-scan.

What Your Auditors Will Ask

  • How do you validate the behavior of artifacts that execute in a browser rather than at install time?
  • How do you account for registries or repositories being used to host content outside their intended package format?
  • What controls detect a referenced script changing after the artifact that points to it was last reviewed
  • How do you determine whether an approved artifact can still alter its own behavior post-publication
  • What evidence do you maintain that execution behavior was evaluated at the point it runs, not only at the point it was published?

A consistent signal is the disconnect between where an organization’s controls are looking and where an artifact actually executes. Trust concentrated entirely at install time leaves every other execution surface unexamined.

Zero Trust for Code Value

Zero Trust for Code introduces a trust decision at the point where an artifact is about to execute, regardless of whether that execution happens during installation, inside a browser, or through any other surface a registry or repository makes available. This means a package is assessed on what it does when it runs, not on whether it matches the narrow category of behavior a scanner was built to catch.

This directly addresses the governance weakness exposed by the student proxy campaign: the assumption that install-time review is sufficient because it is the only execution surface most controls were designed to watch. By requiring a pre-execution trust decision independent of where or how code runs, organizations can evaluate a referenced script’s behavior at the moment it executes, even when that script can change after the artifact pointing to it was last reviewed.

The result is a governance model where execution is evaluated wherever it occurs, closing the distance between what was published and what actually runs on any given day, rather than assuming the two remain the same after the fact.

Governance Action Brief

  • Establish governance controls that evaluate artifact behavior at every execution surface, not only at install time.
  • Require a pre-execution trust decision for any code an artifact references or loads dynamically, including content served from mutable or unpinned sources.
  • Enforce execution policies for browser-based sessions on managed networks, not solely for developer workstations and CI/CD environments.
  • Monitor for registries or repositories being used as hosting infrastructure for artifacts outside their intended package format.
  • Maintain a record of what an artifact was permitted to execute, independent of whether its underlying content has since changed.

Download the PDF

Sources

Analysis based on reporting from The Hacker News (July 14, 2026) and CodeHunter Labs evaluation of governance gaps in post-publication execution trust.

 

Stephen McCarney Joins CodeHunter as Chief Strategy Officer

/in , /by

stephen mccarney, chief strategy officer, CodeHunterCodeHunter has named Stephen McCarney as Chief Strategy Officer, adding a go-to-market leader with a track record of scaling category-defining security companies to help expand Zero Trust for Code across enterprise and government markets.

McCarney will lead corporate strategy, market expansion, strategic partnerships, and go-to-market execution as CodeHunter builds out its footprint across software supply chain, endpoint, DevSecOps, and security operations environments.

He joins from Merlin Group, where he served as Chief Marketing Officer helping scale disruptive cybersecurity companies for government and commercial critical infrastructure markets. Earlier in his career, he helped position and scale one of the industry’s first cloud-based SASE and Zero Trust Network Access platforms as VP of Marketing at OPAQ Networks, later acquired by Fortinet, and held senior marketing and security leadership roles at Arxan Technologies and Unisys. 

“Stephen has spent his entire career helping category-defining cybersecurity companies translate technical innovation into market leadership…His experience scaling Zero Trust, SASE, cloud security, application security, and emerging technology companies will be instrumental as we expand Zero Trust for Code into a critical control layer for enterprise and AI security,” said Ken Ammon, CEO of CodeHunter.

McCarney points to timing as the opportunity: AI-generated code, autonomous development tools, and machine-speed attacks are testing the assumptions behind traditional detection and software supply chain security, the exact gap Zero Trust for Code is built to close. 

Read Stephen’s thoughts on joining the CodeHunter team on LinkedIn. 

CodeHunter Behavioral Risk Brief cover for AI Data Thieves, July 2026, for the regulated-enterprise CISO

Behavioral Risk Brief: AI Data Thieves

/in , /by

The Claim

Governance frameworks that treat marketplace listing or basic scanning as sufficient validation create systemic risk when agentic systems execute functionality without independent behavioral verification. Zero Trust for Code addresses this by enforcing behavioral controls at execution, ensuring that what an AI skill or agent-based artifacts does is verified rather than assumed from where it was found.

The Incident

ESET’s H1 2026 Threat Report found that nearly 900,000 AI agent skills that were analyzed, more than 25,000 were flagged as suspicious and over 3,000 were confirmed malicious, with the malicious count growing from roughly 600 to over 3,000 in a three-month window. These skills carried capabilities including command execution, credential loading, code injection, and obfuscation, the same functions that support legitimate agent tasks. Researchers also found that some skills marketed as security scanners performed only superficial checks, giving operators a false sense of protection. Separately, the report documented a new technique called AI-fix, a variant of the ClickFix pattern that uses fake troubleshooting pages hosted on services associated with Anthropic, OpenAI, and Microsoft to convince users to run malicious commands, contributing to a 108 percent year over year rise in ClickFix detections overall.

The Governance Failure

The governance failure is not the existence of malicious skills, but the absence of controls that validate what a skill will do once an agent is permitted to invoke it. Organizations evaluating agentic AI tools often rely on marketplace presence, download counts, or a passed scan as indicators of safety. These signals confirm that a skill was reviewed once, not that its behavior remains within acceptable bounds every time it executes.

This challenge comes from how agent frameworks are built. Skills inherit the permissions of the agent that invokes them, and agents frequently operate with broad access to credentials, files, and external systems in order to complete tasks. A skill that behaves as documented during review can still execute commands, access credentials, or move data in ways no one explicitly authorized, because the framework does not distinguish between intended task execution and unauthorized action.

The underlying breakdown is the lack of enforceable policy governing what a skill is allowed to do at the moment it runs. Scanning at intake tells an organization what a skill contains. It does not tell them what the skill will attempt once it has the agent’s permissions and a live task in front of it.

As agent adoption accelerates, this distinction becomes the whole of the problem. An organization can document every skill it approved and still have no record of what those skills actually did once deployed. Trust assigned at intake cannot substitute for authorization enforced at execution.

This is a structural problem that extends well beyond agentic AI. For a deeper look at why the trust decision consistently happens at the wrong point in the execution lifecycle, see Why The Trust Decision Happens At The Wrong Moment.

The Regulatory and Business Exposure

  • Unauthorized data access and exfiltration through agent-executed skills.
  • Credential theft and malware execution inside agent workflows, bypassing controls built for software installs.
  • Social engineering exposure through AI-fix pages abusing trusted AI platform domains.

What Your Auditor Will Ask

  • How do you validate the behavior of an AI skill or plugin before an agent is permitted to invoke it?
  • How do you distinguish a skill that performs a genuine security check from one that only appears to?
  • What controls detect an agent executing commands, accessing credentials, or transferring data outside its intended task?
  • How do you prevent a fake troubleshooting or verification page from inducing a user or an agent into running unauthorized commands?
  • What evidence do you maintain that agent-executed skills were evaluated against policy before running, rather than reconstructed after an incident?

A consistent signal is the disconnect between marketplace listing and skill behavior. Skills that pass basic scanning continue to carry actions that were never evaluated against what is consider acceptable execution.

Zero Trust for Code Value

Zero Trust for Code introduces enforcement at the point where an AI skill or agent-executed artifact actually runs, ensuring that capabilities such as command execution, credential access, or code injection are evaluated against defined policy regardless of whether the skill passed a marketplace scan or carries a security label.

This directly addresses the governance weakness exposed by the growth in malicious AI skills: the assumption that a passed scan or marketplace presence indicates safe behavior going forward. By enforcing behavioral constraints at execution, organizations can prevent a skill from exfiltrating data, loading credentials, or executing unapproved commands even when nothing about it was flagged during initial review.

The result is a governance model where agent behavior is evaluated against policy every time it executes, not inherited from a one-time scan or platform trust, holding a skill’s actual execution to the same standard as its claimed function throughout its use.

Governance Action Brief

  • Establish governance controls that validate AI skill behavior independently of marketplace listing or scan status.
  • Require continuous verification of command execution, credential access, and data movement performed by agent-executed skills.
  • Enforce execution policies for AI agents, browser extensions, and automation tooling that consume third-party skills.
  • Monitor social engineering patterns, such as fake troubleshooting pages, that pressure users or agents into running unauthorized commands.
  • Treat agentic AI environments as high-value systems requiring behavioral enforcement at execution, not only at admission

Sources

Analysis based on Help Net Security reporting (July 8, 2026) on ESET’s H1 2026 Threat Report covering malicious AI skills and ClickFix variants, CodeHunter Labs evaluation of governance gaps in agentic AI execution and marketplace trust models

Download the PDF. 

CodeHunter Behavioral Risk Brief cover for New Avalon Framework, July 2026, for the regulated-enterprise CISO

Behavioral Risk Brief: New Avalon Framework

/in , /by

The Claim

When credential theft, lateral movement, persistence, and ransomware deployment are governed as isolated risks, organizations lose sight into how those activities play into
business-impacting outcomes. Zero Trust for Code addresses this by enforcing behavioral policy across execution sequences, ensuring that software actions remain constrained regardless of where they occur within the attack chain.

The Incident

Researchers have identified a modular malware framework known as Avalon that consolidates credential harvesting, reconnaissance, lateral movement, remote access, recovery disruption, and ransomware deployment into a single integrated platform. Distributed through a sophisticated phishing campaign, Avalon uses trusted system utilities, in-memory execution techniques, and defense evasion mechanisms to reduce visibility while progressively expanding attacker control. Its ransomware component, CrownX, represents the final stage of a larger operational workflow designed to move from initial access to enterprise-wide impact with minimal interruption.

The Governance Failure

The governance failure is not that ransomware was deployed, but that organizations continue to manage execution risk as a collection of disconnected controls. Security programs often establish separate ownership for phishing prevention, credential protection, endpoint security, and recovery operations, while lacking unified enforcement over how actions progress between those stages. This creates opportunities for attackers to chain together authorized system behaviors into unauthorized business outcomes.

The issue becomes more significant when malware frameworks are designed to adapt their behavior based on environmental conditions, rather than relying on a single exploit or payload. Avalon evaluates defensive controls, adjusts execution patterns, collects credentials, and expands access over time before ultimately delivering ransomware. The attack succeeds because each step appears operationally manageable in isolation, while the cumulative impact remains insufficiently governed.

The underlying breakdown is the absence of policy enforcement over execution progression. Once code begins operating within the environment, there are limited controls preventing it from transitioning between phases of the attack lifecycle. As a result, organizations may identify individual indicators of compromise without preventing the overall sequence of events that lead to operational disruption, data loss, and ransomware deployment.

Frameworks like Avalon are built around this assumption. For a broader look at how sophisticated malware exploits disconnected controls across the attack lifecycle, see Advanced Threat Actors: How Sophisticated Malware Behaves Differently.

The Regulatory and Business Exposure

  • Consolidation of multiple attack functions into a single operational framework.
  • Increased likelihood of enterprise-wide compromise before detection thresholds are reached.
  • Reduced effectiveness of siloed security controls designed for individual attack stages.

What Your Auditors Will Ask

  • How do you correlate credential access, reconnaissance, and remote-control activity into a single investigation?
  • How do you detect abuse of legitimate administrative tools?
  • How do you identify simultaneous reductions in security controls and increases in privilege?
  • How do you detect ransomware preparation before encryption begins?
  • How do you recognize when low-risk events become a coordinated attack sequence?

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 each software action is allowed to execute, evaluating whether that action should run against defined policy rather than observing how it behaves once permitted. This means each stage of an intrusion, credential harvesting, lateral movement, or persistence, is subject to its own pre-execution evaluation rather than inheriting permission from prior activity.

This directly addresses the governance weakness exposed by Avalon, the ability to combine numerous authorized activities into a coordinated attack chain. Instead of correlating behavior after execution begins, Zero Trust for Code requires that each action clear a pre-execution trust decision, preventing a single permitted step from becoming the foundation for the next stage of compromise.

The result is a governance model where advancing from initial access to ransomware deployment requires clearing a distinct trust decision at every step, ensuring that no stage of the attack chain is permitted to execute on the strength of a decision made earlier in the sequence.

Governance Action Brief

  • Establish governance controls that evaluate execution sequences rather than standalone events.
  • Define behavioral boundaries for credential use, system discovery, and privilege expansion activities.
  • Implement enforcement points capable of interrupting attack progression before impact is reached.
  • Align security operations around lifecycle-wide risk rather than individual control categories.
  • Regularly validate that recovery, credential, and execution policies cannot be chained into unauthorized outcomes.

Sources

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

Download the PDF. 

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

CodeHunter Security Brief cover for Mistic Backdoor, June 2026, for the regulated-enterprise CISO

Security Brief: Mistic Backdoor

/in , , /by

The Claim

Security governance frameworks often focus on preventing initial compromise but lack enforceable controls over what occurs after access is established. This creates a structural gap where persistence, lateral movement, and preparation for ransomware deployment operate without constraint. Zero Trust for Code addresses this by enforcing behavioral limits on execution, ensuring that access cannot be leveraged to perform unrestricted actions.

The  Threat

A newly identified backdoor labeled “Mistic”, has been linked to the initial access broker KongTuke, which highlights this failure. Rather than delivering immediate impact, the malware is designed to establish long-term, low-visibility access within enterprise environments, enabling attackers to maintain persistent footholds and later sell that access to ransomware groups. The intrusion leverages trusted binaries to load malicious components into memory, imitates legitimate security tooling, and enables credential harvesting, file manipulation, and remote command execution, all without triggering traditional detection mechanisms

The Problem

The governance failure is not the use of sophisticated malware, but the absence of controls that constrain behavior once a system has been compromised. Most security models assume that preventing entry is the primary objective, while post-access activity is implicitly trusted if it originates from an authenticated or system-level process. This creates an environment where persistence mechanisms can operate with minimal scrutiny, even when they are clearly outside expected operational boundaries.

This issue is amplified in modern threat ecosystems where initial access is commoditized. Access brokers such as KongTuke specialize in establishing footholds and monetizing them, separating intrusion from exploitation. This division of labor means that the most critical phase of the attacks the maintenance and expansion of access which occurs over extended periods of time without triggering event-driven security responses. Systems continue to operate normally while unauthorized access is quietly preserved and prepared for downstream use.

The core breakdown is the absence of enforceable policy over system behavior during this intermediate phase. Organizations may detect known malware or block initial access but lack the ability to prevent compromised systems from executing unauthorized actions once foothold is achieved. This results in an environment where persistence is not only possible, but operationally sustainable, allowing attackers to remain embedded until monetization occurs.

The Impact

  • Persistent, unauthorized access enabling downstream ransomware deployment.
  • Loss of control over systems during the post-compromise, pre-impact phase.
  • Increased exposure due to commoditized access sold across threat actor ecosystems.
  • Reduced visibility into long-duration intrusions operating within normal system processes.

What to Watch For

  • Legitimate system processes performing actions outside expected operational roles.
  • Evidence of long-term access without corresponding business justification.
  • Credential harvesting or repeated authentication prompts without clear origin.
  • Systems maintaining outbound communication patterns inconsistent with their function.

A consistent signal is the divergence between system-level access and authorized activity. Processes operate within trusted contexts but produce outcomes that exceed defined operational intent, indicating that control is applied to access rather than behavior.

Surfacing what malware is actually designed to do at the execution layer is where that control becomes actionable. Here is what reverse engineering insights reveal about behavioral intent.

Zero Trust for Code Value

Zero Trust for Code introduces enforcement at the point of execution, ensuring that all actions, whether performed by trusted processes or compromised systems, are evaluated against defined behavioral policies before completion. This prevents attackers from leveraging persistent access to perform unauthorized operations, even when they operate within legitimate system contexts.

This directly addresses the governance gap exposed by access broker models: the lack of control over what happens after compromise occurs. By shifting enforcement to actions rather than access, organizations can disrupt the ability to maintain footholds, execute commands, and prepare environments for ransomware deployment.

The result is a governance model where persistent access does not equate to persistent control, ensuring that even stealthy, low-visibility intrusions cannot operate indefinitely without constraint.

CISO Action Brief

  • Establish governance controls that define acceptable system behavior after access is obtained.
  • Enforce policy constraints on execution for all processes, including system-level and trusted binaries.
  • Treat persistent access as a governed risk state requiring continuous validation, not a one-time event.
  • Monitor behavior patterns associated with long-duration presence rather than discrete attack events.
  • Align detection and response strategies to identify and dsrupt access maintenance, not just initial comrpomise.

Methodology & Sources

Analysis based on BleepingComputer reporting (June 24, 2026) on the Mistic backdoor and its linkage to the KongTuke initial access broker and CodeHunter Labs evaluation of governance gaps in post-compromise execution and persistence control.

Download the PDF