SBOM & vulnerabilities

A software bill of materials (SBOM) lists the components inside an artifact. The CRA expects you to keep one; Meshanics lets you attach it per artifact and then uses it to answer the question that actually matters when a new CVE lands - which of my artifacts, and therefore which of my devices, contain the affected component?

Attaching an SBOM

Each artifact can carry its own SBOM in either of the two common formats, CycloneDX or SPDX JSON. The platform detects the format from the document itself, so you upload the file your build already produces - no conversion step. You can attach one when you publish an artifact, or add or replace it later in the artifact's lifecycle.

Produce it at build time (recommended)

The best SBOM is the one your build already knows about: it sees the exact layers and dependencies that went in, it needs no extra transfer of your image, and it is precisely what shipped. Two common ways for a container image:

• Build attestation. With BuildKit, attach an SBOM as the image is built so it travels with the image:

  docker buildx build --sbom=true -t your/image:tag --push .
  

• Generate then upload. With a tool such as Syft:

  syft your/image:tag -o cyclonedx-json > sbom.json
  

  then attach sbom.json to the artifact when you publish it.

Generated for you (containers)

If a container artifact is published without an SBOM, Meshanics generates one so your coverage never depends on remembering to attach it. To do so the control plane pulls the image, scans it, and removes it afterwards - nothing about your image is retained. A generated SBOM is labelled as generated, and a customer-attached SBOM always takes precedence and is never overwritten.

Models, configs and firmware are not scanned this way - a model is signed weights with no real dependency surface, so attach the SBOM to the runtime container that loads it, which is what the vulnerability watch tracks.

Coverage

Coverage is tracked as a ratio: the fraction of published artifacts that carry an SBOM, attached or generated. A later attach or a generated SBOM flips an artifact from uncovered to covered, and the audit log stays the source of truth for when it happened. Zero coverage reads as a gap rather than a false all-clear.

The platform reads the component list out of the SBOM, but it never inspects the payload itself - metadata only.

The vulnerability watch

A background scan runs across the SBOMs you have attached. It extracts each component and queries a public vulnerability database for known issues, then records a finding for every match. The scan runs on an interval and can also be triggered on demand. It is read-only with respect to your fleet: it changes nothing on devices, it only reports.

Each finding records the affected artifact and version, the component and its version, the ecosystem, the vulnerability identifier, a summary, and a severity.

Severity bands

Raw scores are normalised into one of five bands so you can rank and filter consistently. Numeric base scores and CVSS vectors are mapped using the standard qualitative ranges:

unknown is a first-class band - anything that cannot be confidently rated is shown as unknown rather than hidden or guessed.

Triaging findings

A new finding is a draft. It starts no regulatory clock on its own - that is deliberate. From the console you can:

• Filter the list by artifact, version, severity, status, ecosystem or a free-text search.
• Read a posture summary: open / dismissed / promoted totals, an open-by-severity histogram, and a worst-first breakdown per artifact.
• Dismiss a finding that does not apply, or promote one that does.

Promoting a finding is how a vulnerability becomes a deadline-tracked incident. That hand-off is covered next. Every status change is written to the audit log, so the triage history itself is evidence.

Related

• Incident reporting
• Evidence & reports
• CRA overview & timeline
• How it works