SW-REG-001: Skill package not admitted in the organisation's private registry

What it detects

This rule has no detector in the scanner's rule code, which registers it with a function that returns nothing, so spellwarden scan on its own never reports it. A connected run does. The run needs an organisation on the Enterprise plan, whose private registry exists, and a CI policy with the registry check switched on, which is the default. The command sends the identity of each item in scope in one call, and each skill, plugin or marketplace that the registry does not admit becomes one finding of this rule, at the item's location, with severity high.

An identity is what the registry can hold for the item. A skill is identified by the hash of the files of its package. A plugin is an entry of the repository's own marketplace.json with a remote source, and a marketplace is an extraKnownMarketplaces declaration of .claude/settings.json; each is identified as a repository and a full 40-character commit, given as sha or as a ref of that form. Plugins and marketplaces are judged only when the CI policy says so.

What is in scope follows the policy's scope. With changed, on a pull or merge request, the check judges what the request added or changed: a skill when any path under it changed, a plugin or marketplace when its document changed and the base revision holds no entry with the same identity. A run on the default branch, a run on another branch and a policy with scope all judge everything. The evidence is the item's name and its identity, and the Markdown report adds a link to request its admission.

Why it matters

A private registry is the organisation's own list of the skills, servers, plugins and marketplaces its people may load. A skill that arrives in a pull request and is not on that list has not been scanned, curated or approved by the people who answer for the list, yet an agent that loads it follows its instructions with the permissions it already has. The check moves that decision to the pull request, before the merge. The scanner maps this rule to OWASP ASI04, Agentic Supply Chain Vulnerabilities, and to NIST SP 800-53 control SR-3, Supply Chain Controls and Processes.

The rule needs the Enterprise plan and a connected run. The check itself is described in the registry check of the CI guide, and the registry in the private registry guide.

Example

The skill below is added by a pull request. Its package hash is not in the organisation's registry, so a connected run reports it:

This example is an illustration. It cannot be checked offline with spellwarden scan, for the reason given below it.

The rule is applied by a connected run against an organisation's private registry (spellwarden_scan/rules/registry.py has no detector, and no scan of files alone emits it), so no offline scan can reproduce it.

.claude/skills/invoice-check/SKILL.md

---
name: invoice-check
description: Checks an invoice file against the purchase order and lists the differences.
license: MIT
version: 1.0.0
---

# Invoice check

Read the invoice and the purchase order, then list every line that differs.

The finding sits at the skill's location, and its evidence is the skill's name and the package hash. The report's section for items that are not admitted holds the link to request the skill's admission.

How to fix

Request the item's admission with the link in the report. A skill is admitted through its scan and the registry's policy, and a plugin or marketplace through an allow entry that an administrator adds for the exact commit (see allow entries). Or take the item out of the change.

An admitted item stays admitted only as it was. A skill whose files change, or a plugin moved to another commit, has a new identity and needs admission again.

If it is a false positive

The common harmless case is an item that is in the registry under an older identity: a skill edited by one byte, or a plugin pinned to a newer commit than the admitted one. Admit the new version instead of accepting the finding.

If you do accept a registry finding in the baseline file, it can last 90 days at most, and on a pull or merge request only the base revision's baseline counts, so a request cannot accept its own finding.

If the finding is not a problem in your case, accept it with a note: in the dashboard a manager or owner can accept a finding and the note is kept with it; with the scanner on its own, add it to the baseline file with a reason and an expiry date.

Related rules

• SW-REG-002: MCP server not admitted in the organisation's private registry
• SW-REG-003: Agent content the private registry cannot judge
• SW-CFG-009: Marketplace plugin source not pinned to a commit