dependency-vulnerability-scanning

Overview

Software composition analysis (SCA) matches the dependencies a repo declares (lockfiles, manifests, SBOMs) against vulnerability advisory databases. Each scanner family reads a different database, so their coverage differs:

The workflow below is the same for all three; the per-tool detail is in the references.

When to use

• A repo has no dependency scanning in CI yet.
• The team must choose between native audits, OSV-Scanner and Snyk, or layer two of them.
• A scanner reports findings and someone wants to suppress, waive or gate on them.

Step 1 - Pick the scanner

For full coverage run one native audit plus one cross-ecosystem scanner (OSV-Scanner or Snyk): each database misses advisories the others carry.

Step 2 - Scan the committed lockfile

Scan lockfiles, not loose manifests: a manifest range resolves to whatever is newest today, a lockfile is what actually ships.

npm audit --audit-level=high                     # npm; also yarn npm audit / pnpm audit
pip-audit -r requirements.txt                    # Python
cargo audit                                      # Rust
bundle-audit check --update                      # Ruby; --update refreshes the advisory DB
osv-scanner scan -L package-lock.json            # one lockfile
osv-scanner scan -r ./                           # every lockfile and SBOM under ./
snyk test --all-projects --severity-threshold=high

SBOM input: OSV-Scanner picks up SBOMs whose names follow the SPDX or CycloneDX patterns (*.spdx.json, bom.json, *.cdx.json) and scans one directly with osv-scanner scan source -L my-app.cdx.json; the components need Package URLs (OSV-Scanner source scanning). Snyk scans one with snyk sbom test --file=my-app.cdx.json (CycloneDX 1.4-1.6 JSON or SPDX 2.3 JSON, Enterprise plans) (Snyk sbom test). syft-generation produces the SBOM.

Step 3 - Check the scan saw packages

A scan that found no lockfile passes silently. Before trusting a green result, confirm the scanner reported the packages you expect.

OSV-Scanner makes this explicit with its exit codes (OSV-Scanner output):

For the other scanners, read the JSON report's dependency count, or run once against a branch with a known-vulnerable pin and confirm the job goes red.

Step 4 - Emit machine-readable output

osv-scanner scan -r ./ --format sarif --output-file osv.sarif
snyk test --sarif-file-output=snyk.sarif
pip-audit --format sarif --output pip-audit.sarif
npm audit --json > npm-audit.json

--format and --output-file are OSV-Scanner's output flags (OSV-Scanner usage); the container image takes the same arguments (installation). Upload SARIF to code scanning, and pass two or more reports to multi-tool-finding-triage (or the security-finding-triager agent) to dedupe findings across scanners.

Step 5 - False-positive triage

Suppress a finding only in a committed file, per advisory, with a reason, an approver and an expiry date, so it comes back for review:

Before suppressing as "not exploitable", prove it: reachability-analyzer checks whether the vulnerable function is called, and cve-exploitability-triage weighs EPSS and KEV. A severity threshold (--audit-level, --severity-threshold) is a scan filter, not a suppression. Templates per tool: references/snyk-policy-and-triage.md, references/osv-scanner-config-and-ci.md, references/ecosystem-config-and-triage.md, references/cargo-bundle-audit.md.

Step 6 - Gate CI

jobs:
  sca:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - if: hashFiles('package-lock.json') != ''
        run: npm audit --audit-level=high
      - if: hashFiles('requirements.txt') != ''
        run: pipx run pip-audit -r requirements.txt
      - name: OSV-Scanner (fails on findings and on exit 128)
        run: |
          docker run --rm -v "$PWD:/src" ghcr.io/google/osv-scanner:latest \
            scan -r /src --format sarif --output-file /src/osv.sarif
      - if: always()
        uses: github/codeql-action/upload-sarif@v3
        with: { sarif_file: osv.sarif }

With a Snyk license, add snyk test --severity-threshold=high on pull requests and snyk monitor on the default branch, which snapshots the dependency tree and alerts on CVEs disclosed later (Snyk CLI); the full job is in references/snyk.md.

Worked example

A Node + Python service has no SCA. Step 1: two ecosystems, no Snyk license, so npm audit and pip-audit as the fast gate plus OSV-Scanner for cross-ecosystem coverage. The first OSV run exits 128: the Python lockfile is requirements-lock.txt, a name OSV-Scanner does not detect, so the job is pointed at it with -L requirements-lock.txt and now exits 1 with two findings. One is a lodash advisory in a function the service never calls; reachability-analyzer confirms it, and an [[IgnoredVulns]] entry with ignoreUntil 90 days out and the approver's name goes into osv-scanner.toml. The other is upgraded. The job goes green, and the ignore resurfaces when it expires.

Anti-patterns

Limitations

• No scanner here does reachability: every advisory on a declared dependency counts, used or not. Use reachability-analyzer.
• Coverage differs by ecosystem in every database.
• Container images need trivy-image or the Grype flow in syft-generation.
• Automated upgrade PRs are dependabot-config and renovate-config.

References

• OSV-Scanner usage - -L, -r, --format, --output-file, --config.
• OSV-Scanner source scanning - SBOM file-name patterns, scan source -L.
• OSV-Scanner output - output formats and exit codes.
• OSV-Scanner installation - ghcr.io/google/osv-scanner image.
• Dependency-Check suppression - suppression file, until expiry.
• Snyk CLI - snyk test, snyk monitor, subcommands.
• Snyk sbom test - snyk sbom test --file, supported formats, Enterprise plans.
• Per-tool references: references/native-audits.md, references/osv-scanner.md, references/snyk.md.
• Sibling skills: syft-generation (SBOMs), reachability-analyzer, cve-exploitability-triage, multi-tool-finding-triage, dependabot-config, renovate-config, trivy-image.