Audit every
dependency.No build. No leaks.

Ten ecosystems + 9 CMS/frameworks + vendored JS + embedded JARs + native binaries

Point it at any checkout — multi-module, monorepo, polyglot. It parses manifests and lockfiles directly, and falls back to best-effort (pinned versions) when there's no lockfile.

Built for audits, not just CI

Inventoried as instances, not just lockfiles

A WordPress or Drupal site isn't a directory of lockfiles — it's a product with a version, plugins, themes and framework components. VigieVuln inventories the instance: core and component versions read from the tree's own markers, every dependency CVE attributed to the component that ships it, each instance reported in its own sub-chapter — synthesis included even when it comes out clean — and private/custom components kept separate, never sent to any publisher. Activated by the default --app-plugins auto.

Every advisory snapshot a live lane fetches is stamped and cached, carried by --export-cache / --import-cache, warmed from the air-gapped descriptor itself by --import-anonymized and reused automatically offline — the Wordfence API key never travels to the enclave. Full reference in docs/CMS-FRAMEWORKS.md.

Why use VigieVuln for code audits?

What it does for an audit that the others don't. Same column set and sourcing discipline as COMPARISON.md — an amber cell is partial and says how, and every cell is meant to be checkable.

1. No mvn/go/npm/pip/dotnet — manifests parsed off disk, nothing installed or executed. 105 × pom.xml in one pass, with versions mediated per module. The 2026-10-02 re-measurement recorded 834 pairs, including 705/705 OSV-Scanner pairs; see the benchmark for scope and historical comparisons.
2. 705 of 705 of OSV-Scanner's online Maven result in the 2026-10-02 re-measurement, under unshare -rn — no network interface. Tripwire-tested; only public coordinates ever leave the enclave.
3. Chapter 0 names every coordinate that every configured registry answered 404 for — Maven, npm, PyPI, NuGet, Composer, Go and RubyGems — with the manifest(s) declaring it. A registry that timed out is never counted. -e <regex> then excludes them.
4. -t <dir>: normalised POMs plus every non-Maven lockfile mirrored, private coordinates stripped. Archivable, and scannable by anything — --snyk included.
5. endoflife.date, split direct vs transitive so you know which dep to bump, plus deprecated / abandoned / yanked and outdated. Trivy covers OS distros only; Snyk's package health is web-only.
6. Inventory and verdicts: expiry, RSA<2048, MD5/SHA1, self-signed; private vs public keys; JKS/PKCS#12. Offline parser. Trivy's secret rule finds the file, not the flaw.
7. Identified by hash via deps.dev + CIRCL → should-be-declared / name≠checksum / unknown / malicious. Syft's patterns name a version, not an identity.
8. Chapter 0 flags what this scan could not reach (missing lockfiles, unresolved versions, incomplete application checks); Methodology states what the tool never assesses. Elsewhere the first is a log line the audit never sees, the second isn't written down.
9. Provenance manifest: tool, runtime, mode, run configuration and cache freshness for each consulted source. Grype and Dependency-Check carry one source's date, not the run.
10. Chapters 0→6 with an executive summary and fix recipes, self-contained HTML + findings JSON by default, with optional Word .doc. None of the others emits Word.
11. Four inline-SVG charts — CWE by worst severity, vulnerable transitives per root dep, your most vulnerable modules, fix-priority bands — rendered in the .doc too, with one-click copy as PNG (or a table as rich HTML) that pastes into Word formatted. Every CVE keeps its CVSS vector, CWE, references, CPE config and via-path behind a drill-down, with zero external assets.
12. --baseline adds a Δ chapter (new / fixed / unchanged); --fail-on-new gates on new findings only. Snyk tracks this on its platform, not as a local diff.
13. Symfony, Laravel, WordPress, Drupal, Joomla, PrestaShop, TYPO3, Magento/Adobe Commerce and SPIP inventoried per instance — core, plugins, themes, bundles, components, with direct/indirect attribution, publisher advisory feeds where they exist (Wordfence, packages.drupal.org, PrestaShop/TYPO3 GitHub) and WordPress core checksums. The others read lockfiles; none of them has a CMS-instance view. → the dedicated section
14. vigievuln serve-cache + --proxy-cache: one upstream call per provider resource per TTL for the whole fleet, single-flight coalescing, stale-if-error, and NVD/Wordfence/GitHub keys held by the server — use --wordfence-live to activate Wordfence with a server key. Trivy/Grype/DC cache a local DB; Snyk's lives on its platform.

Where it loses — containers/OS packages, auto-fix PRs, and CVE coverage against Snyk's curated feed: the gap, measured.
Deliberately not a goal — reachability. A finding is a vulnerable version on the dependency graph, and the report says exactly that in Methodology instead of guessing at call paths. Whether the vulnerable code is reachable in this application is the auditor's call, made with application context no scanner has.

Watch your direct dependencies.

The free tier watches one project, up to 100 direct dependencies and a 0.5 MB descriptor, for one month renewed by each upload; expiry deletes the monitoring data and triggers an email.

vigievuln login
vigievuln whoami
vigievuln watch ./project --name 'My Project'
vigievuln project status
vigievuln logout

vigievuln watch ./project --export fichier.json

Existing commands remain supported: vigievuln -s ./code, auth login|status|logout, --prepare-project and project push. Monitoring guide and update workflow ↗.

Where it fits

Not a Trivy/Grype replacement — those own containers and continuous CI. VigieVuln owns the zero-setup source audit with an air-gapped story (and now emits SBOM/VEX, flags licenses and prioritises by EPSS/KEV too).

² For pom.xml, transitives need Maven Central once — after that VigieVuln resolves the graph from its cached POMs, which is what makes the air-gapped run work. Snyk needs a real build, Trivy needs the network or a populated ~/.m2. Reach for Trivy or Grype+Syft for continuous CI, containers and SBOM pipelines.

³ EOL row is scoped to application frameworks and libraries. Trivy does compute an end-of-service-life status, but only for OS distributions. Snyk's package-health signal exists on its website, not in the CLI or CI output. Cells re-verified against upstream docs on 2026-09-14 (OSV-Scanner 2.6.0, Trivy 0.74.0, Grype 0.118.0 + Syft 1.51.1, Dependency-Check 13.0.0, Snyk CLI 1.1307.2) — detail and sources in COMPARISON.md.

Benchmark: Apache Dubbo 2.7.8

Five scanners, one public 105-module Maven reactor pinned to a commit, two questions. Every number below is recomputable from the tools' own JSON — the commands are in the benchmark doc.

1 · At full capability · historical comparison

Every scanner online, best configuration, populated ~/.m2. Union of all findings: 908 pairs.

“Not reported” is union arithmetic, not a verified recall gap. It counts pairs another tool produced and this one did not — a miss only if the public record actually binds that vulnerability to that coordinate and version. For VigieVuln that was checked pair by pair: 0 are recall bugs. The other rows have not been adjudicated, so read their column the same way. Trivy and Grype are container/SBOM scanners; a raw source checkout is not the job they are built for.

2 · With no network at all · historical comparison

Same tree, every scanner under unshare -rn — a namespace with no network interface, not just an offline flag. Reference: OSV-Scanner's own online output, 657 pairs.

100% here means "recovers everything OSV-Scanner finds with network access", not "finds everything that exists" — table 1 is the answer to that. OSV-Scanner returns the identical 37 with and without the namespace: it behaves exactly as documented, its transitive resolution is disabled offline by design.

3 · Every other ecosystem

VigieVuln claims ten ecosystems, and benchmarking one of them is not an answer. Same method on five more public projects, findings normalised to (package@version | CVE). Expect parity — that is the point. Outside Maven the transitive graph is already in the lockfile, so no scanner has a structural advantage and none should.

Equal CVE counts do not make two tools equivalent: on these same projects VigieVuln also reported 1 120 outdated dependencies on mastodon, 618 and 2 EOL frameworks on phpMyAdmin, 65 on poetry — questions OSV-Scanner does not attempt. Full per-ecosystem detail, targets and method → BENCHMARK.md.

4 · The Snyk delta, explained

131 pairs came back from Snyk and not from VigieVuln. Adjudicated one by one against OSV, none is a recall bug. Here is what they actually are.

# strip private modules, scan, merge Snyk
vigievuln -s ./proj -t ../clean -e "^client\." --snyk

Full method, per-tool configuration, the four bugs this benchmark found in VigieVuln, and every caveat → BENCHMARK.md.

Everything is documented

Per-flag usage, internals, and the full source — all in the repo.

Watch the actual CLI terminal demo

VigieVuln is a young project. Use its findings as a first pass, verify critical decisions, and report issues so the scanner keeps improving.