Choosing a code security scanner, by what it can actually see.
Three categories, three different blind spots. Most confusion here is a category error rather than a tool choice.
The first thing to settle is which of three categories you need, because they find different things and are frequently confused. Software composition analysis reads dependency manifests and lockfiles and tells you a package you depend on has a known advisory; osv-scanner, npm audit, cargo audit, pip-audit, Snyk and Socket work this way. Static application security testing reads your own source and can find injection flaws, broken authorisation and hardcoded credentials; Semgrep, CodeQL, Snyk Code, Corgea and ZeroPath work this way. A third category, newer and much thinner, scans the agent configuration your coding tools run with.
How to read this
There is no ranking here and no winner, because the honest answer depends on constraints this page cannot see: whether your code may leave the machine, whether anyone will maintain what you write, and whether the diagram has to be reviewed in a pull request. Each entry says what it actually does and when to pick it.
Composition analysis: cheap, and bounded
It reads manifests and lockfiles against advisory databases. osv-scanner covers every ecosystem from lockfiles and is free; npm audit, cargo audit and pip-audit are per-ecosystem and already on most machines; Snyk and Socket add commercial data and supply-chain signals. The bound is absolute: it cannot see a flaw in code you wrote, because it never opens those files.
Static analysis: sees your code, at a cost
Semgrep is the most flexible, with custom rules in a few lines of YAML, which matters because your specific anti-pattern is not in anyone's default ruleset. CodeQL is deep and slow. Corgea and ZeroPath pair language models with program analysis to cut the false positives that make traditional SAST unpopular. The cost of this category is triage: a scanner that reports a hundred findings a week gets muted, and a muted scanner is worth nothing.
Agent configuration: new, and barely covered
Your coding agent launches MCP servers with its own file and network access, often via a command that fetches the latest version at every start. That is a supply chain with no version in it. Almost nothing scans for it. Lucid Train's audit does, flagging unpinned launches, remote and plaintext endpoints and credential-shaped environment variables in .mcp.json, .cursor/mcp.json, .vscode/mcp.json and .claude/mcp.json.
Where it should run
Composition analysis belongs in CI, where it blocks a merge. Static analysis belongs on the pull request, where the author still has context. Agent-config scanning belongs wherever you install MCP servers, which is a developer machine. Running everything in one place is the usual reason findings get ignored.
When this was checked
Every fact on this page was checked against the vendor's own site or repository on 22 August 2026. Prices and features change without notice, and a roundup is only as good as its last check, so verify anything you are about to make a decision on.
What each category can find
| Category | Finds | Cannot find |
|---|---|---|
| Composition analysis | Known advisories in dependencies | Anything in your own code |
| Static analysis | Injection, authz, secrets in source | A vulnerable transitive dependency |
| Agent config | Unpinned MCP servers, leaked env | Either of the above |
Questions
Related
- Which Local LLM Coding Setup Should You Use?The runtime is easy and the agent is easy. The model is where expectations need managing.
- Which Architecture Diagram Tool Should You Use?Four approaches, each with a different failure mode. Pick by which failure you can live with.
- Which Diagramming MCP Server Should You Use?The differentiator is not the vendor. It is whether a language model is being asked to do geometry.
- Which Coding Agent for a Large Unfamiliar Codebase?Model quality is table stakes. What separates agents on a big repo is context, review and isolation.
Last updated