SkillSpector v2.11.0 scans skill bundles without executing them
SkillSpector v2.11.0 accepts a Git repository, URL, zip, directory, or single file and returns a risk score, severity, recommendation, and findings. Its static stage combines pattern matching, Python AST checks, taint tracking, YARA signatures, permission analysis, and live OSV dependency lookups. An optional LLM stage judges context and intent. Reports can be terminal text, JSON, Markdown, or SARIF. This is a useful pre-install view because the scanner reads suspect content without importing packages or running scripts from the skill.
The source is substantial for a specialist scanner. Our checkout had 333 files, about 110,305 lines of source, and used 5.3 MB before dependencies. The README lists 71 patterns across 17 categories, including prompt injection, exfiltration, privilege escalation, supply-chain behavior, memory poisoning, trigger abuse, MCP permissions, and tool-description poisoning. A score condenses those findings, but the individual rule, file, evidence, confidence, and remediation fields are what a reviewer can investigate. Security teams should retain the detailed report rather than storing only the final recommendation.
A SAFE score still needs coverage and human review
SkillSpector v2.11.0 assigns 0 to 20 points a LOW severity and a SAFE recommendation, while scores above 50 become DO NOT INSTALL. Executable scripts multiply the score. The project also supports baselines that suppress reviewed findings by rule, path, or fingerprint, which helps teams focus on new changes. Static analysis favors recall and can produce false positives; the optional semantic stage aims to filter them. Neither mode proves safety. A missed file, unsupported format, model error, or rule assumption can still leave dangerous behavior outside the report.
Our lab installed 103 npm packages in 35 seconds and recorded 232 MB on disk. That result describes the repository's npm surface, not the documented Python 3.12 CLI. The checkout offered no npm build or test script, so our harness skipped both. Anyone evaluating the scanner should follow the uv, pip, or Docker route and run the Python tests separately. The included Dockerfile gives a contained packaging path, while --no-llm gives a static-only trial without model credentials.
What happened when we ran it
Our npm-oriented run at commit 7805bb9 completed installation in 35 seconds. Npm audit found 0 known vulnerabilities at every listed severity. The repository scan found 4 CI workflow files, a Dockerfile, and a tests directory. Our measurement setup was a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. These facts show that the npm dependencies installed cleanly; they do not show that a SkillSpector scan, Python package build, or test case succeeded.
There was no build script or target, so the build step was skipped. There was also no test script or target, so our run produced no passing, failing, or skipped test count. The tests directory is a repository signal, not a test result. This distinction matters because release v2.11.0 documents extensive Python validation, but those are NVIDIA's release claims rather than measurements from our sandbox. A buyer should run the Python suite in the same image and dependency mode chosen for the production gate.
Partial coverage can still exit zero
Issue 389 reports that a scan with 86 percent component coverage exits 0 just like a complete scan, because coverage metadata does not affect the CLI code. Issue 460 adds a related limit in v2.11.0: the whole workflow has a 60-second budget that cannot be raised through a flag or environment variable. Its reporter saw large scans return partial results with varying coverage. CI users should parse analysis_completeness, reject incomplete scans, and distinguish a clean finding set from a scanner that did not inspect everything.
Our checkout supplied no npm test target, even though it contained a tests directory and 4 CI workflows. That leaves issue reports and upstream release validation as context, not confirmation from our lab. Issue 458 says three dedicated trigger-abuse rules look for a triggers field absent from supported skill specifications. Issue 472 says the RP3 version rule reads a manifest key the real context builder never populates. Both reports include direct reproductions. Treat rule counts as advertised coverage, then verify that the specific controls your policy depends on can fire end to end.
SkillSpector v2.11.0 sends semantic-scan contents to a provider
SkillSpector v2.11.0 enables LLM analysis by default and sends analyzer-eligible file contents to the configured provider. --no-llm keeps those contents local, although the SC4 dependency check still sends package names and versions to OSV.dev when network access exists. Without OSV access, a small built-in advisory list is used. The MCP server adds another boundary: stdio is suited to local agents, while HTTP ships without authentication. Remote operators must add an authenticating proxy and should keep the documented rejection of local file paths over HTTP.
The project was pushed on September 1, 2026, and GitHub listed 15,512 stars plus 90 combined issues and pull requests. Release v2.11.0 arrived on August 28 with npm lockfile analysis, bundled-hook findings, and parser fixes. Our 103-package npm audit found 0 known vulnerabilities, but we did not run the scanner itself. SkillSpector earns a place before installation because it gives reviewers structured evidence without executing untrusted code. Its recommendation should remain one input to a gate that also checks completeness, provenance, signatures, and runtime behavior.