Architecture overview
The data sources, system boundaries, and main Basilisk data flow.
Basilisk sits between public vulnerability sources and conda-forge users. It ingests package and advisory data, derives matches, and serves them through the audit API and explorer.
Data flow
Inputs, ingestion jobs, matching, and API outputs.
How matching works
Identity joins, version ranges, comparators, and applicability.
Advisory grouping
How OSV and NVD records are grouped under a canonical CVE.
Traceability
The source data and operations behind a match.
Package identity
purl-associator owns the mapping from conda-forge packages to upstream identities: primary PURLs, alternative PURLs, and CPE 2.3 vendor/product prefixes.
Basilisk does not edit those mappings. It syncs the published payloads and combines them with conda-forge repodata, OSV advisories, and NVD CVEs.
Stored data
Postgres holds:
- synced package identity mappings,
- the package and version universe from conda-forge repodata,
- the OSV and NVD fields needed for matching and display,
- derived package/advisory matches with applicability, confidence, and provenance.
The source projections stay separate. OSV and NVD records can describe the same vulnerability, but Basilisk keeps the original records and groups known aliases for API and explorer responses.