How Dual-Side Verification Protects Against Supply Chain Attacks

Why Single-Side Scanning Isn’t Enough

Traditional package registries scan code once — at upload time. If the registry is compromised, or if the package is modified after scanning, consumers have no way to detect it. The scan report reflects the state of the code at a single point in time, not what you actually download.

This is the gap that supply chain attacks exploit. A clean scan report means nothing if the artifact you receive has been altered.

The Dual-Side Model

SkillSafe uses a dual-side verification model with three independent checks:

1. Publisher Scan

Before sharing a skill, the publisher runs the SkillSafe scanner locally. The scanner performs AST-based static analysis on every file, checking for:

• Command injection — shell execution via subprocess, os.system, backtick interpolation, and similar patterns
• Data exfiltration — outbound HTTP requests, DNS lookups, environment variable access that sends data externally
• Obfuscation — base64-encoded payloads, eval/exec usage, encoded strings that decode to executable code
• File system abuse — writes outside the project directory, access to sensitive paths like ~/.ssh or credential stores
• Privilege escalation — attempts to modify system files, install global packages, or change permissions

The scan produces a structured report with a severity-rated list of findings. This report is attached to the skill version when shared.

2. Consumer Re-Scan

When someone installs a shared skill, the SkillSafe client automatically re-scans the downloaded archive. This produces a second, independent scan report from the consumer’s perspective.

The consumer’s scanner runs the exact same analysis as the publisher’s. It’s the same code, the same rules, the same AST parsing. The only difference is who ran it and when.

3. Server-Side Comparison

The server receives both scan reports and compares them along two axes:

Tree hash verification — Each scan report includes a SHA-256 tree hash computed over the raw bytes of the skill archive. If the publisher’s tree hash doesn’t match the consumer’s tree hash, the archive was modified in transit or at rest. This is a hard failure.

Finding comparison — The server compares the sets of security findings from both reports. If the publisher’s scan found 2 low-severity warnings but the consumer’s scan found an additional critical finding, something changed between publish and install.

The comparison produces one of three verdicts:

• Verified — Tree hashes match and findings are consistent. The skill is safe to use.
• Divergent — Tree hashes match but findings differ. This can happen if scanner versions differ, but warrants investigation.
• Critical — Tree hashes don’t match. The archive was tampered with. Do not use this skill.

Why Tree Hashes Matter

A tree hash is a SHA-256 digest computed over the entire skill archive (the .zip file). Unlike content-based hashes that check individual files, the tree hash covers everything: file contents, file names, directory structure, and metadata.

This means an attacker can’t:

• Replace a single file without changing the hash
• Add a new file (like a malicious post-install script) without detection
• Modify file permissions or metadata without detection
• Reorder or rename files to disguise changes

The tree hash is computed client-side before upload and again client-side after download. The server stores and compares hashes but never computes them — it has no opportunity to forge a matching hash.

What Attacks Does This Prevent?

Attack Vector	How It’s Detected
Registry compromise (modified archive on server)	Tree hash mismatch at consumer re-scan
Man-in-the-middle (modified archive in transit)	Tree hash mismatch at consumer re-scan
Publisher key theft (attacker publishes as publisher)	Consumer re-scan reveals new findings
Dependency confusion (name squatting)	Namespace verification + scan findings
Time-of-check to time-of-use	Consumer scans the actual downloaded bytes

Try It Yourself

You can see dual-side verification in action with any shared skill:

# Publisher side
skillsafe scan ./my-skill
skillsafe save ./my-skill --version 1.0.0
skillsafe share @myns/my-skill --version 1.0.0

# Consumer side (verification happens automatically)
skillsafe install @myns/my-skill --version 1.0.0

After installation, run skillsafe info @myns/my-skill to see the verification status, including both scan reports and the comparison verdict.

Read more about the security model on our Security page or check the documentation for the full API reference.