Dependency vulnerability scanning (SCA)

The Snitch CLI and GitHub Action ship with a software-composition-analysis (SCA) pass that runs alongside the AI code review. It parses package manifests in your repo, queries OSV.dev for known vulnerabilities affecting each pinned version, and renders the results in the same sticky comment / SARIF / markdown report as the rest of your findings.

It is on by default. No extra config, no extra subscription.

Ecosystems supported

Ecosystem	Files parsed
npm	package-lock.json (v1, v2, v3), yarn.lock, pnpm-lock.yaml
PyPI	requirements.txt, poetry.lock, Pipfile.lock, uv.lock
Go	go.sum, go.mod
Rust	Cargo.lock
RubyGems	Gemfile.lock
Maven	pom.xml, gradle.lockfile
Packagist	composer.lock
NuGet	packages.lock.json, *.csproj

If a manifest sits in a path the GitHub Action sees as part of the changed file set (or the CLI sees in its scan scope), it gets scanned.

How findings render

In the PR sticky comment, vulnerable dependencies appear in their own section, grouped by package:

• A top-line table lists every vulnerable package with its version, CVE count, worst severity, and the manifest file
• Each package has a collapsible block containing a per-CVE table with severity, the GHSA / CVE ID linked to the advisory, and a one-line summary
• A "suggested fix" line per package tells you which version range to upgrade out of

In GitHub Code Scanning, each vulnerable package becomes a single rule (SNITCH-SCA-{ecosystem}-{name}), and each CVE is one alert under that rule with a clickable link to the GHSA or NVD advisory page. Dismiss / triage state persists across runs because we use stable per-package fingerprints.

In the markdown artifact (SECURITY_AUDIT_REPORT.md), the same grouped layout — same as what reviewers see on the PR.

Disabling SCA

Some teams already run npm audit / pip-audit / cargo audit in CI and don't want the duplication. Both surfaces have an opt-out:

GitHub Action: set the include-dependencies input to false in your workflow:

- uses: snitchplugin/snitch-github-action@v1
  with:
    snitch-license-key: ${{ secrets.SNITCH_LICENSE_KEY }}
    include-dependencies: false

CLI: pass --skip-sca on a single run, or set SNITCH_SKIP_SCA=1 in your environment to disable globally:

snitch scan --skip-sca
SNITCH_SKIP_SCA=1 snitch scan

Privacy

The SCA pass talks to api.osv.dev (a Google-operated public service) over HTTPS. The body of each request is { ecosystem, name, version } — your package name and version, never your code or any internal identifier.

Responses are cached on the runner's local disk under a sha256-hashed key ({shortHash}.json in a tmp directory) for 24 hours, so re-runs against the same lockfile don't re-hit the API.

OSV requests are bounded: 10-second wall-clock timeout, 5MB response cap, max 5 in-flight at a time. Rate limits and timeouts surface to the workflow log without hiding behind silent zeros.

Plugin (skill mode)

The Plugin variant of Snitch (the one that drops into Claude Code, Cursor, Codex, etc.) doesn't make network calls, so it can't query OSV directly. Instead, the methodology category for vulnerable dependencies instructs the AI to enumerate every pinned dep in your lockfiles and flag anything visibly old or matching a known-bad pattern from training data. Precision is lower than the deterministic CLI / Action path; if you need real CVE matching, run the CLI on the same repo.

What it doesn't catch

• Transitive resolution that changes at install time: if your package.json says "lodash": "^4.0.0" and there's no committed lockfile, we can't know which version will actually install. Commit a lockfile.
• CVEs published after your scan but before deploy: caches expire after 24 hours, but a freshly-published CVE between scan and deploy isn't covered. Run on every PR.
• Vulns in private / internal packages: OSV only knows about public-registry advisories. Internal packages need internal review.
• Malicious-but-not-yet-disclosed packages: zero-day supply chain attacks don't have OSV entries until somebody files them. The Plugin's "Typosquatting & Install Scripts" category catches some heuristics here.