Why this verdict
mcp-server . Suspicious
- suspicious: finding mcp-server:.:mcp-server.json:2:SUPPLY
skill skills/veris Suspicious
- suspicious: finding skill:skills/veris:skills/veris/SKILL.md:29:SUPPLY
- suspicious: finding skill:skills/veris:skills/veris/SKILL.md:31:SUPPLY
- suspicious: finding skill:skills/veris:skills/veris/SKILL.md:87:SUPPLY
- suspicious: unverified finding skill:skills/veris:skills/veris/SKILL.md:75:EXEC
Security findings 5
Supply chain
highContextual riskmedium confidencemcp-server.json launches the server via `npx -y veris-core mcp` without a version pin, so whatever latest npm release exists is fetched and run automatically; server.json pins 2.1.8.
stdioCommand.args[1]: veris-core
conceal:remotevector:metadata
Counter-argument considered
The launch command is `npx -y veris-core mcp` with no version pin, which is not the pinned-install carve-out; the manifest itself is version 2.1.8. The package is the server's own, so severity is low, but the finding stands.
Code execution
highUnverifiedlow confidenceDocs describe extending the tool by dropping JS files into a glob-matched `.veris/plugins/*.js` path inside the analyzed repo, which would be loaded as code and could be planted by an untrusted repo.
Add new domains via `.veris/plugins/*.js`.
vector:instruction
Supply chain
mediumContextual riskmedium confidenceSetup instructs the agent's MCP config to run the unpinned npm package veris-core via npx -y, fetching and executing the latest remote code on each launch with no version pin.
"args": ["-y", "veris-core", "mcp"]
vector:instruction
Counter-argument considered
The setup instructs the agent's MCP config to run `npx -y veris-core` with no version pin. That is a mutable remote fetch and not the pinned-install carve-out.
Supply chain
mediumContextual risklow confidenceSetup instructs configuring the agent's MCP settings to run an unpinned npm package via `npx -y`, which fetches and executes whatever the latest veris-core version is at runtime.
"args": ["-y", "veris-core", "mcp"]
vector:instruction
Counter-argument considered
This is the same unpinned `npx -y veris-core` MCP setup as the previous finding, with no version pin. Severity is low, but it is not a carve-out.
Supply chain
mediumContextual risklow confidenceVerify section tells the user/agent to git clone an unpinned GitHub repo and run npx veris-core on it, executing mutable remote code without version pinning.
git clone https://github.com/vighriday/Veris
cd Veris/examples/demo-app
npx veris-core .
vector:instruction
Counter-argument considered
The Verify section tells the reader to clone an unpinned GitHub repo and run `npx veris-core .` on it. That is a mutable remote fetch with no pin or commit, although it is a demo from the project's own repo.
Refuted findings 4
Candidates the review stage examined and rejected, kept for transparency.
Code execution
highRefutedlow confidenceREADME states Veris 'never executes anything' yet also documents an opt-in plugin mechanism that executes code from the analyzed repository without a sandbox, so the blanket no-execution claim is overstated (the plugin execution is disclosed and off by default).
Plugins execute code from the analyzed repo, so they are off by default
Why it was refuted
The 'never executes' line is about tests, sandboxes and runtime. The README discloses the opt-in plugin execution in the same section, so nothing is concealed or contradicted, and no instruction reaches the agent.
Code execution
highRefutedlow confidenceThe CLI can load and execute .veris/plugins/*.js from the analyzed repository when --allow-plugins or VERIS_ENABLE_PLUGINS is set, so untrusted repo code would run in the user's Node process; it is off by default and documented.
const plugins = loadPlugins(args.targetDir, { allowExecution: args.allowPlugins });Why it was refuted
Plugin loading is documented and off by default. Execution happens only with an explicit opt-in flag or env var, so there is no concealed or unconditional chain.
Code execution
highRefutedmedium confidenceThe plugin loader dynamically require()s any .js/.mjs/.cjs file from the analyzed repository's .veris/plugins directory, running arbitrary repo-supplied code; it is opt-in (--allow-plugins or VERIS_ENABLE_PLUGINS=1) and logs path and hash before execution, so it is a disclosed, gated feature rather than a hidden one.
const mod = require(abs);
Why it was refuted
The require() runs only after the explicit opt-in check passes. It prints the path and SHA-256 before execution, and the README documents it, so it is neither hidden nor automatic.
Code execution
highRefutedlow confidenceThe plugin loader can run arbitrary Node code from the analyzed repository's .veris/plugins directory when opted in, which goes beyond skill.json's declared 'git only' shell permission, although it is disabled by default and discloses path and hash before running.
A plugin is arbitrary Node code that ships inside the repository being analyzed
Why it was refuted
The header comment documents the plugin execution, which is off by default and needs an explicit per-run opt-in. Plugins run in-process through require(), not through the shell, so the 'git only' shell permission is not contradicted.
Coverage gaps 3
Parts of the artifact the static analysis could not fully examine.
no_tools_extracted MCP server target with no statically extractable tools/prompts/resources
package.json
no_dataflow_for_dynamic_code line 203: invoked code is not structurally extracted
src/cli.ts
no_dataflow_for_dynamic_code line 148: invoked code is not structurally extracted
src/plugins/PluginLoader.ts
