Repo Security Scanner - Malicious Code & Supply Chain avatar

Repo Security Scanner - Malicious Code & Supply Chain

Pricing

$20.00 / 1,000 mcp server auditeds

Go to Apify Store
Repo Security Scanner - Malicious Code & Supply Chain

Repo Security Scanner - Malicious Code & Supply Chain

Audit GitHub repos for malicious and supply-chain code before you install or depend on them. Scans a repo list, a whole GitHub user/org, or the MCP registry. Returns a risk level, score and evidence per repo.

Pricing

$20.00 / 1,000 mcp server auditeds

Rating

0.0

(0)

Developer

Ikko Eltociear Ashimine

Ikko Eltociear Ashimine

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

a day ago

Last modified

Share

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 looks for

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

PatternSeverity
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 hostCRITICAL
Seed-phrase / private-key harvestingCRITICAL
Writes to sensitive dirs (~/.ssh, ~/.aws)CRITICAL
Unsafe dynamic code execution with untrusted inputHIGH
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

fieldmeaning
What to scanA list of repos · every public repo of a user/org · or the official MCP registry.
RepositoriesGitHub URLs (for the list mode).
GitHub user or organizatione.g. openai — audits all their public, non-fork repos.
Maximum repositoriesHard cap on how many are audited — and, since you pay per audit, your spending cap.
Only return repos at or aboveFilter output by risk. Every repo is still audited; this only controls what appears.
Include every findingOff 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", "src/index.ts"],
"findings": [ /* every match, when 'Include every finding' is on */ ]
}

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.

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.