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 .

By default every matching CVE is reported at full advisory severity, in whatever order the advisories arrive. To rank them by whether your code can actually reach the vulnerable code — and to see the call path when it can — see Reachability.

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.

Reading an empty result

"No dependency findings" is not automatically "your dependencies are fine". It can also mean the pass never ran, or that the advisory service returned nothing for the packages it was asked about. So every dependency scan reports what it asked and what came back:

dependency scan: 20 packages submitted, 6 correlated to 9 advisories [maven 9/9, npm 4/11]

The same counts are machine-readable under run.dependencies in a --json report, including a per-ecosystem breakdown. The ecosystem rows are the ones to read when a result looks short: maven 0/9 means nine maven packages were submitted and no advisory came back for any of them — worth checking advisory coverage for that ecosystem in your space before concluding the packages are clean.

A package with no package URL is counted separately as not correlatable. Matching is package-URL-based — xgrep will not guess a match from a name — so those packages can never match, whatever the advisory data contains.

When the pass does not run, the report says so instead of reporting a clean result: a missing service account, an unreadable SBOM or a failed request each produce their own message, never "No known vulnerabilities found".

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.

Fixing what you found

xgrep fix upgrades the vulnerable packages — direct and transitive — through the package manager your project already uses, and confirms the vulnerability is gone afterwards rather than trusting the command's exit code. See Fixing dependencies.

xgrep scan .               # find
xgrep fix verify           # see the upgrade plan, offline
xgrep fix apply --online   # do it

What this replaces

The dependency tooling now answers all four questions:

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