Product · Supply Chain Guard (Hlif) · open sensor
Roadmap· Q1 2027 GAState-aware defense against propagation worms.
Mini Shai-Hulud carried a valid signature. The build pipeline was legitimate. Every existing scanner returned green. It still spread to 170+ packages, and the established defenses took 14 hours to catch it. Supply Chain Guard is designed to score every npm/PyPI install with a divergence receipt (registry mirror, PR bot, and publisher-side HITL roadmap Q4 2026/Q1 2027): not "is this package known-bad," but "does this version diverge from prior versions by the same maintainer in patterns that match attack signatures."
Spec live. Reference implementation in progress. Q1 2027 general availability. The architecture was written down on March 17, 2026, 55 days before Mini Shai-Hulud shipped.
Case study · Mini Shai-Hulud
May 11, 2026: a worm that played by the rules.
On May 11, a malicious version of a routine JavaScript package was published to npm. The build pipeline that produced it had been compromised, not the maintainer. The package carried a valid cryptographic attestation. Within hours it had self-propagated to more than 170 downstream packages, including ones maintained by Mistral AI and Guardrails AI. Established supply-chain scanners caught it about fourteen hours later, after the worm had exfiltrated AWS credentials, GitHub tokens, and npm publish keys from affected machines.
The worst part: by the rules of the existing verification systems, nothing was wrong. The signature was valid. The publisher was the right account. The build attestation matched. Every gate that existed, returned green.
The pattern that wouldhave flagged it: this version's behavior diverged sharply from prior versions by the same maintainer. New egress endpoints. New post-install hooks. New cryptographic key reads. No prior history of any of it. That divergence is the signal, and it's available at install-time, not fourteen hours later in a scanner's queue.
Retrospective match
# Spec written
2026-03-17
# Mini Shai-Hulud published
2026-05-11
# Days between
55
# Would SCG have caught it?
design says yes (divergence pattern matches; not yet validated against shipped engine)
# Time-to-detect (SCG)
install-time, not 14h later
The match between the spec and the attack is more on-the-nose than is comfortable. State-aware detection isn't a coincidence; it's what catches things that don't look like prior things by the same maintainer, regardless of whether anyone in the world has seen them before. That's the whole point. See the founder's account in the founder essay →
Architecture · four layers + a substrate
Defense at every surface a package crosses.
Layer 01
Registry Mirror
Roadmap · Q1 2027
An npm-protocol-compatible mirror in front of your package installs. One config line in .npmrc: every install flows through state-divergence detection. Compromised version: install blocked or HITL-gated before it reaches the developer's machine. Zero workflow change for the team.
SynOI Registry Mirror →Layer 02
Pull Request Bot
Roadmap · Q4 2026
A GitHub App that comments on every package-lock change with divergence verdicts. Catches the Mini Shai-Hulud class at PR review: before the merge, before the CI install, before anyone runs the code locally. The reviewer sees `[SCG] divergence 0.91 · new egress endpoint detected` next to the diff.
Supply Chain PR Bot →Layer 03
Lockfile Verifier
Roadmap · Q1 2027
Runs at CI install-time. Compares the proposed install set against the divergence baseline for each dependency. Fails closed when the score crosses your tenant policy. Receipts get attached to the CI artifact and persist for the lifetime of the build.
CI-side install gate →Layer 04
Verified Publisher
Roadmap · Q1 2027
Wraps `npm publish` and `python -m twine upload`. Every release requires out-of-band approval before a stolen token can post: mobile, Slack, SMS, or desktop confirmation, with the diff and the divergence score in the prompt. A stolen npm token alone is no longer sufficient to ship malicious versions.
Publisher-side HITL →Substrate · public OID resolver
Every layer above resolves divergence against a content-addressed package attestation service, SynOI OID Resolver. Public, free to query, federated. DNS-for-software-provenance: any package manager, any CI, any developer can resolve a published OID to its divergence history without paying SynOI a cent.
Differentiation
Scanners ask "is this known-bad?"
SCG asks "does this diverge?"
Socket, Snyk, and Aikido are good products. They scan packages against known-bad indicators and CVE feeds. They're the right answer for the threats they're built for. SCG is built for a different question: how does this version compare to the prior history of the same maintainer? Different signal, different latency, complementary defense.
Detection model
Known-bad indicators · CVE feeds · IOC matching
State-divergence scoring against the maintainer's prior history
Time to detect
Hours to days (scanner queue + IOC publication)
Install-time (gateway), PR-time (bot), publish-time (HITL)
Receipt format
Proprietary dashboards · platform-locked
Hybrid-signed (Ed25519 + ML-DSA-65) Decision Receipts · verifiable offline · open spec
Publisher side
Read-only · cannot prevent a stolen token from publishing
HITL gate on the publish itself · token theft alone is not enough
Pilot the layers that ship before GA.
The PR Bot ships Q4 2026. Registry Mirror, Lockfile Verifier, and Verified Publisher follow in Q1 2027. Design partners get the staged drops and the spec under NDA.