Data flow
How package identities, versions, and advisories become match results.
The worker ingests four inputs and reconciles them into package/advisory matches.
Inputs
| Source | Used for | Transport | Cadence |
|---|---|---|---|
| purl-associator | PURL and CPE package identities | Published JSON payloads | Daily |
| conda-forge repodata | Package and version universe | Sharded repodata via rattler | Daily |
| OSV | PURL-based advisories and affected ranges | Per-ecosystem bulk dumps | Daily |
| NVD | CVE metadata and CPE configurations | NVD API 2.0 | Daily incremental sync |
Pipeline
The worker runs ingestion and matching jobs through a Postgres-backed queue. The API reads the resulting projections and matches; it does not fetch upstream data during a request.
Matching
The matcher uses two main paths:
- PURLs connect package identities to OSV affected entries.
- CPE vendor/product prefixes connect package identities to NVD configurations.
It then evaluates the reported ranges against the versions known from conda-forge repodata. A reconcile writes the current result to package_advisory_matches and removes stale matches.
A match also records range applicability and identity confidence. This is what separates a version-range match from one with missing bounds or an unverified identity. How matching works covers the range rules and comparators in detail.
Outputs
The API exposes:
- OSV-compatible query responses,
- package and advisory endpoints for the explorer,
- provenance, confidence, and freshness data,
- status and job information for operators.
The API reference in this site is generated from the API's OpenAPI document.