Open-CVDB: The Missing CVE Database for Cloud Provider Vulnerabilities

Hook

When AWS accidentally exposed customer credentials through a metadata service vulnerability in 2019, no CVE was issued. In fact, most cloud provider security incidents never get a CVE identifier at all—leaving security teams flying blind.

Context

Traditional vulnerability databases like the National Vulnerability Database (NVD) work well for software with version numbers. A library has a flaw, it gets a CVE identifier, vendors patch it, and security scanners flag unpatched versions. This model breaks down completely in the cloud.

Cloud providers operate shared infrastructure that gets patched silently. When Azure had a container escape vulnerability affecting thousands of tenants, many customers never knew they were exposed. When GCP's metadata service allowed privilege escalation, there was no CVE to track it against. Cloud Security Providers (CSPs) have inconsistent disclosure practices—some publish detailed security bulletins, others quietly fix issues with minimal announcement, and many vulnerabilities only surface through researcher blog posts months after remediation. The Wiz security research team recognized this intelligence gap and created open-cvdb: a community-maintained database that catalogs cloud provider security issues with structured metadata, severity ratings designed for cloud architecture, and most importantly, actionable guidance for customers trying to understand their risk exposure.

Technical Insight

Open-CVDB is architecturally simple but strategically brilliant. It's a Git repository of YAML files—each documenting a single cloud vulnerability with standardized fields. The schema captures what traditional CVEs miss: which CSP is affected, which services, what the shared responsibility implications are, and crucially, what customers should do about it.

Here's what a vulnerability entry looks like:

Id: CVDB-2022-1234
Title: Azure Container Instances cross-tenant privilege escalation
Vendor: Microsoft
Product: Azure Container Instances
Advisory:
  Date: 2022-03-15
  URL: https://msrc.microsoft.com/update-guide/...
Severity: Critical
PiercingIndex: 9.2
Description: |
  A vulnerability in Azure Container Instances allowed an attacker 
  to escape container isolation and access other tenants' data on 
  the same physical host.
Impact:
  CustomerResponsibility: None - provider-side vulnerability
  DataExposure: Potential access to other tenants' container data
  RequiresAuth: Yes
  RemoteExploitable: No
Remediation:
  Customer: |
    No customer action required. Microsoft patched infrastructure.
    Review audit logs for suspicious activity during exposure window.
  Provider: Infrastructure patched 2022-03-10
Researcher:
  Name: Palo Alto Networks Unit 42
  URL: https://unit42.paloaltonetworks.com/...
References:
  - https://cloudvulndb.org/...

The Piercing Index is particularly noteworthy—it's a cloud-specific severity rating that considers factors CVSS ignores. Traditional CVSS scoring treats all vulnerabilities through a software lens: attack complexity, privileges required, impact on confidentiality/integrity/availability. But cloud vulnerabilities have unique characteristics. A provider-side vulnerability might have zero customer remediation options (unlike patching software), but massive blast radius (affecting thousands of tenants simultaneously). The Piercing Index weights these cloud-specific factors.

Contributors submit vulnerabilities through GitHub issues using a structured template that maps directly to the YAML schema. This turns vulnerability research into a pull request workflow—security researchers who discover issues can document them in the same place they share code. The maintainers review submissions for accuracy and completeness before merging.

The repository syncs automatically to cloudvulndb.org, which provides a searchable web interface. But the real power is that the data remains open and machine-readable. Security teams can clone the repository and integrate it directly into their threat modeling:

import yaml
import glob

# Load all vulnerabilities
vulns = []
for file in glob.glob('vulnerabilities/*.yaml'):
    with open(file) as f:
        vulns.append(yaml.safe_load(f))

# Filter for critical AWS vulnerabilities affecting your services
aws_critical = [
    v for v in vulns 
    if v['Vendor'] == 'AWS' 
    and v['Severity'] == 'Critical'
    and any(svc in v['Product'] for svc in ['S3', 'Lambda', 'EC2'])
]

# Generate risk report
for v in aws_critical:
    print(f"{v['Id']}: {v['Title']}")
    print(f"Piercing Index: {v['PiercingIndex']}")
    print(f"Customer Action: {v['Remediation']['Customer']}")
    print("---")

This programmatic access lets you build custom alerting, integrate vulnerability data into security dashboards, or cross-reference cloud incidents against your infrastructure inventory. The YAML format is human-readable for manual review but structured enough for automation—a sweet spot that makes the database useful for both security researchers writing blog posts and SOC teams running queries.

The project inherits content from Scott Piper's earlier 'CSP security mistakes' repository, which cataloged cloud misconfigurations and provider issues in markdown format. Open-CVDB extends this with formal schema, severity ratings, and remediation guidance—evolving from documentation to actionable intelligence.

Gotcha

The database is only as complete as public disclosures allow. Many cloud security incidents never become public—providers patch silently, affected customers may not realize they were exposed, and NDAs prevent disclosure. You're seeing the tip of the iceberg. If you're building compliance controls that require comprehensive vulnerability tracking, open-cvdb won't satisfy audit requirements because there's no guarantee of completeness.

The lack of a formal enumeration system like CVE numbering creates interoperability problems. Security scanners, SIEM systems, and GRC platforms don't recognize CVDB identifiers. You can't easily correlate these vulnerabilities with existing security tooling without custom integration work. And while the Piercing Index is theoretically more appropriate for cloud risks than CVSS, it's not widely adopted—meaning you'll struggle to compare severity across different vulnerability sources or explain ratings to auditors familiar with CVSS.

Verdict

Use if: You're a cloud security engineer building threat models for multi-cloud infrastructure, a security researcher studying cloud provider security practices, or a compliance team trying to understand shared responsibility boundaries for specific incidents. This database fills a genuine gap in cloud vulnerability intelligence and provides context you won't find in traditional CVE databases. The structured YAML format makes it perfect for integrating into security automation. Skip if: You need real-time vulnerability detection (this documents historical issues, not active scanning), comprehensive coverage for compliance requirements (too many gaps), or you're exclusively focused on application-layer vulnerabilities in your own code rather than provider infrastructure issues. Also skip if you need vendor-neutral severity ratings that integrate with existing security tools—the custom Piercing Index creates friction.