About VDB

What is this?

VDB is a public vulnerability database for SBOM workflows. It aggregates CVE/OSV/GHSA/EUVD/HF/MCP and more into an OSV-compatible format, while also surfacing new risks created by AI-assisted coding.

Why?

The 2024 CVE funding crisis exposed how fragile the vulnerability ecosystem is when it depends on a single operator. At the same time, AI coding has accelerated dependency risks. VDB tries to address both.

Findings don't stop at "there's a problem" — we hand you the fix

Most scanners stop at "vulnerable". VDB goes further.

Each finding in a /sbom/scan response looks like:

{
  "id": "GHSA-29mw-wpgm-hmr9",
  "purl": "pkg:npm/lodash",
  "version": "4.17.20",
  "severity_bucket": "high",
  "severity_score": 7.4,
  "fixed_in": ["4.17.21"],
  "remediation": {
    "type": "upgrade",
    "ecosystem": "npm",
    "name": "lodash",
    "fixed": "4.17.21",
    "command": "npm install lodash@4.17.21",
    "manifest": "\"lodash\": \"^4.17.21\"",
    "rationale": "Upgrade lodash to 4.17.21 or newer via npm."
  },
  "affected_functions": [
    { "path": null, "symbol": "template" },
    { "path": null, "symbol": "templateSettings" }
  ]
}

We see the names attackers will target — before they do

Slopsquatting isn't a "package already attacked" problem — it's a "package about to be attacked" problem. When several LLMs all hallucinate the same fake name, the moment someone registers it under that name they'll be installed by every developer who follows the LLM. VDB's slop collector gathers those names before attackers register them.

Hook VDB into your AI coding tools — protection on autopilot

Claude, Cursor, Copilot and other AI assistants now write your code. Convenient — but follow their suggestions blindly and you end up installing slopsquatted packages, libraries with known vulns, or over-privileged MCP servers.

Connect VDB to your AI tool once. Just keep saying "build me this". Dangerous dependencies are filtered, suspicious ones get a warning — without you thinking about it.

What VDB protects against — and what it doesn't

VDB isn't a silver bullet. Here's an honest map of what we catch, what slips through, and the trust assumptions you should know about.

Prompt-injection defence (response text = data)

Attackers can plant payloads like "</instruction>" in OSV/CVE descriptions hoping an LLM treats them as directives. We sanitise every text field at the response boundary: strip control characters, cap at 500 chars, and defang known instruction-handover markers with a zero-width space. The /connect prompt also explicitly tells your agent that VDB response text is data, never instructions. Model-layer defence against prompt injection is unsolved industry-wide, but this defence-in-depth materially reduces practical risk.

Official domain

For VDB to work, the host in the prompt must be ours (or your self-hosted instance). If anyone hands you a "VDB prompt" pointing at an unfamiliar host, treat it as suspicious — official prompts are only published on vdb.ai.kr and from your own local instance.

Roadmap

Hidden from the main nav until collectors are populating data — we'll surface them automatically when there's something to look at.

Data sources

External feeds VDB ingests.