Monitor an SBOM

Point vuln.mlab.sh at a lockfile or SBOM URL and get an email when a new advisory affects one of your dependencies, within minutes.

A one-off scan tells you what is vulnerable today. Monitoring keeps watching: you give vuln.mlab.sh the URL of a lockfile or SBOM, and it emails you the day a new vulnerability affects one of its dependencies, ranked by known exploitation, severity and EPSS.

SBOM monitoring is part of the Pro, Team and Enterprise plans: up to 10, 50 and unlimited projects. Projects live at vuln.mlab.sh/me/sbom.

Add a project

On /me/sbom, give the project:

A name.
The URL of the file, for example the raw URL of a package-lock.json or of the CycloneDX SBOM your build publishes. Every format of the SBOM scan works, and the format is detected unless you pick one.
An auth header, for a private URL: Authorization: token ghp_..., or any Name: value. It is stored write-only and sent only to that URL's origin, never to a host a redirect points to.
A full-scan schedule: weekly or monthly.

The project is scanned right away, and alerts go to your account email.

How vuln.mlab.sh keeps watching

When	What happens
Every 10 minutes	Advisories vuln.mlab.sh has just ingested (OSV, and NVD for components known only by a CPE) are matched against your project's dependencies. A new vulnerability is emailed within minutes of being published.
Every day, 00:00 UTC	Your file is fetched again, so the dependency list follows your repository. Dependencies added since the day before are scanned at once.
Weekly or monthly	A full scan of the whole file: the one pass that also closes findings for vulnerabilities you have fixed or dependencies you have removed.
On demand	Scan now on the project runs a full scan.

Only active projects are watched; a paused project keeps its findings.

Alerts

One email per new vulnerability, per project and dependency, whichever pass finds it first. The email lists the new findings, worst first: known-exploited, then severity, then EPSS.
At most one email per project per pass.
A finding you mark acknowledged or not affected stays quiet. A fixed finding that shows up again is reopened, without a new email.

Triage

Each finding is one vulnerability (a CVE, or the advisory id when there is none) in one package version, with its severity, EPSS, known-exploited status and source. Set its status:

Status	Meaning
`open`	To handle (default)
`ack`	Known, being handled. A full scan still closes it once it is gone.
`not_affected`	Not exploitable in this project. Never closed automatically, never alerted again.
`fixed`	Set by you, or by a full scan that no longer sees it

What is not covered

A file over 4096 dependencies is scanned up to that limit, and the project status says so (ok, first 4096 of N deps scanned). A cut scan never closes findings.
Entries the parser cannot turn into a package (a git or path dependency, an unpinned requirement, a pom.xml version from a property) are not scanned.
If the file cannot be fetched or vuln.mlab.sh's database is unavailable, the project shows error: ... and nothing is closed.

A README badge

Enable the badge on a project to publish its open findings, per severity and known-exploited, without any CVE id or package name:

[![vulns](https://vuln.mlab.sh/badge/sbom/<key>.svg)](https://vuln.mlab.sh/badge/sbom/<key>)

Variant	Use
`/badge/sbom/<key>.svg`	The image. `?style=flat` (default), `flat-square`, `for-the-badge`, `mini` or `detailed` (one cell per severity); `?label=` changes the left text.
`/badge/sbom/<key>.json`	A shields.io endpoint: `https://img.shields.io/endpoint?url=https://vuln.mlab.sh/badge/sbom/<key>.json`
`/badge/sbom/<key>`	A public status page for the link.

The badge reads pending before the first scan, scan error when the last full scan failed, and stale when there has been no full scan for twice the schedule. It counts open findings only. Regenerating the key breaks every existing embed; disabling it makes them read not found. Badges are cached for 5 minutes.