Insights

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

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

Security Brief: WordPress CDN Breach

The Claim

Security models that rely on trusted delivery infrastructure assume that software served from legitimate domains retains its integrity over time. When distribution channels become the attack surface, that assumption collapses. Zero Trust for Code addresses this by verifying the integrity and intent of executed code regardless of its delivery source, ensuring that trust is not implicitly inherited from infrastructure.

The Threat

A supply chain attack targeting WordPress plugins such as OptinMonster, TrustPulse, and PushEngage, demonstrate how trusted distribution channels can be weaponized. Attackers tampered with JavaScript files served via the vendor’s CDN, and injected malicious code that executed only when a logged-in administrator loaded the site. Once triggered, the script leveraged the admin’s session to create unauthorized administrator accounts and deploy a hidden backdoor plugin, granting persistent remote access. The attack affected a plugin ecosystem reaching over 1.2 million websites, with the malicious payload designed to evade detection by remaining inactive for normal users and hidden from administrative interfaces.

The Problem

  • Trusted Distribution Risk: Code served from legitimate CDN endpoints is implicitly trusted, even when integrity is compromised upstream.
  • Session Exploitation: Attacks increasingly leverage valid authenticated sessions, making malicious actions indistinguishable from legitimate administrative activity.
  • Execution Origin Blind Spot: Security controls fail to validate where code originates at execution time versus where it is hosted.
  • Lifecycle Integrity Gap: Software integrity is not continuously verified as it moves through delivery, rendering downstream environments vulnerable.

The constraint failure appears at the boundary between delivery and execution. Organizations treat trusted sources, such as vendor CDNs, as static anchors of integrity, assuming that content delivered through them reflects intended functionality. This model breaks when attackers compromise the distribution layer itself, turning legitimate delivery mechanisms into propagation channels for malicious behavior.

This is the same gap supply chain attacks have exploited repeatedly. Signing confirms a publisher. It doesn’t confirm behavior.

What distinguishes this attack is its reliance on authorized context to execute unauthorized outcomes. The injected scripts do not exploit vulnerabilities in the traditional sense. Instead, they operate within valid administrator sessions, using legitimate tokens and workflows to escalate access. This bypasses many detection mechanisms because actions appear operationally correct, even as they produce adversarial outcomes.

The Impact

  • Full administrative takeover of affected websites without exploiting traditional vulnerabilities.
  • Persistent unauthorized access via concealed backdoor plugins.
  • Large-scale exposure across over a million downstream sites through shared dependencies.
  • Reduced ability to distinguish legitimate activity from attacker-controlled actions.

What to Watch For

  • Administrative actions without corresponding operator intent.
  • Scripts loaded from trusted domains initiating privileged operations.
  • Presence of unknown or hidden plugins not visible in standard dashboards.
  • Outbound communication to unfamiliar domains triggered during admin sessions.

A consistent signal is the divergence between authorized execution context and actual intent. Actions performed within legitimate sessions begin to produce outcomes that exceed operational expectations, indicating that trust in execution context alone is no longer sufficient for validation.

Zero Trust for Code Value

Zero Trust for Code introduces enforcement at the moment code executes, ensuring that actions initiated by scripts, regardless of its origin, are validated against defined behavioral policies before completion. This eliminates reliance on the assumption that trusted delivery channels guarantee safe execution.

By eliminating complete trust from infrastructure and instead governing it in verified execution behavior, organizations gain control over actions performed within privileged contexts. Even when code is delivered through legitimate channels and executed within valid sessions, its outcomes remain subject to enforcement.

This model transforms supply chain risk from an uncontrollable exposure into a governed control point, ensuring that integrity is continuously validated across delivery and execution layers, and preventing unauthorized actions from occurring even in trusted environments.

Zero Trust for Code: Trust but verify.

CISO Action Brief

  • Enforce behavioral validation for administrative actions, regardless of session legitimacy.
  • Implement integrity checks for externally served scripts, including CDN-delivered assets.
  • Restrict and monitor privileged operations initiated from client-side execution contexts.
  • Establish detection for invisible or self-concealing persistence mechanisms.
  • Prioritize enforcement on high-impact web platforms and externally dependent services.

Methodology & Sources

Analysis based on reporting from The Hacker News (June 15, 2026) on the WordPress plugin supply chain attack, research from Sansec on CDN-based code injection techniques, and CodeHunter Labs evaluation of execution integrity risks in external software components.

Download the PDF