Vulnerable dependencies

Check the dependency versions in your proposed change against known vulnerability advisories.

Check ID: vulnerabilities. Engine: Zedbee’s bounded OSV API v1 client, verified against the Zedbee 0.1.0 source snapshot on September 7, 2026. API v1 is not an advisory-database version or freshness guarantee.

Enable the check

Choose coverage and outage policy explicitly

The thorough profile enables vulnerability analysis at error severity. fast and recommended leave it off unless you enable it, as shown here. The default outage policy is block.

With when: "relevant", the check runs when a discovered lockfile changes. A source-only edit normally does not trigger it. Use when: "always" to request the dependency check even when no lockfile changed; this changes scheduling, not Swarm’s change-attribution model.

The check reads lockfiles from the selected Git snapshots, not the installed node_modules tree. For local scans, stage policy and lockfile updates. For CI, commit and push them so the job checks out those versions.

Configure onUnavailable under the root checks.vulnerabilities policy. File-scoped availability overrides are rejected.

When settings updates take effect

{
  "schemaVersion": 1,
  "profile": "recommended",
  "checks": {
    "vulnerabilities": {
      "severity": "error",
      "when": "relevant",
      "onUnavailable": "block"
    }
  }
}

Supported inputs

Use a supported, committed lockfile format

These are lockfile format versions, not package-manager release versions. Both the baseline and target lockfiles must be readable when present.

Supported vulnerability lockfile formats
Package manager	Files	Supported format
npm	`package-lock.json` or `npm-shrinkwrap.json`	lockfileVersion 1, 2, or 3
pnpm	`pnpm-lock.yaml`	lockfileVersion 6.0 or 9.0
Yarn	`yarn.lock`	Classic format, or Modern metadata versions 4 through 8
Bun	`bun.lock`	Text lockfileVersion 1

Legacy bun.lockb is not parsed as a vulnerability inventory. Migrate it to Bun’s text lockfile using the package manager. If a text bun.lock is present in the inspected snapshot, the adapter excludes legacy binary Bun lockfiles from its inventory pass.

Parsing is bounded, including an 8 MiB file-size limit. pnpm and modern Yarn files that rely on YAML aliases are rejected rather than expanded. Unsupported formats, malformed records, and exceeded limits make analysis incomplete; regenerate the lockfile with the project’s package manager instead of hand-editing it to satisfy the scanner.

Attribution

Compare dependency state, not just package names

Swarm builds dependency inventories from the baseline and target lockfiles, queries OSV for the unique package-name and exact-version pairs across both, and compares advisory/package state with the available importer and dependency-path context.

The same package can appear at different versions or through different dependency paths. Those details matter to comparison; the check is not simply a list of vulnerable package names.

Existing unrelated dependency debt is not automatically assigned to your current change. when: "always" still compares baseline and target rather than turning Swarm into an all-dependencies audit. A newly published advisory affecting an otherwise unchanged dependency can appear on both sides of that comparison.

In CI, use scan --base <ref> to compare committed branch changes. A clean checkout with no staged changes is not a substitute for selecting the intended committed comparison.

Understand finding attribution Set up the CI comparison

git add package.json package-lock.json
git diff --cached --stat
npx zedbee scan --format json > zedbee-report.json

Data handling

What leaves your machine?

The vulnerability client sends package names, exact package versions, and the npm ecosystem identifier to api.osv.dev. It does not send repository source code or file hashes. Swarm discloses the service and metadata categories before scheduling online analysis.

OSV queries cover the union of baseline and target packages, so the metadata can include a version you are replacing as well as the new version. Package metadata can still be sensitive; review this disclosure before enabling the check in a restricted environment.

There is no offline advisory database. OSV results and online response bodies are not stored in Swarm’s scan cache. Results depend on service availability, advisory freshness, and supported lockfile data.

A known-vulnerability match is not proof that an application can exploit or reach the affected behavior. Conversely, no attributable findings does not prove that every dependency is safe or that unpublished vulnerabilities do not exist.

Stays local

Source codeSelected snapshotsAnalyzer outputSecret contentsFile hashes

OSV vulnerability request

Package name: sent
Exact package version: sent
npm ecosystem identifier: sent

Source code and file hashes are not sent to OSV.

Incomplete analysis

Decide what happens during an OSV outage

severity controls how vulnerability findings affect the gate. onUnavailable controls a different situation: whether a supported OSV availability failure can be non-blocking.

OSV outage policy and analysis errors
Situation	Policy	Outcome
OSV cannot be reached, times out, is rate-limited, or is unavailable	`onUnavailable: "block"`	Reports incomplete analysis and fails closed. The unavailable check is not treated as a pass.
The same supported availability failure	`onUnavailable: "warn"`	Reports the incomplete check without blocking on that outage. Other findings or incomplete checks can still block.
Malformed or unsupported lockfile, invalid OSV response, or exceeded analysis limits	Not an outage-policy exception	Remains an analysis error under the scan’s incomplete-result policy. onUnavailable: warn does not turn it into a warning-only outage.

An outage does not remove other findings or change their severity. Resolve reported parsing and response errors rather than weakening the outage policy to try to hide them.

Allowing an outage is not completing the check.

With onUnavailable: "warn", a commit or CI job can proceed without completed vulnerability analysis if nothing else blocks it. Choose that tradeoff deliberately and rerun the check when connectivity returns.

Act on a result

Update dependencies, then verify the change

Review the advisory ID, affected package and version, lockfile location, and attribution evidence. A report can include a fixed-version hint when supplied by the advisory; check the advisory’s affected ranges and your project’s compatibility before choosing an upgrade.

Use the package manager to update the direct dependency or the parent dependency that brings in an affected transitive package. Review the resulting manifest and lockfile changes, run your project’s tests, then stage and rescan. Swarm does not automatically upgrade packages through zedbee fix.

For incomplete analysis, zedbee doctor can help diagnose lockfile parsing and bounded OSV connectivity without running a scan. Fix the reported input or connectivity problem and retry. Do not treat exit code 2 as a clean result or discard it in CI.

Preserve the scan’s decision in CI

npx zedbee doctor
npx zedbee scan --format json > zedbee-report.json