Self-Hosted Vulnerability Feed Management: cve-search vs osv.dev vs Trivy-DB

Managing vulnerability data at scale requires more than running a scanner — you need a centralized, self-hosted vulnerability feed that aggregates CVE data from multiple sources, supports local querying, and integrates with your CI/CD pipeline. This guide compares three leading open-source vulnerability feed platforms: cve-search, osv.dev, and Trivy-DB.

Why Self-Host a Vulnerability Feed?

Running your own vulnerability feed server gives you complete control over vulnerability data, eliminates rate-limiting from public APIs, and enables offline scanning capabilities that are essential for air-gapped environments.

Data sovereignty and compliance. Many regulated industries require vulnerability assessments to run against locally cached data. Self-hosting ensures your security team can query vulnerability databases without sending package manifests or SBOM data to third-party services. For organizations subject to SOC 2, HIPAA, or ISO 27001 requirements, keeping vulnerability intelligence on-premises reduces audit scope and demonstrates due diligence.

Performance at scale. Public vulnerability APIs like the NVD enforce rate limits that throttle automated scanning pipelines. A local feed server processes thousands of queries per second with no throttling, enabling continuous monitoring of large container registries or artifact repositories. Organizations with 10,000+ container images or 50,000+ dependencies benefit from sub-millisecond local response times versus hundreds of milliseconds for remote API calls.

Air-gapped and offline environments. Production environments in defense, finance, and critical infrastructure sectors often operate without internet connectivity. A self-hosted vulnerability feed can be updated periodically via secure transfer mechanisms and then serve as the authoritative vulnerability source for all internal scanning tools, from CI pipeline integration to production container monitoring.

Cost optimization. Commercial vulnerability intelligence subscriptions can cost tens of thousands of dollars annually. Open-source feed platforms provide comparable data coverage — including NVD, GitHub Advisory Database, OSV ecosystems, and vendor-specific feeds — at zero licensing cost.

For vulnerability scanning integration, see our OpenVAS vs Trivy vs Grype comparison. For broader endpoint security management, our Fleet vs Wazuh vs Teleport guide covers the scanning layer. When combined with proper SSH access controls, as detailed in our SSH certificate management guide, you get a complete security stack.

Comparison Overview

cve-search: Full-Featured Local CVE Database

cve-search is a comprehensive vulnerability database tool that imports and enriches NVD data with additional sources like CPE dictionaries, CWE classifications, and CAPEC attack patterns.

Architecture: cve-search uses MongoDB as its backend and provides a full-text searchable database of all known CVEs. The import pipeline fetches NVD JSON data, CPE dictionaries, and enrichment data from various sources, then indexes everything for fast querying.

Key Features:

• Full NVD import with CWE and CAPEC enrichment
• CPE 2.3 dictionary matching for accurate product identification
• Full-text search across descriptions, references, and configurations
• REST API for programmatic access
• Web interface for browsing and searching vulnerabilities
• Plugin system for custom data sources
• Brokering mechanism to share vulnerability data between instances

Docker Compose Deployment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

version: '3.8'
services:
  mongodb:
    image: mongo:7
    volumes:
      - mongodb_data:/data/db
    command: mongod --quiet

  cve-search:
    image: cve-search/cve-search:latest
    ports:
      - "5000:5000"
    environment:
      - MONGO_HOST=mongodb
      - MONGO_PORT=27017
    depends_on:
      - mongodb
    volumes:
      - cve_data:/var/lib/cve-search

  web:
    image: cve-search/cve-search:latest
    ports:
      - "8080:80"
    command: python3 web/index.py
    environment:
      - MONGO_HOST=mongodb
    depends_on:
      - mongodb

volumes:
  mongodb_data:
  cve_data:

Initial setup requires a data population step:

1
2
3
4
5
6
7
8

# Run the import pipeline (first time - takes several hours)
docker exec -it cve-search python3/sbin/db_updater.py -v

# Query a specific CVE via the API
curl http://localhost:5000/api/cve/CVE-2024-12345

# Search for vulnerabilities by product
curl "http://localhost:5000/api/search/openssl"

Best for: Security teams needing a comprehensive, searchable CVE database with enrichment data and a web interface. Ideal for organizations that need to query vulnerabilities by CPE identifiers or vendor names.

osv.dev: Modern Unified Vulnerability Database

osv.dev is Google’s open-source vulnerability database and triage service that aggregates vulnerability data from multiple ecosystems into a single, standardized format.

Architecture: osv.dev uses a Git-based storage model where each vulnerability is stored as a JSON file in a Git repository. This enables transparent versioning, easy diffing, and straightforward replication. The service supports multiple ecosystem-specific databases (Go, PyPI, npm, Maven, crates.io, Linux, etc.) through a unified API.

Key Features:

• OSV format standard adopted by major ecosystems
• Git-based storage with transparent versioning
• Unified API across all ecosystems
• Ecosystem-specific databases with specialized schemas
• Affected version range computation
• GitHub Advisory Database integration
• GraphQL API support
• Batch vulnerability checking

Self-Hosting with Docker:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

version: '3.8'
services:
  osv-api:
    image: gcr.io/oss-vdb/osv-api:latest
    ports:
      - "8080:8080"
    volumes:
      - osv_data:/var/lib/osv
    environment:
      - WORKERS=4

  osv-worker:
    image: gcr.io/oss-vdb/osv-worker:latest
    volumes:
      - osv_data:/var/lib/osv
    depends_on:
      - osv-api

volumes:
  osv_data:

Alternative lightweight approach using the OSV-Scanner CLI:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Install osv-scanner
go install github.com/google/osv-scanner/cmd/osv-scanner@latest

# Scan a directory for vulnerabilities
osv-scanner --lockfile=package-lock.json
osv-scanner --lockfile=requirements.txt
osv-scanner --recursive /path/to/project

# Use the OSV API directly
curl -d '{"commit": "YOUR_COMMIT_HASH"}'   https://api.osv.dev/v1/query

Best for: Development teams working across multiple language ecosystems who want a unified vulnerability query interface. The OSV format is becoming the industry standard for vulnerability data exchange.

Trivy-DB: Container-Optimized Vulnerability Database

Trivy-DB is the vulnerability database powering Aqua Security’s Trivy scanner, providing optimized vulnerability data specifically tuned for container image and artifact scanning.

Architecture: Trivy-DB is a lightweight BoltDB database that ships as a standalone artifact. It downloads vulnerability data from multiple sources (NVD, GitHub Advisory Database, Alpine, Red Hat, Debian, etc.) and compresses it into an efficient format that can be embedded directly into scanning tools.

Key Features:

• Optimized BoltDB format for fast local queries
• Multi-source data aggregation (NVD, GitHub, distro feeds)
• Language-specific vulnerability data (Go, Python, Ruby, Node.js, Java, .NET, PHP)
• OS package vulnerability data (Alpine, RHEL, Debian, Ubuntu, Amazon Linux, etc.)
• IaC misconfiguration data (Docker, Kubernetes, Terraform, CloudFormation)
• Lightweight database (~100MB compressed)
• Automatic updates every 6 hours

Using Trivy-DB as a standalone feed:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# Download the latest vulnerability database
trivy image --download-db-only

# The database is stored at ~/.cache/trivy/db
ls -lh ~/.cache/trivy/db

# Query the database for a specific CVE
trivy image --severity HIGH,CRITICAL myapp:latest

# Run as a local vulnerability feed server
# (using Trivy's built-in server mode)
trivy server --listen 0.0.0.0:4954

# Clients can then query the server
trivy image --server http://localhost:4954 myapp:latest

Docker Compose for Trivy server mode:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

version: '3.8'
services:
  trivy-server:
    image: aquasec/trivy:latest
    command: server --listen 0.0.0.0:4954
    ports:
      - "4954:4954"
    volumes:
      - trivy_cache:/root/.cache/trivy
    restart: unless-stopped
    environment:
      - TRIVY_SKIP_DB_UPDATE=false
      - TRIVY_SKIP_JAVA_DB_UPDATE=false

volumes:
  trivy_cache:

Best for: Container security teams and CI/CD pipelines that need fast, lightweight vulnerability lookups. The embedded database format makes it ideal for embedding in scanners and automated pipelines.

Choosing the Right Vulnerability Feed

FAQ

What is a vulnerability feed server?

A vulnerability feed server is a self-hosted service that aggregates, stores, and serves vulnerability data from multiple sources (NVD, GitHub Advisory, vendor feeds). Unlike vulnerability scanners that check specific packages, a feed server provides the raw intelligence data that scanners, dashboards, and monitoring tools consume.

Why should I self-host vulnerability data instead of using public APIs?

Self-hosting eliminates rate limits, enables offline operation, reduces query latency, and keeps sensitive package manifests private. Public APIs like the NVD enforce strict rate limits that break automated scanning pipelines at scale.

How often should I update my vulnerability database?

For production environments, update at least daily. Critical vulnerability feeds (like Trivy-DB) update every 6 hours. cve-search recommends daily NVD syncs. osv.dev updates continuously as new advisories are published.

Can I run a vulnerability feed in an air-gapped environment?

Yes. All three platforms support offline operation. cve-search and Trivy-DB can be fully populated on an internet-connected system and then transferred to air-gapped networks. osv.dev’s Git-based format makes it easy to mirror and transfer via secure media.

Which vulnerability feed is best for container security?

Trivy-DB is purpose-built for container scanning with optimized BoltDB storage and comprehensive OS/language package coverage. Its server mode allows multiple scanners to share a single local database, reducing download overhead.

How much disk space does a vulnerability database require?

cve-search with MongoDB requires 5-15GB depending on enrichment data. osv.dev’s Git repositories total approximately 2-3GB. Trivy-DB is the most compact at approximately 100MB compressed, expanding to about 500MB when loaded.

Choosing the Right Platform for Your Organization

For large enterprises with compliance requirements, cve-search provides the most comprehensive feature set with CPE matching, CWE enrichment, and a web interface. The MongoDB backend handles millions of CVE records with full-text search.

For development teams working across multiple language ecosystems, osv.dev’s unified API and OSV format provide the most consistent query experience across Go, Python, npm, Maven, and other ecosystems.

For container-focused organizations and CI/CD pipelines, Trivy-DB’s lightweight format and native scanner integration make it the most practical choice. The server mode enables centralized vulnerability data distribution across all scanning nodes.