Supply-chain checks for agent installs

Supply chain attacks love unchecked agent installs.

Malicious publishes, typosquats, and known CVEs ride in through dependencies—especially when tools default to @latest with no advisory context. SafeVersion answers in one GET: is it on the registry, which versions look safer against OSV, and what policy says—so your agent isn't installing blind. Suggestions, not guarantees.

d theme

Comparison: high supply-chain risk when agents trust latest with no publish-age or OSV context in the loop, versus one SafeVersion GET that returns registry-backed suggestions and advisory signals to reduce blind installs—not a guarantee against supply chain attacks.

Before

Supply chain: wide open

Classic supply-chain failure mode: grab latest, never re-check the tarball, and skip advisories—exactly how typosquats and bad publishes slip through.

Package

react

Install target

react@latest

Publish freshness

Not checked (risk window)

Known CVEs (OSV)

Not in your loop

Typosquat / real package?

You didn't verify

After

Supply chain: checks in the loop

Same dependency decision—one GET pulls registry truth and OSV-backed candidates into JSON so the agent can avoid the worst supply-chain mistakes before install.

Package

react

On the registry?

Found

Safer version picks

latestSafe · smallestSafeUpgrade

Supply-chain filters

Publish-age window + OSV among candidates

Also in JSON

Policy · links · optional release notes

What the API does today

One narrow endpoint: one package name per request. No lockfile scans, dependency trees, batch resolution, or hosted policy engine—just structured suggestions you can use from your own code.

  • Suggested versions per package

    GET /api/npm/{name} returns JSON with suggested picks such as latestSafe, using registry metadata, a minimum publish-age rule, and OSV-informed filtering among candidates—not a full advisory product.

  • Optional exact current

    Pass a single semver as current to get smallestSafeUpgrade (strictly greater than that version) and compare links when a GitHub repo is present. This is exact-version context, not range resolution.

  • Optional release notes

    Set releaseNotes when you want GitHub release snippets in the payload. Slower when enabled; entries may be missing depending on tags and upstream limits.

  • Normalization and clear errors

    Package names are validated and normalized before lookup. JSON error bodies for missing names, invalid current semver, not found, timeouts, registry failures, and other known cases.

  • Free and rate-limited

    No billing or API keys in Phase 1. Per-IP limits and burst protection keep the service sustainable for lightweight agents and scripts—exact limits may change.

How it works

Three steps from a package name to a structured answer—one package per call, no separate dashboard product.

  1. 01

    Point at a package

    Call GET with the package name—scoped or unscoped—and optional query params current (exact semver) and releaseNotes.

  2. 02

    One JSON response

    The API combines registry metadata, OSV-informed candidate filtering, optional release-note snippets, policy fields, and links into a single document.

  3. 03

    Use it your way

    Consume the JSON from scripts, agents, or your own tools. SafeVersion does not run your CI, open PRs, or enforce org policies—that stays on your side.

Agent-first by design

No dashboard, no SDK ceremony—your agent (or script) calls one GET per package and gets structured JSON: suggested versions, policy and security fields, links, optional release notes. Free, rate-limited. Full reference and try-it panels in the docs.

Open API documentation