vulnerability-db

Security Policy

Reporting Security Issues

The AppThreat vulnerability-db maintainers take security reports seriously. If you believe you have found a vulnerability in vdb, please report it privately through GitHub Security Advisories.

Use this private reporting link:

https://github.com/AppThreat/vulnerability-db/security/advisories/new

Please do not open a public GitHub issue for suspected security vulnerabilities. Public issues are appropriate for bugs, feature requests, documentation improvements, data quality issues, and hardening suggestions that do not expose users to immediate risk. For anything that could affect release integrity, published database artifacts, package installation safety, database query safety, credential handling, or downstream scanner results, use the private advisory flow first.

A good report usually includes:

• the affected version or commit
• the impacted component or file if known
• a clear description of the issue
• reproduction steps or a proof of concept
• expected behavior and observed behavior
• any constraints, assumptions, or exploit prerequisites
• your assessment of impact

If your finding involves a third-party dependency, upstream vulnerability feed, registry, GitHub, Hugging Face, GHCR, ORAS, SQLite/APSW, or an external workflow tool rather than vdb itself, please consider reporting it to the upstream maintainer as well. If the impact on vdb users is still meaningful, report it privately here and explain the dependency relationship.

After the initial report, maintainers will triage the finding, may ask for more detail, and will coordinate remediation and disclosure as appropriate.

Service Level Agreements (SLAs)

The following response targets are best-effort goals, not contractual guarantees.

Severity	Initial Response	Triage / Confirmation	Remediation Target	Disclosure
Critical such as release pipeline compromise, malicious published database artifacts, arbitrary code execution during default install/use, or compromise of GHCR/Hugging Face publishing	48 hours	5 business days	15 business days	Coordinated with reporter
High such as SQL/query injection with practical impact, path traversal in custom data loading, unsafe artifact download behavior, token leakage, or vulnerability-result integrity failure with broad impact	5 business days	10 business days	30 business days	Coordinated with reporter
Medium such as denial of service on crafted database/feed input, validation bypass with limited impact, misleading metadata indexes, or security control regression	10 business days	15 business days	60 business days	Next suitable release
Low such as minor hardening gaps, verbose non-sensitive errors, documentation ambiguity, or low-impact defense-in-depth improvements	15 business days	30 business days	Best effort	Next suitable release

When remediation is available, maintainers may publish a GitHub Security Advisory and request a CVE where appropriate.

What Counts as a Genuine Security Issue

In scope

The following classes of issues are generally in scope for vdb.

• Supply chain and release integrity issues. This includes compromise or meaningful weakening of Python package publishing, GHCR image publishing, Hugging Face dataset publishing, ORAS artifact generation, or workflow integrity.
• Published database artifact integrity issues. Reports are in scope if an attacker can cause public .vdb7 files, metadata, compressed artifacts, or tags to be malicious, misleading, or not traceable to the intended workflow.
• Unsafe database handling. SQL injection, unsafe SQLite URI handling, path traversal through database paths, unsafe temp/journal behavior with security impact, or crafted database files that trigger unsafe behavior may be in scope.
• Unsafe source ingestion. Bugs that let crafted vuln-list, OSV, NVD, GitHub, npm, custom JSON/YAML/TOML, or zip inputs trigger code execution, uncontrolled file writes, credential leakage, or denial of service may be in scope.
• Credential or secret leakage caused by vdb. If vdb exposes tokens, secrets, credentials, sensitive environment data, or registry credentials in normal output, logs, metadata, or published artifacts, that is in scope.
• Vulnerability reporting integrity failures. A bug that can materially suppress, misstate, or poison results in a way that creates security risk for downstream scanners may be in scope.
• Unsafe download behavior. Issues in ORAS/Hugging Face/GHCR database download paths that allow unintended overwrite, unsafe extraction, trust bypass, or malicious artifact selection may be in scope.
• MCP server impact. Vulnerabilities in packages/mcp-server-vdb that expose data, execute unintended code, bypass expected tool boundaries, or misrepresent results are in scope.

Out of scope

The following are generally not considered vdb vulnerabilities on their own.

• Vulnerabilities in a user’s project or package. If vdb correctly reports a vulnerable dependency or OS package, that is a finding about the target, not about vdb.
• Upstream feed data quality without a vdb-specific exploit. Missing, incorrect, delayed, or disputed data in OSV, NVD, GitHub, npm, or vuln-list is usually a data quality issue unless vdb processes it unsafely or introduces a security-relevant misrepresentation.
• Dependency CVEs with no demonstrated impact. Automated reports that only state that a dependency has a CVE are not enough. Please explain reachability or impact on vdb.
• Operator-controlled unsafe deployment choices. Running untrusted custom data, replacing database URLs with untrusted mirrors, or exposing local files through broad mounts may be important guidance but is not always a product vulnerability by itself.
• Expected behavior of SQLite or external package tooling. Report upstream unless there is a clear vdb-specific unsafe delegation or trust-boundary bypass.
• Debug or explicitly verbose output. Reports should show why the observed output exceeds what the chosen mode reasonably implies.
• Social engineering, phishing, or local workstation compromise. These are outside normal product scope unless there is a repository-specific exploit path.
• Scanner-only submissions with no reproduction or impact story. Reports need enough context to evaluate exploitability and product impact.

Grey areas

Some findings require case-by-case review.

• False positives and false negatives. Not every accuracy bug is a security vulnerability, but systematic suppression or poisoning of results in default workflows can be security-relevant.
• Environment variable poisoning. vdb uses environment variables for paths, source selection, and workflow behavior. If a bypass meaningfully crosses trust boundaries beyond ordinary environment control, it may be in scope.
• Large-feed denial of service. Memory, disk, temp-file, or journal growth is often a reliability issue, but crafted data that makes common workflows unsafe may be security-relevant.
• Custom data processing. Local custom vulnerability data is powerful and usually trusted. In hosted or automated flows, the impact depends on who controls the custom data path and files.

Shared Responsibility Model

vdb sits at the intersection of vulnerability intelligence, SQLite storage, artifact publishing, and downstream scanner integrations. Security responsibility is shared between the project, its users, and upstream systems.

What vdb is responsible for

Area	Responsibility	Key Controls
Own code safety	Preventing injection, traversal, unsafe defaults, and unintended behavior in the vdb codebase	parameterized SQLite queries, safe temp-file handling, bounded batch processing, tests
Database artifact integrity	Publishing trustworthy .vdb7 and metadata artifacts	pinned workflow actions, least-privilege permissions, reproducible builds, metadata, controlled publishing
Source ingestion safety	Handling large or malformed upstream feeds safely	cached fixtures, streaming downloads, zip filtering, row-count and size tests
Search integrity	Returning accurate package and vulnerability matches	deterministic conversion tests, version comparison tests, metadata index tests
Artifact hygiene	Avoiding accidental leakage through metadata, logs, or release assets	no token logging, environment review, artifact review
Timely remediation	Addressing genuine product vulnerabilities in maintained versions	private advisory intake, triage, fixes, and coordinated disclosure

What users are responsible for

Area	Responsibility	Guidance
Database source trust	Choosing where database artifacts come from	Prefer internal mirrors or workflows for production. Use public AppThreat artifacts as bootstrap/defaults.
Deployment safety	Running VDB and MCP integrations in an appropriate trust environment	Restrict access to local database paths and server/tool integrations.
Custom data trust	Controlling custom JSON/YAML/TOML vulnerability definitions	Treat custom data as trusted policy input. Review it before use in CI or hosted services.
Filesystem and temp space	Providing safe storage for databases and SQLite temporary files	Set VDB_HOME, VDB_CACHE, and VDB_TEMP_DIR to controlled paths with sufficient space.
Network egress	Controlling access to external sources and artifact registries	Pin internal mirrors when required and monitor artifact provenance.
Result interpretation	Making remediation decisions with appropriate context	Validate critical findings against upstream advisories and package context.

Supported Versions

Security fixes are normally applied to the latest released major version. VDB v6 is the maintained SQLite-based line. Older v5 users should upgrade unless they have a specific compatibility requirement.

Public Disclosure

Please allow maintainers time to investigate and remediate before public disclosure. Coordinated disclosure helps protect downstream scanners, CI users, and teams that mirror the public database artifacts.

This site is open source. Improve this page.