Terminology
Advisory, severity, applicability, and source terms used by Basilisk.
The explorer separates version-range matches, platform/build applicability, and evidence coverage. A result in one of these categories does not establish the others.
The explorer's package versions come from conda-forge repodata. A PyPI, npm, GitHub, or other upstream identity links a conda-forge package to advisory data; it does not change where the listed releases were published.
| Term | Definition |
|---|
| Advisory | A source record describing a vulnerability or malicious package. Basilisk groups records with a shared canonical ID into one advisory in the explorer. |
CVE ID, for example CVE-2023-50447 | An identifier assigned to a vulnerability. Other databases may use different IDs for the same issue. |
| Alias / other ID | Another known identifier for the grouped advisory, such as a GHSA or PYSEC ID. |
| Severity / CVSS | The impact reported by an advisory source. CVSS scores range from 0 to 10; the score does not establish whether a particular version, build, or installation is affected. |
| Malware | A package reported as malicious, rather than a vulnerability in otherwise legitimate software. It may have no CVSS score. |
| Not scored | No usable numerical severity score is available in this result. It does not mean low severity. |
| Term | Definition |
|---|
| Version-range match | A matcher linked the package identity to an advisory and found the version among its reported affected versions or ranges. This is not proof of exploitability or the absence of a build patch. |
| No version-range match | The recorded checks found no matching affected range for the version. Read this alongside source coverage and freshness; it is not a claim that the installation has no vulnerabilities. |
| Checks incomplete | The required checks do not provide a complete result for the selected version or history. Some checks may have completed while others are missing or out of date. |
| No usable identity | Basilisk cannot run the relevant checks because it has no usable upstream identity for them. A mapping can exist without being usable by a matcher. |
| Version not known | The requested version is absent from Basilisk's indexed conda-forge release history. It is not a vulnerability result. |
| Inconclusive result / unknown applicability | The available evidence cannot establish the result for the requested scope. Missing, stale, unsupported, or ambiguous evidence can cause this. |
| Unconfirmed match / needs review | A package-linked report does not establish a version-range match. It may have unevaluated version information or no usable bounds. This describes the match evidence, not the credibility of the vulnerability report or a human review decision. |
| Count unavailable | Basilisk cannot establish the exact count. Positive matches may still be recorded; an unavailable count is neither zero nor proof that no checks ran. |
“Evaluated” depends on context. A source-coverage label says a check ran. An evaluated source record can have no matching versions; evaluated on a stored package–advisory match means at least one known version matched.
| Term | Definition |
|---|
| Evaluated (source coverage) | A recorded check used the named source revision for this scope. The result may be a match, no match, or inconclusive. Any incomplete-source qualification still applies. |
evaluated (stored package–advisory match) | At least one known version matched an advisory's affected versions or a usable range. |
unevaluated | The package identity joined the advisory, but its version information could not be evaluated. |
version_unbounded | The advisory identifies the product but has no usable version bounds. This does not establish an evaluated match for every version. |
| Not checked (a source) | No recorded check covers that source for the selected scope. Other sources may have been checked. |
| Source unavailable | The source or a usable identity needed to check it is unavailable. |
| Stale evidence | An input changed after the recorded evaluation. A retained positive result is historical evidence, not proof that the current inputs have been evaluated. |
| Partial coverage | Some required evidence or checks are incomplete. A positive match can coexist with partial coverage. |
| Source-data timestamp | A timestamp recorded for source data. It does not by itself prove that a complete source synchronization succeeded. |
| Term | Definition |
|---|
| Package history / all versions | A query across the indexed release history. Finding an affected version does not mean every version is affected. History advisory totals count each grouped advisory once. |
| Platform | A conda artifact subdirectory, such as linux-64, linux-aarch64, or noarch. It describes the published artifact, not every detail of the environment where it is installed. |
| Build | A published artifact identified by its version, platform, build string, and filename. Different builds of the same version can contain different bytes. |
| Range result | Whether the advisory's version and platform conditions match the queried scope. A no-match is specific to that advisory and scope, not a general safety claim. |
| Platform-dependent | A platform-qualified match exists, but no particular platform or build was selected. Read the platform-specific results rather than treating it as a package-wide positive. Platform conditions alone do not establish a match. |
| All platforms (result grouping) | Current, complete source evidence reports a match without a platform restriction. It does not establish patch status or exploitability. |
| All indexed platforms | The complete indexed artifact inventory agrees for the listed versions. Source platform conditions still apply; this is not the same as unrestricted evidence. |
| Term | Definition |
|---|
| Reported fixed version | A source-reported fixed boundary, or a version resolved from source-reported fix-commit evidence. Publication on conda-forge is a separate fact. |
| Fix committed upstream | A fix commit is recorded upstream. It may not belong to a release or map to a conda-forge version. |
| No fixed version reported | This result has no reported or resolved fixed version. A fix commit or backport may still exist. |
| Available from conda-forge | The exact reported version spelling exists in the indexed conda-forge releases. This is not proof that every build contains a security fix. |
| Fix could not be mapped to a release | Basilisk could not associate the upstream fix with a conda-forge release. This does not prove that no published build contains the fix. |
| First version outside the reported range | The first indexed release outside the range being described. Check the source and advisory scope; this is not a universal upgrade recommendation. |
| Patch / backport status unknown | The available evidence does not establish whether the selected build includes a patch. A higher build number alone is not proof of a fix. |
| Term | Definition |
|---|
| PURL | A package URL identifying a package in an ecosystem. Basilisk uses mapped upstream PURLs to connect conda-forge packages to OSV records. |
| CPE | A product identifier used by NVD. It can include version, hardware, and software conditions. |
| Upstream ecosystem | The ecosystem of a mapped package identity, such as PyPI or npm. The explorer still lists conda-forge releases. |
| Primary-PURL coverage | The proportion of indexed packages with a primary PURL mapping. It does not measure completed vulnerability checks; other identities, including CPEs, may also support matching. |
| Automatic identity | A package-to-project mapping created automatically. It is not evidence of manual verification. |
| OSV | osv.dev, a vulnerability database and schema for open-source packages. Basilisk ingests selected OSV ecosystems. |
| NVD | The U.S. National Vulnerability Database at nvd.nist.gov. Basilisk uses its CVE metadata and CPE configurations. |
| Anchore enrichment | Attributed replacement data for NVD applicability rules. NVD remains the advisory source, and the evidence records the enrichment revision. |
See How matching works for the evaluation rules, Advisory grouping for aliases and source records, and Using the API for structured scope and coverage results.
