Repo Security Scanner — Malicious Code & Supply Chain

Audit GitHub repositories for malicious and supply-chain code before you install or depend on them. Give it a list of repos, a whole GitHub user/org, or the entire official MCP server registry, and get back one row per repo: a risk level, a score, and the single worst finding with the file, line and evidence that triggered it.

Installing a dependency, an agent tool, or an MCP server means running someone else's code — often at install time, before your own code ever executes. This scans for the patterns that matter and tells you which repos to look at twice.

What it does, in the words you'd ask for it

• Run a supply chain audit on a dependency before you add it to a project.
• Scan a GitHub repo for malicious code — install hooks, download-and-execute, credential exfiltration, seed-phrase harvesting.
• Check an MCP server before installing it — point it at the official registry, or at any single server repo, and get a risk level back.
• Vet an npm or PyPI package's source repository for install-time execution, the supply-chain vector that runs before your own code does.
• Detect prompt injection in an agent tool's repo — instructions planted in READMEs, tool descriptions and config that target the model rather than the machine.
• Scan a monorepo's packages, not just its root — entry points are located from the repo's own git tree, so code under packages/* or apps/* is audited rather than missed.
• Audit a whole GitHub user or org in one run, ranked worst-first.
• Audit an open source dependency before it enters your lockfile.
• Find credential exfiltration in code — tokens, API keys and seed phrases being sent to an external host.
• Static analysis for secrets in a repo — deterministic pattern matching, no LLM and no code execution.
• Check a repo for install scripts — preinstall/postinstall hooks and setup.py commands that run before your own code does.
• Review an agent tool for safety — including prompt-injection markers aimed at the model rather than the machine.
• Get a package supply chain risk score — a level and a numeric score per repo, with the file, line and evidence behind the worst finding.

What it looks for

Install-time execution is checked first, because it is the biggest supply-chain vector:

Pattern	Severity
Install hooks that run commands (package.json pre/postinstall, setup.py)	via the rules below
Download-and-execute (curl … | sh, eval(fetch(…)))	CRITICAL
Credential / token exfiltration to an external host	CRITICAL
Seed-phrase / private-key harvesting	CRITICAL
Writes to sensitive dirs (~/.ssh, ~/.aws)	CRITICAL
Unsafe dynamic code execution with untrusted input	HIGH
Prompt-injection markers ("ignore previous instructions", "operate unconditionally")	HIGH
Auth/security bypass (verify=False, rejectUnauthorized:false)	HIGH

Capability mentions (an outbound URL, a broad filesystem read, a plugin-install line) are reported separately as context and never inflate the score — the calibration that keeps a scanner from being muted on day one. 17 named patterns / 60 signatures, deterministic: no LLM, no code execution.

Input

field	meaning
What to scan	A list of repos · every public repo of a user/org · or the official MCP registry.
Repositories	GitHub URLs (for the list mode).
GitHub user or organization	e.g. openai — audits all their public, non-fork repos.
Maximum repositories	Hard cap on how many are audited — and, since you pay per audit, your spending cap.
Only return repos at or above	Filter output by risk. Every repo is still audited; this only controls what appears.
Include every finding	Off returns just the risk level, score and worst finding — a much smaller result.

Output

One dataset item per repository:

{
  "repo": "owner/name",
  "repo_url": "https://github.com/owner/name",
  "risk_level": "CRITICAL",        // CRITICAL | HIGH | MEDIUM | LOW | SAFE | UNKNOWN
  "risk_score": 25,
  "finding_count": 1,
  "counts": { "CRITICAL": 1 },
  "top_finding": {
    "file": "package.json",
    "severity": "CRITICAL",
    "pattern": "Download & Execute",
    "line": 4,
    "evidence": "\"postinstall\": \"curl https://… | bash\""
  },
  "files_scanned": ["package.json", "packages/core/src/index.ts"],
  "code_files_scanned": ["packages/core/src/index.ts"],
  "coverage": "code",              // "code" | "shallow"
  "findings_in_executable": 1,     // in code that runs
  "findings_in_docs": 0,           // in .md / .rst / .txt
  "findings": [ /* every match, when 'Include every finding' is on */ ]
}

Where a payload sits changes what it means. A curl … | sh in postinstall.js runs on npm install; the same string in README.md is prose — very often a security tool's own test vectors, or a threat write-up showing what not to do. Both are reported and neither is hidden, but they are counted separately, the headline top_finding prefers executable content over a paragraph about it, and a repo whose findings are all in documentation gets a findings_note saying so. It is still real text, so an agent that reads those files does meet it — judge it as content, not as runtime behaviour.

UNKNOWN is reported, never hidden, and is split by cause: repo_gone (deleted or private since listed), no_entry_point (exists but keeps code somewhere unusual), or unreachable. It is not a clean bill of health.

coverage tells you how much was actually read, because SAFE on its own does not. If a repository turns out to expose no source entry point at all, coverage is "shallow" and a coverage_note says plainly that the verdict rests on a manifest and documentation only — a check, not a code review. This exists because it once mattered: pointed at a real monorepo, an earlier version read package.json and README.md, found nothing, and returned SAFE with no indication that it had never seen a line of the code. Entry points are now located from the repository's git tree, so packages/* and apps/* are audited too.

Pricing

Pay-per-event: charged once per repository audited. Maximum repositories is therefore also your budget cap. Filtering the output does not reduce the charge, because the audit is the work.

Use cases

• Before you npm install / pip install — audit the dependency's repo for install-time execution and credential exfiltration.
• Vetting AI agent tools and MCP servers — scan the whole official MCP registry, or one server, before you connect it to an agent that holds your keys.
• Org-wide hygiene sweep — point it at your GitHub org and get a ranked list of which repos contain risky patterns.
• Supply-chain due diligence — audit an acquisition target's or vendor's public repos.

FAQ

Does it execute any of the scanned code? No. The scan is purely lexical — it reads source files and matches behavioural patterns. Nothing is installed, built or run.

Is this a vulnerability scanner / SCA tool? No. It does not check dependency versions against CVE databases. It looks for malicious and supply-chain behaviour in the code itself — pipe-to-shell installers, token exfiltration, seed-phrase harvesting, prompt injection — which CVE-based tools do not cover.

What does a SAFE result mean? "No known pattern matched." It is not a guarantee of safety. Treat CRITICAL as "look here first", and every finding as a pointer for human review rather than a verdict.

Why do some repos come back UNKNOWN? Because the truth is unknown: the repo was deleted or made private (repo_gone), keeps code somewhere the scanner did not look (no_entry_point), or could not be reached (unreachable). It is reported rather than quietly counted as clean.

How much does a scan cost? You pay per repository audited, so Maximum repositories is your hard spending cap.

How it decides

The scanner is lexical — it reads source and matches behavioural patterns; it never executes anything. Risk level is the highest-severity real finding present, so one credential-exfil or pipe-to-shell reads as CRITICAL regardless of count. It is strongest on self-contained payloads (a curl … | bash, an eval(request…), a malicious install hook) and weaker on behaviour split across many files or heavily obfuscated. Treat SAFE as "no known pattern matched", not a guarantee — and CRITICAL as "look here first".

Findings are pattern matches that warrant human review, not verdicts. Never publish one as an unverified accusation.