SkillSpector v2.12.0: skanuj umiejętności agentów i serwery MCP przed instalacją, a kodu wyjścia 0 nie traktuj jako dowodu kompletności

Scan agent skills before anyone installs them, and do not read exit code 0 as "fully inspected"

Technicians now install skills and MCP servers into coding agents and assistants the way they once installed browser extensions: quickly, and on machines that can reach customer systems. A skill is instructions plus code plus dependencies, and the agent will follow the instructions. That makes intake a governance question, not a convenience setting.

One reference tool, named as a reference and not an endorsement: NVIDIA's SkillSpector, repository NVIDIA/SkillSpector, licensed Apache-2.0, which the project describes as a security scanner for Claude Code, Codex and MCP skills "before you install them." The GitHub API read on 6 October 2026 showed 19,494 stars and a last push at 06:47 Europe/Rome that morning. The current release is v2.12.0, published on 23 September 2026.

This tutorial has one rule. By default, SkillSpector's exit code 0 covers both SAFE and CAUTION, and the release notes say outright that "exit code 0 alone does not establish complete inspection." Gate pipelines on both --fail-on-findings and --fail-on-incomplete.

Below: what the scanner looks at and what it never does, what changed in 2.12.0, how to read exit codes and completeness, which content leaves your network when LLM analysis is on, and an intake policy an MSP can adopt this week. The article includes no attack examples.

From the repository description and README only: SkillSpector scans skills supplied as directories, single files, Git repositories, URLs or zip files. It reports risks in categories that include prompt injection, data exfiltration, privilege escalation, supply-chain risk, excessive agency and MCP tool poisoning. The project says it covers 71 patterns in 17 categories. This article names categories and does not explain techniques.

The scan runs in two stages. The first is fast static analysis: pattern rules, checks on the Python syntax tree and YARA signatures. The second is an optional semantic review by a language model. A supply-chain check looks up declared dependencies against OSV.dev, with an offline fallback list.

Output can be terminal text, JSON, Markdown or SARIF, with a 0–100 risk score, a recommendation, and a baseline mechanism for accepted findings, so re-scans show only what is new.

The trust model, in the project's own terms: SkillSpector never executes the scanned skill, and it does not sandbox the host. It flags risky patterns before install. It does not contain a skill that someone decides to install anyway.

The popularity numbers: 19,494 stars and 1,704 forks on 6 October 2026, read from the GitHub API. An earlier search snapshot in our own research put the count at about 19.3k; the picture is the same. Stars measure attention, not assurance. The licence is Apache-2.0, from the API's SPDX field.

Release facts here come from the public releases page. The GitHub releases API was rate-limited when we checked, so dates come from the release text.

v2.12.0, published 23 September 2026. The release brings more consistent reporting of scan completeness, better finding identity and source locations in JSON and SARIF, and faster scans with progress messages on standard error while JSON and SARIF stay clean on standard output. It adds an optional OpenCode integration and support for scanning GitHub subdirectory links and GitHub or GitLab file links.

The CI flag is new and opt-in: --fail-on-findings. Opt-in means pipelines that do not add it keep the old behaviour, so upgrading the scanner alone does not tighten anything.

Timing changed too. The default static-analysis allowance per artifact rose from 30 to 300 seconds, still bounded by the overall workflow deadline, and one environment variable restores 30 seconds. Budget CI time accordingly.

v2.11.1, 7 September. The default aggregate workflow deadline rose from 60 to 600 seconds and became configurable. It is a shared ceiling for the whole scan, not a per-analyzer allowance.

The upgrade warning an MSP must act on, from the 2.12.0 notes: findings, risk scores, recommendations and completeness results can change after upgrading, so review existing baselines. Treat a scanner upgrade as a change with its own ticket. One line of context from 2.10.0: degraded LLM analysis now floors an otherwise SAFE result to CAUTION, so incomplete work is harder to mistake for a clean result.

The exit codes, from the README. 0 means the scan completed, the risk score is 50 or below (recommendation SAFE or CAUTION), and no strict gate fired. 1 means the risk score is above 50, or an enabled gate fired: findings, incomplete coverage or a minimum-coverage floor. 2 means an error, such as bad input, an unreadable source or an internal failure.

The trap fits in one sentence: by default the exit code collapses SAFE and CAUTION into 0, so a pipeline that only checks "did it exit 0?" will pass a skill the scanner itself marked CAUTION.

The fix, in the project's own words from the 2.12.0 notes: combine --fail-on-findings with --fail-on-incomplete when CI must reject either active findings or incomplete coverage. A policy-gate failure returns code 1, and code 2 denotes an input or execution error. Optionally add --min-coverage with a percentage floor, or read the JSON recommendation field for a custom policy.

Incompleteness happens in normal operations, with no attacker involved: timeouts against the workflow deadline, an LLM provider that fails or is not configured, unsupported inputs, or exclusions set by whoever runs the scan. The README says any matched exclusion makes coverage partial and prevents a SAFE recommendation.

Treat code 2 as "no verdict", never as a pass. Record it, then retry or escalate.

The evidence an MSP should keep per install request: scanner version, the exact source and revision scanned, the SARIF or JSON report, the completeness section, and who approved. Not evidence: "it exited 0", or a star count.

A minimal gate for a CI job or an intake script follows. Remove --no-llm only where your data policy allows file contents to go to the configured LLM provider.

# Static-only scan: file contents stay local (dependency names still go to OSV.dev).
# Fails the job on any active finding OR on incomplete coverage.
skillspector scan ./incoming-skills/example-skill/ \
  --no-llm \
  --fail-on-findings \
  --fail-on-incomplete \
  --format sarif --output skillspector.sarif
# exit 0 = both gates passed · 1 = a gate fired or risk > 50 · 2 = no verdict (error)

Data custody comes first, from the README's trust-model section. LLM analysis is on by default, and it sends analyzer-eligible file contents to whichever provider is configured. --no-llm keeps file contents local and runs static analysis only; analysis that was requested but could not run stays visible in the completeness metadata.

The second flow is the one people miss. The supply-chain check sends the names and versions of declared dependencies, not file contents, to OSV.dev, and it does so even with --no-llm. If a skill is a customer's private code, decide whether its dependency names are sensitive and whether that outbound call is allowed from that network.

Provider choice is a custody decision. The project supports hosted, local and OpenAI-compatible endpoints. For customer-owned skills, prefer a local or contractually covered provider, and write that choice into the scan policy.

The MCP server mode has a boundary worth knowing, from 2.9.4: when SkillSpector itself is exposed as an MCP server over HTTP, it rejects caller-chosen local scan paths. Use the trusted stdio transport for local scans.

The project also states a language limit. It may miss patterns in non-English content, and it cannot analyse text inside images. For skills written in Italian, German or French, treat a clean result with extra care and keep a human read in the loop.

An intake policy an MSP can adopt this week, written as defender controls with evidence and non-evidence:

1. One intake path. Skills and MCP servers reach technician machines or customer environments only through a request with an owner. Evidence: a ticket per install. Not evidence: "the team knows what they use."
2. Scan the exact revision. Scan the commit, tag or archive that will be installed, not the repository's default branch, and re-scan on every update. Evidence: the revision in the report matches the revision installed.
3. Two gates. --fail-on-findings and --fail-on-incomplete on every automated scan; code 2 is a hold. Evidence: the pipeline definition shows both flags.
4. Pin the scanner. Record the SkillSpector version in the report and in the ticket. After an upgrade, re-run the baseline review that the release notes ask for.
5. Baselines are decisions. Every accepted finding in a baseline file has a reason and an approver. A baseline added to silence a gate is not acceptance.
6. Least privilege after install. A clean scan does not justify broad tool permissions. Grant the narrowest tool access the agent needs, customer by customer.

The scanner shortens the reading. It does not replace the decision.

Five things this article is not.

It is not about OpenAI's Codex Security CLI, a separate, vendor-gated scanner that needs Codex Security access.

It is not about DefectDojo, which aggregates findings across many tools.

It is not about Harden-Runner, which controls egress from CI runners. It complements a skill scanner but does a different job.

It is not about Trivy or Syft, which scan containers and generate SBOMs for software images, not instruction-bearing agent skills.

And it is not an attack write-up: there are no injection examples, no payloads and no technique walk-throughs here.

The live facts: SkillSpector is Apache-2.0, had 19,494 GitHub stars on 6 October 2026, and was last pushed at 06:47 Europe/Rome that day. The current release is v2.12.0, published on 23 September 2026, with the opt-in --fail-on-findings gate; 2.11.1 raised the default workflow deadline to 600 seconds.

The rule: exit code 0 alone does not establish complete inspection. Gate on findings and on completeness with --fail-on-findings and --fail-on-incomplete, and treat code 2 as no verdict. The custody line: LLM analysis sends file contents to the configured provider unless --no-llm is set, and dependency names go to OSV.dev either way. The limit: non-English content may be missed, so Italian-language skills deserve a human read.

This is a skill-intake story, not a story about Codex Security CLI, DefectDojo, Harden-Runner, Trivy or Syft. The release page, the README and the repository API were read on 6 October 2026; the releases API was rate-limited, so release dates come from the release text.