Comparison
Dependabot vs SkillAudit
Dependabot is zero-config, free, and built into GitHub. SkillAudit is a purpose-built security grader for MCP tool-handler code. These tools don't overlap — they cover adjacent layers. The comparison most MCP developers need isn't "which one" but "do I have both?"
Quick verdict
- Choose Dependabot if: you want automatic pull requests that upgrade vulnerable dependencies the moment a CVE is published and a fixed version is available. It's free, zero-config, and native to GitHub. Nothing else matches it for that job.
- Choose SkillAudit if: you want a grade for the MCP tool-handler code you wrote on top of those dependencies — the SSRF patterns in
fetch(url)handlers, the credential echo through tool responses, the prompt-injection susceptibility the LLM will inherit. Dependabot doesn't read handler bodies; SkillAudit does. - Run both: there is no switching cost. Dependabot and SkillAudit are purely additive — they look at different parts of the same repo. Enabling SkillAudit doesn't replace Dependabot; it covers the layer Dependabot wasn't designed to reach.
What Dependabot actually does
Dependabot monitors your manifest files (package.json, requirements.txt, go.mod, Gemfile.lock, and others) and the GitHub Advisory Database. When a dependency you use has a published CVE with a fixed version, Dependabot opens a pull request that bumps the version. It also supports version-update PRs on a configurable schedule — keeping your deps fresh even when no CVE is in play. Its sibling, GitHub Code Scanning with CodeQL, extends this into source code: SQL injection, path traversal, hardcoded credential patterns, and other OWASP Top 10 findings in your own source files.
Both are free for public repos. Both are GitHub-native with a checkbox setup. Both are important for baseline hygiene — MCP authors should have both enabled before they ship anything to a public marketplace.
What Dependabot cannot see
Dependabot's model assumes the dangerous code is in a package someone else published. If your node-fetch version has a CVE, Dependabot will tell you. It will not tell you that your own code passes a caller-supplied URL directly into node-fetch without validation — because that pattern isn't a CVE in a database, it's a design decision in your tool handler. Specifically:
- SSRF in tool-handler bodies. The pattern
server.tool('browse', async ({url}) => fetch(url))is a textbook SSRF primitive — the LLM can supply any URL, including internal cloud-metadata endpoints. Dependabot won't open a PR for it because it's not a dependency vulnerability; it's your code. We found this in 50 of the 101 MCP servers we've audited — including vendor-official releases from Heroku, Cloudflare, AWS, and GCP. - Credential echo through tool output. A handler reads
process.env.API_KEY, makes an upstream request, and includes the full request log in tool output "for debugging." The API key is now in the model's context window. Dependabot's dependency feed doesn't model data-flow between env var reads and tool return values. - Prompt injection via untrusted tool output. A tool fetches a third-party document and returns its raw content. That content contains embedded LLM instructions. The model treats tool output as a trusted channel and follows them. This is a behavioural risk that requires red-teaming — static analysis can flag the data-flow but can't answer the model-behavioural question. SkillAudit uses an LLM-assisted probe for this axis specifically.
- Permission scope bloat. An MCP server that requests broad OAuth scopes when the tool it registers only needs narrow ones is a permissions failure. Dependabot has no way to reason about intended vs actual scope.
Side by side
| Dependabot | SkillAudit | |
|---|---|---|
| Primary job | Open PRs to patch vulnerable dependencies | Grade MCP tool-handler code for security, credential handling, and prompt injection |
| What it reads | Manifest files (package.json, etc.) + GitHub Advisory Database | Tool-handler source code — function bodies registered via server.tool() |
| Scan target | Your own repos in GitHub | Any public GitHub repo, npm package, or ZIP — including code you're about to install |
SSRF in fetch(url) tool handlers | No — dependency scanner, not source SAST | Yes — MCP-specific pattern detection on tool-handler bodies |
| LLM-assisted prompt-injection probe | No | Yes — extracts tool handlers, red-teams via Claude Haiku 4.5 |
| Credential-echo detection (env var → tool output) | No | Yes — first-class axis |
| Permission scope analysis | No | Yes — flags over-privileged OAuth/API scope declarations |
| Buyer-readable grade | No — private Security tab in the repo | A–F grade + public report card URL for marketplace listings |
| Badge for README | No | Yes — embeddable skill-grade badge |
| Free tier | Free for all GitHub users, unlimited | 3 audits/month on public repos; all public report cards viewable for free |
| Cost for private repos | Free (Dependabot); GitHub Advanced Security for some CodeQL features | $19/mo Pro (unlimited), $99/mo Team (10 seats, SSO) |
| Auto-remediation | Yes — opens PRs that upgrade deps | No — grades and suggests fixes; doesn't open PRs |
| Setup effort | One checkbox in GitHub repo settings | Paste a URL for one-off audits; GitHub Action for CI gate |
The data: what Dependabot misses
We've audited 101 of the most-installed MCP servers. The grade distribution is 19 A · 30 C · 10 D · 42 F. The repos that failed are, in general, repos that Dependabot is monitoring and finding clean. Their dependency trees are healthy. The findings are in handler bodies that Dependabot never inspects.
A concrete example: heroku/heroku-mcp-server — published by Heroku's official engineering team — has Dependabot enabled and has no dependency CVEs. It earned an F from SkillAudit because 10 of its tool handlers pass a configurable endpoint parameter straight into template-string fetch() calls: fetch(`${this.endpoint}/apps/${args.appName}/…`). An adversarial prompt can set endpoint to an internal cloud-metadata address. Dependabot cannot see this because it's not in package.json.
When Dependabot is still the right choice (it's always the right choice)
We're not arguing for replacing Dependabot. Dependency hygiene is foundational — a vulnerable version of axios in your transitive tree is a real bug regardless of whether your tool handlers are clean. Keep Dependabot. If you haven't enabled it, enable it today — it's free, it's zero maintenance, and it closes a real class of vulnerability that SkillAudit doesn't try to detect.
The specific case where you might weigh Dependabot more heavily than SkillAudit: if you're building a server-side web app (not an MCP server) and your primary risk surface is library-level CVEs and web injection. SkillAudit is narrow on purpose — it's for MCP-shaped code. If that's not what you're building, Dependabot + CodeQL is the right stack and SkillAudit adds little.
For MCP authors: use both. No trade-off required.
How to add SkillAudit alongside Dependabot
- Keep Dependabot enabled as-is.
- Paste your repo's GitHub URL on SkillAudit's home page for a one-off audit. You'll get a grade and a report card in 60 seconds.
- If the grade is acceptable, opt the report into the public board and embed the badge in your README.
- For continuous CI coverage: add the SkillAudit GitHub Action (Pro) and set a minimum-grade gate (e.g. fail PR if grade falls below B).
Both run in CI, both are free for public repos at the basic level, and neither interferes with the other.
Try SkillAudit on your repo — free
Paste any public GitHub URL. No sign-up for public audits. Graded report card in 60 seconds.