is-malicious

How we reviewed this: we ran it in Docker offline against a local stand-in, on a synthetic malicious package and on trees with and without a .gitignore. We made no Jev calls.

What it does

It walks a repository, classifies each file, packs them into 8,000-character chunks by directory, and asks twenty questions per chunk — credential theft, exfiltration, hidden network calls, dynamic code, persistence, supply chain, and more. Each question carries its own true/false criteria:

Does chunk.files steal credentials, tokens, cookies, private keys, or other secrets and send or write them somewhere the project would not normally need, rather than using its own configured secrets for a documented purpose?

Anything suspicious gets a second pass to pin it to a line window. On a synthetic package that base64’d process.env and ~/.npmrc to a remote host, it found both that and the CI workflow that posted an npm token, at the right lines.

.env is not an accident

if (CONFIG_NAMES.has(lower) || CONFIG_EXTENSIONS.has(ext) || lower.startsWith(".env")) {
  return "config";
}

Dot-files are not skipped here; .env is named. The only thing that saves it is .gitignore, so the outcome depends on the repository you point it at:

tree	.env sent?
not a git repo, no .gitignore	yes
.gitignore covers .env	no
git repo, .env untracked and not ignored	yes
git repo, .env committed	yes

A captured request contained AWS_SECRET_ACCESS_KEY=… and GITHUB_TOKEN=ghp_… in full. Nothing is redacted.

There is a defensible reason for this — a malicious package might hide its payload in a config file — and the README never claims otherwise. But the tool’s whole purpose is “run this before you trust the code”, which is exactly when you are pointing it at somebody else’s repository, and the README’s own CI template is the case most likely to meet an unignored .env.

A related quirk: JSON files are dropped as noise unless they look like they hold a secret. A credentials.json with a real private key is kept and sent; the same file with {"a":1} is dropped.

The gate passes when the API doesn’t

The exit code is the only enforcement:

return report.findings.some((finding) => finding.severity === "high") ? 1 : 0;

A failed request is caught, recorded in skipped[], and does not count. We ran it with an asker that always returns 401: three chunks skipped, zero findings, exit 0, with the failures visible only as a “Skipped” section in the log. In the provided GitHub Actions template, that is a green check on a pull request nobody scanned.

--min-prob also has no range validation, so --min-prob 1.1 guarantees a pass.

Verdict

The question set is the best part — twenty categories, each with criteria a person could apply, is more thought than most scanners put in. 36 tests, published to npm.

Two changes would make it trustworthy in CI: fail non-zero when chunks were skipped, and let people opt out of .env rather than relying on their .gitignore. Both are reported.

For scanning your own agent’s actions instead, see jev-guard; for Solidity, jevscan-evm.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 20, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.