What SBOM, SLSA, and code signing leave uncovered and how behavioral verification closes the gap at execution. Supply chain attack analysis, third-party code risk, and enforcement.

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

""

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 Security Brief cover for Crypto Heist, June 2026, for the regulated-enterprise CISO

Security Brief: Crypto Heist

/in , , /by

The Claim

Governance frameworks that rely on external trust signals create a control gap when those signals can be intentionally manipulated. When trust is inferred from consensus rather than verified through enforceable policy, organizations lose control over what software is permitted to execute. Zero Trust for Code addresses this by shifting from perception-based trust to pre-execution enforcement, ensuring that credibility cannot override behavioral governance.

The Threat

A large-scale cryptocurrency theft campaign demonstrates this failure, where attackers constructed a coordinated reputation ecosystem across GitHub, SourceForge, YouTube, and malware analysis platforms to promote malicious tools. These tools were presented as legitimate crypto utilities, supported by inflated downloads, fake engagement, and manipulated through what was thought to be safe classifications. Once executed, the software deployed a clipboard hijacker that intercepted and replaced cryptocurrency wallet addresses, redirecting transactions to attacker-controlled accounts. The campaign’s effectiveness was driven not by technical evasion, but by successfully manufacturing trust across multiple independent systems.

The Problem

The governance failure is rooted in the absence of controls that validate software behavior independently of reputation signals. Organizations implicitly trust software that appears validated by external ecosystems but lack mechanisms to verify whether that trust is justified at the point of execution. This results in a misalignment between how trust is assigned and how risk is controlled, allowing manipulated credibility to bypass internal safeguards.

This issue is compounded by the widespread use of distributed validation channels such as repositories, content platforms, and security scanning tools. They are not governed as unified trust sources. Attackers can influence each independently, creating a reinforcing loop where perceived legitimacy increases with each additional signal. Without centralized governance over software acceptance criteria, these signals collectively override internal policy, effectively outsourcing trust decisions to systems that are not designed to enforce integrity.

This creates a condition in which software is permitted to execute based on perceived credibility rather than verified behavior. Once executed, there are no mechanisms to prevent high-impact actions like clipboard manipulation from occurring. The failure is not the presence of malicious code, but the lack of enforceable controls that ensure software actions remain within defined policy boundaries, regardless of how trustworthy it appears.

Sophisticated threat actors are increasingly building campaigns around trust manipulation rather than technical exploits. Understanding how advanced malware behaves differently is essential context for why reputation signals keep failing as a control.

The Impact

  • Unauthorized execution of software based on manipulated external trust signals.
  • Financial loss through ungoverned transaction manipulation behavior.
  • Breakdown of assurance in reputation-based validation systems.
  • Increased regulatory exposure due to lack of enforceable software control.

What to Watch For

  • Software adoption driven by external ratings, downloads, or social validation signals.
  • High-trust artifacts with inconsistent or unverifiable development provenance.
  • Discrepancies between reputation indicators and actual runtime behavior.
  • Security tools or platforms providing conflicting or overly permissive trust signals.

A consistent signal is the divergence between assigned trust and enforced control. Systems allow execution based on perceived legitimacy, but fail to validate whether resulting actions align with acceptable operational boundaries.

Zero Trust for Code Value

Zero Trust for Code introduces a control model where trust is established through enforceable policy at execution, not inferred from external validation signals. By evaluating actions before they complete, it ensures that even widely trusted or highly rated software cannot perform unauthorized behavior.

This directly addresses the governance gap exposed in this campaign: the lack of control over what trusted code is allowed to do. Instead of relying on reputation, Zero Trust for Code enforces constraints on execution outcomes, ensuring that software actions remain within defined boundaries regardless of how trust was initially assigned.

The result is a security and governance framework where trust is continuously verified through behavior, enabling organizations to maintain control even when external ecosystems are compromised or manipulated at scale.

CISO Action Brief

  • Establish governance policies that define acceptable software behavior independent of reputation or source.
  • Eliminate reliance on external validation signals as a primary control mechanism for execution decisions.
  • Enforce behavioral constraints on all executed code, regardless of perceived credibility.
  • Centralize trust decisioning to ensure consistency across distributed validation sources.
  • Monitor and audit execution outcomes rather than relying solely on pre-ingestion validation.

Methodology & Sources

Analysis based on Dark Reading reporting (June 22, 2026) on the cryptocurrency heist leveraging a multi-platform fake reputation campaign and CodeHunter Labs evaluation of governance failures in reputation-based trust systems.

Download the PDF

CodeHunter Security Brief cover for Red Hat NPM supply chain attack, June 2026, for the regulated-enterprise CISO

Security Brief: Red Hat NPM and the Mini Shai-Hulud Supply Chain Malware

/in , /by

The Claim

Trusted developers and maintainers are now a primary attack surface. When access to a legitimate developer account enables malicious code through established software ecosystems, trust decisions are compromised before execution even begins. Zero Trust for Code addresses this by validating not just how code behaves at runtime, but whether its origin, build context, and delivery pipeline have remained trustworthy throughout the entire software lifecycle.

The Threat

A recent supply chain attack involving multiple Red Hat npm packages demonstrates how quickly trusted ecosystems can be weaponized when developer identity is compromised. The attack originated from unauthorized access to a Red Hat employee’s GitHub account, which was used to introduce malicious code into widely consumed npm packages. These packages were then distributed through legitimate channels, embedding malicious code directly into developer environments. The malware, “Mini Shai-Hulud”, targets development workflows, harvesting credentials and sensitive data from build environments while operating under the appearance of trusted dependencies. Unlike traditional malware delivery, this attack bypasses a user’s decision making entirely. The compromise occurs upstream, where developers and systems implicitly trust package sources, maintainers, and update mechanisms.

The Problem

  • Trust Anchored to Identity: Package trust is derived from maintainer identity and repository access, not from verification of code integrity over time.
  • Pre-Execution Compromise: Malicious code is introduced before deployment, avoiding the need to evade endpoint or runtime defenses.
  • Pipeline Blind Spot: Most CI/CD pipelines are not designed with the intent to capture the behavioral aspects of code execution, they are primarily focused on building executable and deployable code.
  • Transitive Risk Amplification: A single compromised package propagates across thousands of downstream applications automatically. Security models establish trust at the point of access but do not revalidate that trust as code evolves through the software lifecycle.

Once established, trust becomes persistent. Packages, updates, and dependencies are treated as extensions of that initial decision, regardless of whether the underlying code has changed or been compromised.

This creates a structural condition where malicious code can enter through legitimate channels and execute within trusted workflows without resistance.

The failure is not in individual controls, but in the assumption that trusted sources remain trustworthy over time. Build pipelines, developer environments, and automated processes inherit this trust and execute code accordingly, often with elevated privileges. Zero Trust for Code addresses this by ensuring that trust is continuously validated across the software lifecycle, not implicitly carried forward from a single upstream decision.

The Impact

  • Trusted pipelines executing attacker-controlled logic.
  • Credential exposure within development and build environments.
  • Rapid, large-scale propagation through automated dependency updates.
  • Loss of integrity in software supply chains and internal codebases.

What to Watch For

  • Unexpected changes in widely used dependencies without corresponding version trust validation.
  • Build processes accessing external or unusual endpoints during dependency installation.
  • CI/CD pipelines executing code from newly updated or low-confidence package versions.
  • Developer credentials or tokens being accessed during build-time execution.

The key signal is not abnormal runtime behavior, but rather unexpected trust transitions in the software supply chain.

Zero Trust for Code Value

Zero Trust for Code introduces verification capabilities before, during, and after execution, ensuring that trust is not assumed at any stage of the software lifecycle.

By validating software provenance and enforcing behavioral constraints across development pipelines, organizations can:

  • Prevent compromised code from entering production environments.
  • Detect unauthorized modifications within trusted ecosystems.
  • Maintain control over software integrity even when upstream sources are attacked.

This shifts security from reactive containment to proactive assurance of software trustworthiness. This transforms supply chain risk from an uncontrollable exposure, into a governed, enforceable control point.

It establishes clear ownership over where trust is defined, how it is validated, and when it must be re-evaluated across the software lifecycle. This closes the gap between assumed trust and proven integrity, aligning security controls with the speed and scale of modern software delivery.

CISO Action Brief

  • Implement code provenance verification across all third-party dependencies.
  • Enforce trust validation for package updates, not just initial adoption.
  • Restrict CI/CD execution privileges to limit exposure from compromised dependencies.
  • Monitor and log build-time behavior, especially external communications or credential access.
  • Establish policy controls for software lineage, including version trust and maintainer validation.

Begin with high-risk environments such as build systems and developer workstations, where compromised code has the greatest systemic impact.

Methodology & Sources

Analysis based on reporting of the Red Hat npm package compromise and Mini Shai-Hulud malware activity(June 2026), combined with CodeHunters evaluation of software supply chain risk, and dependency trust models.

Download the PDF

Digitally connected supply chain network illustrating complex software execution dependencies and the need to control code behavior across distributed systems

Transportation Industry Software Supply Chain Security: Why Signing and SBOMs Are Not Enough

/in /by

The transportation industry runs on digital infrastructure. Automated ports, cargo tracking systems, logistics management software, GPS-guided fleets: the efficiency gains from digitization are real, and the dependency is deep. So is the exposure. Cyberattacks targeting transportation do not just disrupt operations. They can affect national security, public safety, and the global movement of goods that other industries depend on. The attack surface is wide, the systems are deeply interconnected, and many of the controls used to govern software trust in this sector were designed for a simpler threat environment than the one that exists today.

Third-Party Vendors Are a Trusted Entry Point for Untrusted Code

Transportation companies rely on third-party vendors for logistics software, cloud services, IoT monitoring, and dozens of other operational dependencies. Each of those relationships is a channel through which software enters the environment, and most of those channels are trusted by default.

The SolarWinds attack in 2020 is the clearest illustration of what that trust assumption costs. Compromising a single software vendor exposed 18,000 organizations downstream, including government agencies, enterprises, and critical infrastructure operators who had all vetted and approved that supplier. The code that delivered the payload was signed. It came through the expected update channel. It passed every control designed to evaluate its origin. What those controls did not evaluate was what the code would do when it was executed. That is the gap Zero Trust for Code is built to close.

OT Systems Carry Unique Execution Risk

The convergence of IT and operational technology in transportation creates a security challenge that generic enterprise controls were not designed to address. Autonomous vehicles, smart port systems, and rail networks all depend on OT that was often built without cybersecurity in mind, is expensive and operationally disruptive to update, and is deeply connected to the physical systems that move people and cargo.

The NotPetya attack in 2017 made the consequences of OT compromise concrete. Maersk’s entire shipping operation was crippled, with an estimated $300 million in losses and operations halted across ports worldwide. That attack entered through IT systems and moved laterally into OT environments. Pre-execution behavioral intent analysis evaluates what code will do before it is deployed, including whether its behavioral capabilities are appropriate for the specific environment where it will execute.

What SBOM and Signing Leave Uncovered in Transportation

Software bill of materials documentation and code signing represent meaningful progress in supply chain governance. An SBOM tells you what components are in the software. Code signing confirms who published it. Neither tells you what those components will do when they execute in your specific environment.

A signed update from a compromised vendor is still a compromised update. An SBOM that accurately lists every dependency still cannot tell you whether those dependencies will attempt to communicate with an external command-and-control server when deployed on a port management system. The control that answers what SBOM and signing leave open is pre-execution behavioral analysis: deconstruct the artifact, surface its behavioral capabilities, and issue a deterministic execution verdict before deployment advances.

The CodeHunter Solution for Transportation

CodeHunter helps transportation organizations span the gap between their existing security controls and the execution of governance those controls do not cover. Our platform automatically evaluates executable artifacts at speed and at scale. Every artifact is evaluated for behavioral intent before it is authorized to execute. The verdict is deterministic: Allow, Block, Contain, or Escalate. The evidence is forensic. The decision is auditable, and it happens before the first operational system is exposed.

Zero Trust for Code does not slow down software deployment in transportation environments. It ensures that what gets deployed has earned the right to execute. Find out how CodeHunter integrates into your existing security stack.

Secured data exchange between systems illustrating third-party software execution being verified and controlled before code is allowed to run

Third-Party Integration Risk Management: Monitor to Mitigate

/in /by

In the interconnected world of modern business, managing and mitigating cybersecurity risks posed by third-party vendors and partners has become a critical concern. Breaches can- and do- occur through less secure external entities, posing significant risks to organizations that rely on these vendors. Effectively managing these risks is crucial, as the security of an organization is often only as strong as its weakest link.

Read more

Interconnected circuitry forming a padlock, representing secure control over software execution and the verification of code behavior before it runs

Software Supply Chain Security: Why Pre-Execution Defense Is the Missing Layer 

/in , , /by

Software supply chain attacks are on the rise, and the reason is straightforward. A successful attack on any single link in the chain can spell disaster downstream. As software becomes more complex and interconnected, attackers have more entry points, more trusted channels to exploit, and more cover for the code they introduce.

The deeper problem is structural. Most cybersecurity solutions available today are built to detect known threats. By the time a security team identifies a new attack, the effects have already traveled down the chain. Reactive defenses that wait for something to look wrong are not a supply chain security strategy. They are a cleanup plan.

Defending software supply chains requires answering a question that existing tools were never designed to ask: what will this code do when it executes?

Trusted Sources Are Not Trusted Behavior

Threat actors approach supply chain attacks by undermining code signing, forging their way into a software supply chain under the guise of a known and trusted author. The fundamental problem is that organizations extend trust based on where code came from rather than what it will do.

CodeHunter operates on a different principle: every artifact is untrusted by default, regardless of its source. Where a manual check or preconfigured rule might wave through code from a trusted vendor, CodeHunter’s pre-execution behavioral analysis evaluates what that code is capable of doing before it is allowed to run, every time, without exception.

Software updates present the same risk. A threat actor who compromises a vendor’s update pipeline delivers malicious behavioral capability through a channel the target organization has explicitly trusted. Combing through every update manually would be prohibitively slow and expensive. CodeHunter deconstructs the artifact’s behavior automatically, issuing a deterministic verdict in a fractionof the time it would take an analyst to complete the same review.

Open-Source Code Is Not an Exception

Compromised open-source code is one of the most underestimated supply chain risks. The Linux backdoor discovered in the XZ Utils compression library is a clear example: a single contributor embedded a backdoor into widely trusted code that had been in use for years. Researchers caught it before it reached production systems, but that outcome was fortunate rather than systematic.

The sheer scope of open-source dependencies makes manual review impractical at scale. CodeHunter can be configured to automatically scan entire directories and networks, locally or in the cloud, to identify behavioral capabilities that should not be there. The question is never whether the code looks familiar. The question is what the code will do.

What Humans Miss, Behavioral Intent Analysis Catches

Valid credentials were the preferred initial access technique of cybercriminals last year, with a 71% increase in attacks leveraging stolen account access. Information stealers that harvest those credentials are often delivered through code that looks entirely legitimate. CodeHunter’s pre-execution behavioral analysis evaluates what code is capable of doing at the artifact level, not the filename level. Suspicious behavioral capability is surfaced regardless of how the artifact is packaged, named, or signed.

Unknown Threats Have Behavioral Signatures Too

Not every supply chain threat arrives with a known fingerprint. Behavioral intent analysis does not depend on prior knowledge of the threat. It deconstructs the artifact to surface what it is programmatically designed to do, and a trojan that has never been catalogued still has behavioral characteristics that are present in the artifact before it ever runs.

The Cost of Letting Threats Sit Undetected

The SolarWinds attack remains the clearest illustration of what delayed detection costs. Eighteen thousand customers unknowingly downloaded a malicious update, and the intrusion went undetected long enough to cause an estimated $90 million in insured losses. IBM put the average cost to remediate a software supply chain compromise at $4.63 million in 2023. The earlier a malicious artifact is identified, the less damage it causes, and CodeHunter is designed to catch artifacts at the threshold, before they execute, not after the damage is done.

Empower Your Software Supply Chain Security

CodeHunter’s combination of scalability, automation, and pre-execution behavioral analysis makes it the practical defense for organizations that cannot afford to let signed, trusted-looking code run unchecked. Speak with our team to learn more about how CodeHunter applies Zero Trust for Code to software supply chain security.