Introducing Osprey: Security Visibility for the Software Supply Chain

Today we're launching Osprey, our open-source CLI (cra) for software supply chain visibility. You can find it on GitHub at Purplelotusec/Osprey.

Osprey builds a Software Bill of Materials (SBOM) from your project, cross-checks every component against the CISA Known Exploited Vulnerabilities (KEV) catalog, and tells you which dependencies are actively exploited in the wild — not merely “have a CVE.”

The Problem We Built It For

Most vulnerability tooling stops at “this package has a CVE.” That produces a lot of tickets and very little prioritization: a scanner that flags every CVE in your dependency tree, regardless of whether it's actually being exploited, trains teams to ignore the output. Osprey narrows the question to the one that actually matters for triage — is this specific component, at this specific version, known to be exploited right now?

What Osprey Does

• KEV detection — cross-checks every component against CISA's KEV catalog.
• Confidence tiers — high (PURL-backed exact match) vs. low (name/vendor match only), so you're never told to panic over a coincidental name match.
• Version intelligence — uses OSV to determine whether your installed version is actually affected, rather than flagging the whole package.
• Remote auditing — audit a GitHub repository without cloning it.
• SBOM signing — Ed25519 signatures in a DSSE envelope, with tamper detection.
• Alerting — a Slack-compatible webhook, batched into one message per run.
• CI-ready — GitHub Actions job summary, inline annotations, and SARIF output.

How It Works

Software / Repository
        ↓
   Dependencies
        ↓
       SBOM
        ↓
 Vulnerability Analysis
        ↓
    CISA KEV Match
        ↓
  Security Signal
        ↓
 Investigate & Respond

Instead of treating every vulnerability as the same, Osprey adds context around the software component, affected version, and known exploitation status.

Running it

A single command runs the whole pipeline: generate the SBOM, poll the KEV catalog, cross-check components, and report.

cra --path /path/to/your/project

Or point it at a GitHub repository directly, without cloning it locally:

cra --url owner/repo

When something is found, Osprey names the CVE, the exact affected component and version, and whether the OSV evidence actually covers your installed version — not just the package name:

exploitationStatus: "known_exploited" comes from CISA KEV independently of the OSV version check, so the two signals stay clearly separated rather than blended into one confidence-eroding score.

Why CISA KEV Matters

Vulnerability scanners can produce large numbers of findings. The CISA Known Exploited Vulnerabilities (KEV) Catalog provides an additional signal by tracking vulnerabilities known to have been exploited in the wild.

Osprey correlates that information with the dependencies found in a project, helping teams identify when actively exploited vulnerabilities may affect software they build or ship.

How Osprey Supports the EU CRA

The EU Cyber Resilience Act (CRA) introduces requirements around cybersecurity, vulnerability handling, security updates, and vulnerability reporting for products with digital elements.

The CRA creates a need for organizations to have visibility into vulnerabilities affecting their products and to respond to applicable actively exploited vulnerabilities through the relevant reporting process.

Osprey is not a CRA compliance or regulatory reporting platform, and its output is not intended to be relied on, or presented to an auditor, as proof of compliance on its own. Instead, it provides a technical visibility layer that can support the workflow:

Know what you ship
        ↓
Identify affected components
        ↓
Check exploitation status
        ↓
Investigate and respond
        ↓
Support your security process

Mapped against specific CRA themes, that looks like:

• Vulnerability handling — the KEV cross-check plus OSV version intelligence is the “is one of these components vulnerable, is it being exploited, does it affect us” workflow, not a raw CVE count.
• Documentation integrity — SBOM signing (Ed25519 in a DSSE envelope) gives the SBOM tamper detection, so the artifact is verifiable rather than taken on trust.
• Evidence of response — the CI-ready output (job summaries, annotations, SARIF, a versioned JSON result) gives you a record of what was checked, when, and what was found.

Know what you ship. Know what is affected. Know what is being exploited.

Osprey brings software inventory and exploitation intelligence together so security teams can act with better context.

Built to Be Honest About Its Own Limits

We'd rather Osprey under-claim than over-claim. A few things worth knowing before you rely on it:

• Lockfile coverage today is package-lock.json (npm) and exact-pinned requirements.txt (Python) — no yarn, pnpm, poetry, Go, or Cargo yet.
• low-confidence matches are name/vendor matches only, since CISA KEV's fields are free text rather than machine-precise CPE ranges.
• Version intelligence via OSV is npm-only for now.
• Signing uses local Ed25519 keys rather than Sigstore keyless signing or a transparency log.

Get Started

git clone https://github.com/Purplelotusec/Osprey
cd Osprey
npm install
npm link

cra --path .

For CI, add --fail-on-high to exit non-zero only on high-confidence, actively exploited matches:

cra --path . --fail-on-high --output results.json

View Osprey on GitHub →

This article is for general educational and product-information purposes. Osprey does not by itself establish CRA compliance, and it is not intended to be relied on — or presented to an auditor — as proof of compliance. Organizations should assess their specific obligations against the applicable EU legislation, standards, and official guidance.