Glossary

Key terms and concepts used throughout the Ossprey documentation and product.

SBOM (Software Bill of Materials)

A structured inventory of all software packages and dependencies in a project. Ossprey generates an SBOM by analysing your package manifest files and lockfiles (e.g. package.json, requirements.txt, poetry.lock), then submits it to the Ossprey service for malware analysis. SBOMs are the foundation of software supply chain security — they let you know exactly what's in your software. Ossprey's own format is OSSBOM.

Scan

The process of analysing a project's dependency tree for malicious packages. A scan begins with SBOM generation (identifying all packages), followed by submission to the Ossprey service for analysis. Scans can be triggered via the dashboard, the GitHub integration, the CLI, or the API.

Verdict

The outcome of a scan for a given package: Safe (no malicious behaviour detected) or Malicious (intentionally harmful code identified). A component may also be Not found (couldn't be resolved in its registry) or Unsupported (an ecosystem Ossprey doesn't analyse yet) — neither is a verdict, and both are shown explicitly so a clean result never hides an unchecked package.

An overall scan carries its own result, which additionally covers partial coverage (Warning, Skipped) and failure — see Scan results explained.

Finding

A detected problem in a package. Ossprey uses "finding" rather than "vulnerability" because it detects malicious behaviour — exfiltration, backdoors, obfuscated payloads — not published CVEs in otherwise legitimate code. Each finding you own carries a triage status you control (Open, Investigating, Fixed, Won't Fix, False Positive).

Threat card

The evidence behind a malicious verdict: severity, threat type, a human-readable justification, the code excerpts that triggered the detection, and mappings to MITRE ATT&CK techniques and Ossprey TTPs. See Scan Results.

Severity

How serious a finding is, on a five-point scale: Info, Low, Medium, High, Critical. Severity is what alert rules threshold on — see Notifications & Alerts.

TTP (tactics, techniques and procedures)

The standard vocabulary for describing how an attacker operates. Ossprey maps findings to MITRE ATT&CK technique IDs, plus its own TTP taxonomy for supply-chain behaviours that ATT&CK doesn't name directly. The mappings let an Ossprey finding slot into detection and reporting frameworks you already use.

Scan job

The unit of work that processes a scan request on the Ossprey backend. A scan job progresses through statuses — typically queued, in progress, and succeeded (or failed). You can track scan job progress from the dashboard, via the CLI's verbose output, or by polling the API.

Artifact cache

A registry proxy or mirror your builds pull packages through — AWS CodeArtifact, for example. Ossprey can record what was actually pulled through a cache and report a verdict for each package, which catches installs that never appear in a committed manifest. See Artifact Caches.

Alert rule / destination

A destination is somewhere alerts are delivered (an email address, a Slack channel, an incident.io alert source). A rule pairs a trigger condition — malware detected, a severity threshold, a scan failure — with the destinations it notifies. See Notifications & Alerts.

Quota

The number of packages your plan lets you scan per day and per month. Exceeding it causes scans to be skipped rather than failed, so a quota limit never breaks a build. Packages resolved from cache or by reputation aren't charged. See Security & API Keys.

Malicious package

A software package identified as containing intentionally harmful code. Common attack vectors include data exfiltration (stealing environment variables, credentials, or files), backdoors (providing remote access to attackers), typosquatting (mimicking popular package names with slight misspellings), and dependency confusion (exploiting private/public package name collisions).

GitHub App

The mechanism by which Ossprey integrates with GitHub. The Ossprey GitHub App is installed at the organisation or account level and grants read access to repository metadata and contents, enabling automated scanning on pull request, on a nightly or weekly schedule, or on demand. It reads your repository to build an SBOM — and, for public repositories where you've enabled code scanning, to analyse the code itself — but never stores your source code. See GitHub Integration.

Ecosystem

A package registry and its associated tooling — for example, npm (JavaScript), PyPI (Python), Maven (Java), Cargo (Rust). Ossprey currently supports npm and PyPI. If you need another ecosystem, tell us at [email protected] — demand drives the order we add them.

OSSBOM

Ossprey's own SBOM format: a format marker plus a list of components, each identified by a Package URL. It's what the CLI produces (--local, or -o file.json) and what the API accepts. See the API Quickstart.

purl (Package URL)

The standard, registry-agnostic way to name a package version — for example pkg:npm/[email protected] or pkg:pypi/[email protected]. Ossprey identifies components by purl throughout the API, and alert rules can be scoped to one.

👍

Missing a term?

This glossary will grow as Ossprey evolves. If you encounter a term that isn't listed here, let us know at [email protected].