Find Known Vulnerabilities — and Who Introduced Them

A vulnerability scanner that ends with a list of forty CVEs has done the easy half of the job. The hard half is everything the list leaves out: which of these are real for your build, who introduced each one, and how long you have been exposed. Without that, the report is a to-do list with no owner and no deadline — so it sits.

vg scan --full does the whole job. It finds known vulnerabilities across your lockfiles, enforces the dependency policy you commit to your repo, and pairs with vg why to name the commit that introduced each open advisory.

One command

vg scan --full turns on known-vulnerability detection and, when you have committed a standards policy, a banned-dependency report — on top of the drift scoring and code map you already get from a bare scan:

$ vg scan --full
✖ 4 known vulnerabilities · 1 critical, 2 high, 1 moderate
✔ Standards: no banned dependencies in use

If you only want the vulnerability pass, vg scan --vulns does that alone.

Known vulnerabilities across 14+ ecosystems

Vibgrate reads each project's lockfile and checks the resolved versions against the OSV advisory database. That means coverage well beyond npm: pnpm and yarn, pip, poetry and pipenv, Cargo, Composer, Bundler, Go modules, pub, Hex, NuGet, and Maven or Gradle. Each finding records the advisory id and CVE, the severity, the CVSS score, and the version that fixes it — written into the scan artifact, the findings, and the SARIF output so it lands in your code-scanning dashboard.

Banned dependencies: your policy, enforced

Not every risk is a CVE. Some packages are banned inside your organisation — unmaintained, wrongly licensed, or simply replaced by an approved alternative. Vibgrate reads a standards policy you commit at .vibgrate/standards.json and reports any banned dependency in use, with the reason and the alternative:

$ vg scan --full
⚠ Standards: 1 banned dependency in use
  banned  npm:request 2.88.2 → use undici (request is deprecated)

The scan reports; it does not fail your build on its own. When you want a hard gate, that is a separate, explicit step (below), so a report never surprises a pipeline.

Who introduced it? vg why

A CVE with no history is hard to act on. vg why replays a package's version timeline against the advisory ranges and attributes each open vulnerability to the commit — and the author — that first introduced the affected version:

$ vg why lodash
lodash 4.17.19
  introduced 2023-08-11 by a.developer  ("bump deps for release 3.2")
  open advisory GHSA-… · exposed 331 days

Attribution comes from your git history and the most recent vg scan --vulns. It is not about blame — it is about routing. The person who introduced a dependency is usually the fastest person to upgrade it safely, and the exposure window tells you how urgent that conversation is.

Exposure windows and the remediation clock

For teams working to a standard like the EU's Cyber Resilience Act, "we fixed it eventually" is not evidence. Vibgrate computes how many days each advisory has been open and measures remediation against severity-based service levels — a critical flaw is on a far shorter clock than a low one. That turns a pile of CVEs into a set of deadlines you can actually manage and report against.

Gate CI without blocking on noise

Reporting and gating are deliberately separate. To fail a build when a banned dependency is in use, run the standards gate, which exits non-zero on a violation:

$ vg drift --fail-on standards

Because the gate is explicit, you choose exactly what blocks a merge and what is only surfaced — no scan quietly turns red on you.

Try it

$ vg scan --full
$ vg why <package>

The vulnerabilities reference and the vg why reference cover the flags and output formats, and the supply-chain guide shows how the pieces fit into an evidence trail.