Scanning dependencies for vulnerabilities

xgrep scan finds both code issues (SAST) and known vulnerabilities in your dependencies, in a single run. When a scan discovers dependency manifests or lockfiles (go.mod, package-lock.json, …), xgrep builds an SBOM for them, matches it against known CVEs via Mondoo Platform, and renders the matching vulnerabilities inline as normal findings, right alongside the code findings:

xgrep scan .

Dependency findings flow through every output format (text, JSON, SARIF, GitLab), count toward the exit code like code findings, and are tagged dependency-vuln so you can tell them apart from SAST results. Each finding names the affected package and version, the CVE, a summary, references, and a remediation hint, and is located back to the lockfile/manifest the package came from.

Credentials

Unlike SBOM generation and dependency queries — which are fully offline — matching packages against the vulnerability database is the one networked step in the dependency tooling. It needs a Mondoo service account, resolved the same way as platform reporting — via xgrep login, --mondoo-config, MONDOO_CONFIG_PATH / MONDOO_CONFIG_BASE64, or ~/.config/mondoo/mondoo.yml.

The scan itself is ephemeral: packages are matched against the database scoped to your space, and nothing is stored on the platform by the scan. The resulting vulnerabilities are published only when reporting is enabled — automatic on the default branch when a service account is configured, unless --incognito.

It is best-effort, exactly like the rest of a scan:

• No credentials → xgrep logs a one-line warning only when there were dependencies to scan and continues; your code findings are unaffected. A credential-less, code-only repo stays quiet.

  found 42 dependencies but skipped vulnerability scanning — no Mondoo service
  account (set --mondoo-config or MONDOO_CONFIG_PATH; --no-dep-scan to silence)

• Scan error → logged as a warning; the code scan still completes and reports.

Opting out (--no-dep-scan)

To run the SAST code scan only — no dependency scan, no Mondoo call — pass --no-dep-scan:

xgrep scan --no-dep-scan .

This is the flag to use in fully-offline or credential-less environments where you don't want the "no service account" warning. xgrep ci inherits both the dependency scan and --no-dep-scan.

Scanning an existing SBOM (--sbom)

If you already have an SBOM — produced by xgrep sbom, another tool, or a build pipeline — scan it for vulnerabilities directly, with no code walk:

xgrep scan --sbom sbom.cdx.json

xgrep auto-detects the format (CycloneDX, SPDX, or Mondoo JSON) and renders the matching vulnerabilities in the selected output format (text, --json, --sarif, or --gitlab). --sbom cannot be combined with target paths — it scans the SBOM, not a tree. This is useful for scanning an SBOM built in an earlier CI stage, or one for an artifact you don't have the source tree for.

Publishing to Mondoo Platform

When reporting is enabled — automatic on the repository's default branch whenever a service account is configured — the dependency vulnerabilities are published to the platform alongside your code findings. They are uploaded as VEX (Vulnerability Exchange) documents, re-homed onto the same repository asset as the code findings, so a repo's SAST and SCA results land together:

xgrep scan .              # reports automatically when logged in (default branch only)
xgrep scan --incognito .  # render CVEs locally; upload nothing

Reporting is additive — local output is unchanged, and an upload failure never fails the scan. Pass --incognito for a local-only run; the vulnerability scan still runs and renders CVEs, only the upload is suppressed.

What this replaces

The dependency tooling now answers all three questions:

• What's in here? → xgrep sbom
• What does our code use? → xgrep deps
• Which dependencies are vulnerable? → xgrep scan (this page)