Integrations

Every integration below runs the same SBOM scan against the same data, so a lockfile reads the same everywhere. They all share the same limits and the same API token.

Generate a token at vuln.mlab.sh/me/tokens (Free: 1 token, Pro and Team: 5). Scans made with it land in your scan history. Every integration waits out the cooldown when it scans several files in a row.

In your editor

VS Code and compatible editors (Cursor, Windsurf, VSCodium, code-server, vscode.dev...): Visual Studio Marketplace, Open VSX. Scans on change after a one-time consent, diagnostics on the vulnerable line, CVE hovers. Details: VS Code extension.

JetBrains IDEs (IntelliJ IDEA, PyCharm, GoLand, WebStorm, PhpStorm, RubyMine, RustRover, CLion, Rider, Android Studio...): JetBrains Marketplace. The same features: Check for Lock Vulnerabilities on any supported lockfile, automatic rescans, a report tab, the mlab tool window, the Vulnerable dependency (mlab) inspection, CVE quick documentation. The token goes in Settings | Tools | mlab.

Both read .mlab/config.json (project, then home directory) and the VS Code extension also reads .mlab/vuln.yml, the file the GitHub Action uses for ignored advisories.

In CI

GitHub Actions: mlab-sh/vuln-scan-action auto-detects lockfiles, annotates the vulnerable lines in the pull request, writes a job summary and fails on a severity threshold.

- uses: mlab-sh/vuln-scan-action@v1
  with:
    fail-on: high
    token: ${{ secrets.VULN_MLAB_TOKEN }}

Details: GitHub Action. Any other CI can run the CLI below, or call the API directly.

In your terminal

The mlab CLI:

brew tap mlab-sh/mlab-cli https://github.com/mlab-sh/mlab-cli
brew install mlab

(.deb, .rpm and tarballs are on the releases.)

mlab sbom scan package-lock.json
mlab sbom scan Cargo.lock web/package-lock.json --fail-on high
mlab sbom scan --url https://raw.githubusercontent.com/o/r/main/go.sum
cat requirements.txt | mlab sbom scan - --format pip

--fail-on exits 7 when a finding reaches that severity, and refuses to pass a scan that did not look at everything (a cut manifest, packages the scanner could not check, an outage). --json and -o csv keep the gate. Pass the token with MLAB_VULN_TOKEN or vuln_token in ~/.mlab/conf.yml. See the CLI wiki.

On every commit

The CLI ships a pre-commit hook that scans the lockfiles a commit touches and blocks it on a high or critical finding:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/mlab-sh/mlab-cli
    rev: v1.2.0
    hooks:
      - id: mlab-sbom-scan          # builds mlab from source, once
      # - id: mlab-sbom-scan-system # or uses the mlab already installed

It runs on the pinned lockfiles of every ecosystem the server reads, and on CycloneDX and SPDX SBOMs. requirements*.txt and pom.xml are opt-in with a files: override, since they often hold versions the scan cannot resolve. See the pre-commit wiki.

In your AI assistant

The mlab MCP server exposes the scan as the scan_sbom tool: paste a lockfile or SBOM in a conversation and get one finding per package and CVE, worst first, with its severity, the version that fixes it, and what the scan could not cover.

For Claude Code, the mlab plugin adds /mlab:sbom-audit: it scans a lockfile, ranks findings by known exploitation and EPSS, and attributes actively exploited CVEs to threat actors.

/plugin install mlab@mlab-sh

Your own integration

Use the API: /api/v2/scan for a whole manifest, /api/v2/query for one package. Respect Retry-After on a 429, read truncation and results[i].ok before calling anything clean, and show the server's message when it refuses a scan: it says what to do.