The Complex State of Vulnerabilities and Advisories in 2026: CVE, NVD, OSV, and Vendor Feeds
· Verimu
CVENVDOSVVulnerability ManagementCRA Compliance
If you've ever pulled vulnerability data into your own system, you've seen the chaos of the naming and ID system first-hand: CVE-, GHSA-, RHSA-, USN-, PYSEC-, RUSTSEC-, GO-, and many more.
In general, here is an initial overview of the landscape:
- CVE are the globally recognized IDs for publicly disclosed vulnerabilities.
- NVD numbers enrich CVE records with additional analysis (severity, CWE, applicability metadata).
- OSV standardizes package/ecosystem-oriented vulnerability records and aggregates many advisory sources.
- Many vendors and ecosystems publish their own advisories (Red Hat, SUSE, Ubuntu, Debian, Android, PyPI, RustSec, Drupal, etc.), each with their own identifiers and update cadence.
Why The Security Landscape Is So Fragmented
Three reasons:
- One issue, many IDs.
The same vulnerability can exist as a CVE, a GHSA, a distro advisory, and an OSV record with aliases. - Different product models.
NVD/CPE-style applicability and package-ecosystem version ranges are both useful, but not equivalent. - Asynchronous updates.
Publication, enrichment, fixes, and backports happen on different timelines.
Advisory Prefixes We Actually See (And What They Usually Mean)
Below is the consolidated prefix map from a real OSV-style corpus (your local sample set), grouped by advisory family, source, and typical environment/ecosystem.
| Prefix(es) | Typical source | Typical environment / ecosystem |
|---|---|---|
ALBA-, ALEA-, ALSA- |
AlmaLinux errata | AlmaLinux RPM ecosystems |
ALPINE-CVE- |
Alpine security tracker | Alpine Linux |
ASB-A-, PUB-A- |
Android Security Bulletins | Android |
BELL-CVE- |
BellSoft / Alpaquita advisories | Alpaquita |
BIT- |
Bitnami VulnDB | Bitnami packages/images |
CAN-, GSD-, UVI- |
CSA GSD database | General security dataset / Linux-oriented records |
CGA- |
Chainguard advisory feed | Chainguard packages |
CLEANSTART- |
CleanStart advisories | CleanStart ecosystem |
CURL-CVE- |
curl security advisories | curl/libcurl |
CVE- |
CVE Program records | Cross-ecosystem global ID space |
DEBIAN-CVE-, DSA-, DLA-, DTSA- |
Debian security trackers and advisories | Debian releases (main + LTS/testing streams) |
DRUPAL-CORE-, DRUPAL-CONTRIB- |
Drupal Security Team | Drupal core and contrib modules |
ECHO- |
Echo advisory feed | Echo ecosystem |
EEF-CVE- |
Erlang Ecosystem Foundation CNA | Erlang/Elixir ecosystem |
GHSA- |
GitHub Security Advisories | Cross-ecosystem package advisories |
GO- |
Go Vulnerability Database | Go modules |
HSEC- |
Haskell security advisories | Hackage |
JLSEC- |
Julia SecurityAdvisories.jl | Julia packages |
LSN-, USN-, UBUNTU-CVE- |
Canonical Ubuntu security notices | Ubuntu and Ubuntu Pro/ESM streams |
MAL- |
OpenSSF malicious-packages feed | Known malicious packages (npm/PyPI/etc.) |
MGASA- |
Mageia advisories | Mageia Linux |
MINI- |
mini.dev / MinimOS advisories | MinimOS |
OESA- |
openEuler security advisories | openEuler |
OSEC- |
OCaml security advisories | opam |
OSV- |
OSV/OSS-Fuzz style records | OSS-Fuzz and upstream projects |
PSF-, PSF-CVE- |
Python Software Foundation advisory DB | Python / CPython |
PYSEC- |
PyPA advisory database | PyPI |
RHSA-, RHBA-, RHEA- |
Red Hat advisories | RHEL and Red Hat package streams |
RLSA-, RXSA- |
Rocky Linux errata | Rocky Linux |
ROOT-APP-NPM-CVE-, ROOT-APP-NPM-GHSA-, ROOT-APP-PYPI-CVE-, ROOT-APP-PYPI-GHSA-, ROOT-OS-ALPINE-, ROOT-OS-DEBIAN-, ROOT-OS-UBUNTU- |
Root OSV feeds | Root-patched app and OS ecosystems |
RSEC- |
R advisory database | CRAN |
RUSTSEC- |
RustSec advisory DB | crates.io |
SUSE-SU-, SUSE-RU-, SUSE-FU-, SUSE-OU-, openSUSE-SU- |
SUSE/openSUSE update advisories | SUSE and openSUSE RPM ecosystems |
V8-FRESHNESS- |
Chromium policy vulnerability feed | V8 freshness / policy records |
CVE vs NVD vs OSV in one table
| System | Primary purpose | Best for | Not ideal for |
|---|---|---|---|
| CVE | Global vulnerability identifier and canonical record publication | Cross-vendor identifier linking and deduplication | Deep package version matching |
| NVD | CVE enrichment (severity, CWE, applicability metadata) | Risk scoring and compliance-oriented reporting | Fast package-level dependency matching in modern language ecosystems |
| OSV | Open-source vulnerability schema + aggregated package-centric data | Ecosystem/package/range-based matching | Being the sole source for every enterprise/vendor-specific product detail |
| Vendor/Ecosystem advisories | Product-specific fix and exposure guidance | Operational patching decisions for that platform | Cross-platform normalization by themselves |
How we handle this in practice
If you're building your own vulnerability backend:
- Store external IDs as a graph, not a single string.
Keeposv_id,cve_id,ghsa_id, and vendor IDs as linked identifiers. - Track source provenance per field.
"Severity from NVD" and "fixed version from vendor advisory" are different facts with different trust boundaries. - Use
modifiedtimestamps as your sync cursor.
Avoid polling by publication date alone. - Separate the "canonical vulnerability table" from "affected package projections."
This keeps ingest flexible when schemas evolve.
This sounds like extra work, but it is what prevents painful re-platforming six months later.
References
- OSV data dumps and
modified_id.csvformat - OSV schema specification
- CVE List v5 repository and release assets
- NVD API update workflow guidance
If you are mapping vulnerabilities to SBOM components for CRA workflows, this normalization layer is the part that usually determines whether your reporting is reliable or fragile.
Get started free → or book a demo if you want a CRA-first workflow without rebuilding this entire stack yourself.