Trust model

A supply-chain security tool asks you to trust it with the most sensitive metadata you have: your full dependency graph. lockwarden’s answer is architectural, not contractual — there is no backend to send it to.

Local-first, by construction

• No accounts. There is nothing to sign up for.
• No telemetry. No analytics, no crash reporting, no phone-home — ever.
• No API backend. Advisory data (the OSV snapshot and incident bundles) ships vendored inside the npm package and updates via npm releases. The release cadence is the data pipeline.

This stopped being a purely philosophical stance in 2026: CI-targeting malware now identifies hosted security agents, kills their containers, and poisons /etc/hosts to block their telemetry domains. A tool with no endpoint has no endpoint to attack, block, or subpoena.

The only network calls

Exactly one feature needs the network: delta comparison. To score what a version bump introduced, lockwarden must fetch the previous version’s tarball from the registry.

Operation	When	What is fetched
audit --diff <ref>	PR flow	Previous tarball of each package whose resolved version changed
audit --deep	Scheduled deep scans	Previous tarball of every dependency

That’s the complete list. check, drift, scan, secrets, and plain audit perform zero network I/O. Fetched tarballs are cached in ~/.lockwarden/cache, so each version is fetched at most once across runs.

The --offline guarantee

--offline is how you prove the claim rather than take it on faith:

npx lockwarden audit --offline   # exits 2 if any network call is even attempted

Enforcement is structural: all network I/O in the codebase goes through a single chokepoint module, and that chokepoint hard-fails with exit code 2 the moment a fetch is attempted while --offline is set. The behaviour is locked in by tests that fail the suite on any network attempt — offline is a tested invariant, not a best effort. A warm tarball cache also counts as offline: only an actually required fetch trips the guarantee.

For airgapped or paranoid CI, add --offline to every invocation and the run becomes a verifiable no-network operation.

Provenance is informational — never a pass signal

lockwarden reports SLSA provenance where present, but never treats it as a green light. The June 2026 Miasma compromise published Trojanized packages with valid provenance, generated by the victim’s own hijacked GitHub Actions pipeline. Provenance tells you which pipeline built the package — not whether that pipeline was compromised. Version-to-version structural anomaly (new install hook, 25x size jump, new transitive dep in a patch) is the honest signal, and it’s what the scoring model weights.

Detection, not enforcement

lockwarden never blocks installs and never proxies the registry. It detects, grades, and reports; the exit code feeds your policy (branch protection, pipeline gates). Running enforcement infrastructure would mean running infrastructure — and the whole point is that there isn’t any.

Our own dependency tree is part of the model

A tool that audits dependency trees should survive its own audit. The published CLI has 3 runtime dependencies (commander, semver, yaml) under a hard project budget of fewer than 10 total transitive dependencies — and CI runs lockwarden audit against the lockwarden repository itself on every build. Every release is published with npm provenance and an explicit files allowlist, and the tarball contents are reviewed before publish. (Yes, we just said provenance isn’t a pass signal — publish it anyway, treat it as one more informational datum.)