* policy(scan): review whole payload incl .claude/ + flag credential extraction
The review rubric anchored "read every relevant file" to the loaded plugin
surface (skills/*/SKILL.md, hook-referenced source) and checked credential
reads (~/.ssh, ~/.aws/credentials) only within hooks. Code that reads the user's
live secrets from a non-loaded location — e.g. a dotdir like .claude/ that still
ships to the user's disk on a git-source install — could fall through both.
Two fixes:
- Scope: direct the reviewer to read the WHOLE shipped payload incl. dotdirs
like .claude/ (clones to disk, agent-reachable though not auto-loaded).
- Detector: add an explicit credential/secret-extraction check across ALL
shipped code (not just hooks), naming OS credential-store CLIs + token
harvest, with the set-your-own-key vs harvest trust-boundary distinction.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* policy(scan): scope credential-extraction flag to CROSS-service routing (cut same-service FPs)
A full faithful scan of all 159 -official url-source plugins surfaced false
positives: the credential clause flagged plugins that use the user's OWN
service token to call that SAME service (e.g. a Railway plugin reading the
Railway CLI token to call Railway; a gcloud token used against Google) — normal
integration behavior. The "flag even if the destination is the vendor's own
service" wording inverted the right rule.
Corrected: flag only CROSS-service routing — a credential for service A sent to
a DIFFERENT service or third party (the vercel-style misuse: Anthropic's
ANTHROPIC_AUTH_TOKEN routed to a non-Anthropic endpoint). Same-service use
(token for X used to call X) is explicitly NOT a violation.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* policy(scan): judge credential ownership by NAME/source, not plugin-claimed use
Refines the cross-service rule after the full -official re-validation showed the
prior wording let a plugin pass by *claiming* an ANTHROPIC_*-named token was
"its gateway key." Now: which service a credential belongs to is judged by its
NAME / storage location (ANTHROPIC_AUTH_TOKEN => Anthropic; ~/.railway/config.json
=> Railway; ~/.aws/credentials => AWS), NOT by how the plugin repurposes it. So
reading an ANTHROPIC_*-named token and routing it to a non-Anthropic endpoint is
cross-service (flag) even if the code treats it as a gateway key; same-service
use (Railway token -> Railway) still passes. Catches the wrong-credential-class
trust-boundary breach while preserving the same-service FP fix.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ci(validate): trigger on .github/policy/** so policy-prompt PRs clear the required check
A PR touching only .github/policy/** matched none of the validate
pull_request paths, so the required 'validate' check never ran via
pull_request and sat Expected forever (a workflow_dispatch check run
isn't associated with the PR, so it can't satisfy the gate). Mirrors
the existing .github/workflows/** carve-out.
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Tighten policy scan: hook scope, telemetry, disclosure; make blocking
policy/prompt.md — adds Part 2 (hook scope and disclosure):
- Enumerate every registered hook and read its source.
- Flag has_broad_scope_hooks when UserPromptSubmit/PreToolUse/
PostToolUse runs without a project-relevance gate, or any hook
reads user data beyond the plugin's stated scope — regardless of
whether it makes network calls.
- Flag has_undisclosed_telemetry when any hook or shipped code calls
a non-MCP host without explicit disclosure + opt-out.
- Flag description_matches_behavior=false when the install
description would not lead a reasonable user to expect the
hooks/telemetry/data-access found.
- passes=false when any of the above trip. Violations must cite the
specific hook/file and what the user wasn't told.
The bar is now "handles user data responsibly," not merely "isn't
malicious." A non-malicious plugin that observes more than its stated
purpose justifies will fail.
policy/schema.json — adds required hooks[], has_broad_scope_hooks,
has_undisclosed_telemetry, description_matches_behavior.
scan-plugins.yml:
- fail-on-findings: true (blocking — loosen later if FP rate too high)
- workflow_dispatch with scan_all input for full re-review of all
external entries
- timeout-minutes: 360 (full scan of 117 entries at ~96s each ≈ 3h)
- trigger on .github/policy/** so prompt edits get scanned
* Bump vercel SHA to test the tightened scan against it
* Adopt validate-plugins action suite; pin all external SHAs
Replaces the hand-rolled marketplace validator and bot-based bump
workflow with the shared composite actions (pinned at f846a0b).
marketplace.json:
- 62 external entries that were missing a `sha` are now pinned to
their current upstream HEAD (resolved via git ls-remote).
Workflows:
- validate-plugins.yml: invariants I1-I11 + claude plugin validate +
diff-gated clone-at-SHA validation of changed external entries.
SHA-pin (I5) is a hard error. I8/I11 stay warnings until the 15
known data issues (vendored dirs without manifests; one dotted
name) are cleaned up.
- bump-plugin-shas.yml: bot-free weekly refresh. Validates each new
SHA with claude plugin validate before opening one PR; works with
the default GITHUB_TOKEN (contents:write + pull-requests:write).
- scan-plugins.yml: Claude policy scan of changed external entries.
Non-blocking; graceful no-op if ANTHROPIC_API_KEY isn't set.
Removed:
- validate-marketplace.yml + the two TS helper scripts (superseded
by step 11/20 of validate-plugins).
validate-frontmatter.yml is kept — it's complementary (targeted
checks on agent/skill/command files for in-repo plugins).
* Remove 5 external entries that fail validation at HEAD
Step 30 (clone at pinned SHA + claude plugin validate) fails for
these at their current HEAD:
aiven Unrecognized key "logo" in plugin.json
atlassian-forge-skills skill YAML frontmatter parse error
sagemaker-ai skill YAML frontmatter parse error
speakai no plugin manifest at repo root
stagehand no plugin manifest at repo root
These can be re-added once the upstream repos are fixed.
* Wire scan-plugins to the detailed policy prompt
Adds .github/policy/prompt.md and schema.json (the full security
review rubric — malicious code, privacy, deception, safety
circumvention, exfiltration; plus network-call and software-install
flags) and points scan-plugins at it via the policy-prompt input.
With ANTHROPIC_API_KEY now configured on the repo, scan-plugins runs
the actual policy review on changed external entries instead of
no-op'ing.
* Bump scan-plugins action pin to include L11/L12 fixes
