Data flow
How package identities, versions, and advisories become match results.
The worker ingests package identities, versions, advisories, and attributed applicability enrichment, then 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 | Artifact metadata and distinct package/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 |
| Anchore NVD overrides | Attributed replacements for NVD CPE configurations | Immutable Git archive at a resolved commit | Daily, after NVD |
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 effective NVD configurations. An active Anchore replacement supersedes the original configurations without changing NVD metadata.
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.