A committable lockfile for your domain's third-party scripts. cipherwake.vendors.json

Vendor lockfile is the JSON artifact produced by npx pqcheck vendors export. It snapshots the list of third-party script origins your domain loads so you can commit it to your repo and fail PRs that introduce new origins. Like package-lock.json for vendor scripts.

What we measure

The set of distinct third-party origins (https://<host>) observed loading scripts on your domain at the time of the export. The lockfile is a domain-level snapshot — one file per monitored domain.

Free tier generates and uses lockfiles freely (1 monitored domain). Founder Pro adds a second mode: vendors sync merges your dashboard-managed approved-vendor allowlist into the lockfile, so the file represents both what was observed AND what you intentionally approved.

How we measure it

vendors export calls the public /api/deps endpoint — the same data that powers pqcheck deps <domain> and the Vendor Surface view on /r/<domain>. Origins are normalized to https://<hostname> form (path / query / fragment stripped, case lowercased, port stripped if default).

vendors check re-fetches current origins from the same endpoint and computes set difference vs the committed lockfile:

• New origins (observed now but not in the lockfile) — exit code 4, CI fails. To accept them, re-run vendors export and commit the updated lockfile.
• Removed origins (in lockfile but no longer observed) — informational only, exit 0. Vendor cleanup doesn't fail the build.
• Unchanged set — exit 0, lockfile is current.

How it scores / contributes

The lockfile does not contribute to your Decryption Blast Radius score. It is a developer artifact: a policy file that says "these are the third-party origins we approved as of this commit." The scoring is unchanged.

What the lockfile does contribute: a stable PR-review event when vendor surface drifts. Like package-lock.json, the value comes from making changes visible in diffs.

Schema (v1)

{
  "schema_version": 1,
  "generator": "pqcheck-cli/0.12.0",
  "domain": "example.com",
  "generated_at": "2026-05-16T22:30:00.000Z",
  "approved_script_origins": [
    "https://js.stripe.com",
    "https://www.googletagmanager.com"
  ],
  "synced_from_account": null
}

The synced_from_account field is null for Free-generated lockfiles. Founder Pro vendors sync sets it to the sync timestamp, indicating the file contains dashboard-managed approvals (not just whatever was observed).

Free vs Founder Pro — what each tier gets

• Free tier: vendors export + vendors check work fully against 1 monitored domain. CI gate is enforceable. The lockfile is generated from CURRENTLY OBSERVED origins (read-only snapshot).
• Founder Pro ($19.99/mo launch pricing — locked while subscription active; $29/mo standard post-traction): Adds vendors sync, which pulls the dashboard-managed approved-vendor allowlist (set via the Cipherwake UI at /account) and merges it into the lockfile. Useful when you want to pre-approve an origin BEFORE it appears in production — e.g., during a planned vendor rollout. Plus 5 watched domains, full CI Trust Gate, custom thresholds, and Slack/webhook delivery.

The dashboard UI is the Founder Pro wall. The lockfile itself is free.

What this tool does NOT claim

• It does not claim a vendor is bad. The lockfile is a record of approved origins, not a security verdict on any specific vendor. New origins fail CI because they are unreviewed, not because they are unauthorized.
• It does not detect dynamic loads. Only origins detected during our crawl are captured. Scripts injected by a tag manager or loaded conditionally after the initial render may not appear.
• It does not check script integrity. Subresource Integrity (SRI) hashes are not part of the lockfile. Two requests to the same origin returning different bytes will both pass the vendors check.
• It does not enforce at runtime. The lockfile is a CI-time check. To enforce at request time, configure your Content-Security-Policy (CSP) script-src allowlist.
• It is point-in-time. The export captures origins at a moment. Drift after the commit is what vendors check detects.

Limitations + edge cases

• SPA / late loads: origins loaded after the initial render (router-driven, lazy chunks) may be missed by the public scan. vendors check won't fail on origins it never observed; this is a coverage limitation, not a correctness issue.
• Wildcarding: the lockfile does not currently support wildcard or pattern origins (no https://*.example.com). Each subdomain is treated as a distinct origin.
• Tag managers: if a single tag manager origin (e.g. https://www.googletagmanager.com) is approved, that does NOT implicitly approve downstream tag origins. Each unique origin appears separately.
• HTTPS-only: non-HTTPS script origins are not eligible for the dashboard allowlist (per score-components) and won't appear in synced lockfiles. They may still appear in vendors export output if observed.
• API quota: export + check + sync each consume one /api/deps call. Free tier has generous bulk rate limits for this endpoint (it is not metered against Trust Diff quota).

Try it

• npx pqcheck vendors export cipherwake.io — captures the current vendor surface.
• npx pqcheck vendors check cipherwake.io — CI gate; exits 4 on new origins.
• CIPHERWAKE_API_KEY=qpk_... npx pqcheck vendors sync cipherwake.io — Founder Pro dashboard sync.
• Schema example: see "Schema (v1)" above.