Track Vulnerabilities

Find the known vulnerabilities in the software your devices run, decide which ones to fix first, and record why others do not apply. Nexigon reads the SBOMs you publish with each version, matches their components against public vulnerability data and your own advisories, and relates the results to the devices running each version.

Components and Coverage

A software bill of materials (SBOM) lists the components of a build, such as the Debian packages of a system image. When a version links an SBOM, as Before You Start describes, Nexigon indexes its components. It supports CycloneDX JSON, SPDX 2.2 and 2.3 JSON, and SPDX 3 JSON-LD.

Nexigon identifies components by their package URL (purl), for example pkg:deb/debian/libssl3@3.0.15-1~deb12u1?upstream=openssl&distro=debian-12. Vulnerability databases name packages per ecosystem, using the ecosystem names of OSV. Nexigon maps purls to ecosystems as follows:

Debian, Ubuntu, and Alpine advisories name source packages for a distribution release, while SBOMs list binary packages. SBOM generators such as Syft record the source package in the purl’s upstream qualifier and the release in distro. Nexigon therefore checks the example above as the source package openssl in Debian:12.

Each component of a version has a coverage:

A component is unchecked when it has no purl of a type in the table, a version the ecosystem’s versioning cannot order, or, for Debian, Ubuntu, and Alpine packages, no distro qualifier with a release, such as debian-12. Some generators, such as Syft, also list every file of an image. Files without a purl are not components and are left out. Nexigon does not match CPE identifiers.

Yocto SPDX documents give each installed package the purl of the recipe that builds it, such as pkg:yocto/core/busybox@1.37.0 for busybox-syslog. Nexigon lists the packages of a recipe as one component named after the recipe. No public database covers Yocto recipes. Import the report of sbom-cve-check for each build instead, as Import VEX Documents describes. Until you do, the version’s SBOM shows a warning. The report states nothing about recipes without known vulnerabilities, so they remain unchecked.

Findings and Vulnerabilities

An advisory is a published record stating that a vulnerability affects certain versions of a package. Public advisories come from the OSV database. Advisories that share an identifier, such as a Debian advisory and its CVE, describe one vulnerability. You can also publish your own advisories.

A finding is a vulnerability that affects a version, either through a component of its SBOM or because one of your advisories names the version. New advisories are matched against existing components, so findings appear for versions you published long ago without any action on your part.

A vulnerability’s severity follows from the highest CVSS v3 base score of its advisories. Without a score, Nexigon uses the severity an advisory states, or Unknown. Debian and Ubuntu rate how urgently a vulnerability needs fixing in their packages. A finding of a Debian or Ubuntu package takes the distribution’s rating instead of the CVSS score, so a vulnerability that is critical elsewhere but minor in the distribution’s build ranks low. Debian rates unimportant vulnerabilities as low and has no critical rating.

The Known Exploited Vulnerabilities (KEV) catalog of the US Cybersecurity and Infrastructure Security Agency lists vulnerabilities with evidence of active exploitation. Nexigon marks these vulnerabilities as known exploited and lists them first.

Each finding has a state that records your assessment. New findings start in triage. A finding is open while it is in triage or assessed as exploitable. Assess Findings describes the states.

Before You Start

On Nexigon Cloud, vulnerability management requires a subscription plan that includes it. On a self-hosted Nexigon Hub, organizations that do not require a subscription always have it, and an instance administrator configures the public vulnerability feeds.

Attach each version’s SBOM to the version, then name the SBOM’s filename under relations.sbom in the metadata of each attachment it describes. For example, with Nexigon CLI, use an existing version ID as $version_id and the IDs of the uploaded SBOM and bundle as $sbom_asset_id and $bundle_asset_id. Publish Software Artifacts explains how to create a version and upload its files.

nexigon-cli repositories versions assets add "$version_id" "$sbom_asset_id" gateway-os.cdx.json
nexigon-cli repositories versions assets add "$version_id" "$bundle_asset_id" gateway-os.rugixb \
  --metadata '{"relations": {"sbom": ["gateway-os.cdx.json"]}}'

The Rugix release workflow sets this metadata for you. Nexigon indexes SBOMs in the background within a minute of an upload or metadata change.

Devices must report the version they run. The system update integration reports it as currentVersionId in dev.nexigon.ota.status. It resolves the version string built into the image as a tag of the configured package, so keep that tag on every release. Only versions from repositories linked to the device’s project count. Devices without a resolvable version appear as without a known version and are not part of the report. Version retention never deletes a version that devices run, so its SBOM stays available for the report.

Review Your Fleet

Choose Security in the project navigation. The summary counts the devices with critical and with known exploited vulnerabilities, the open vulnerabilities by severity, and the devices without a known version. Those devices are not part of the report, so a report without findings says nothing about them.

The Vulnerabilities tab lists every vulnerability affecting a version that devices run. Known exploited vulnerabilities come first, then the others by severity. Each row shows how many devices the vulnerability affects and through which components. Filter by severity, state, or Known exploited only, or search for an identifier or component.

Fixed In names the earliest version created after the affected versions that has an indexed SBOM and no open finding of the vulnerability. Assessing a version as not affected also closes its finding. The column is empty when no such version exists or when the vulnerability affects several packages.

The Versions tab lists the versions devices run, with their device count and open vulnerabilities. Use it to see how far a fix has rolled out.

Select a vulnerability to see the versions and components it affects, the devices running them, and the version that fixes it. Sources names the advisories describing the vulnerability and the license under which each database publishes them.

Check a Version

The page of a version has a Vulnerabilities section with its findings and an SBOM section with the components of its SBOMs and the coverage of each. Use them to confirm that a release candidate fixes the findings of the version in the field before you roll it out.

If an SBOM cannot be indexed, Vulnerabilities names the file and the reason, such as an unsupported format. Fix the cause, then choose More options → Reindex SBOMs on the version.

Assess Findings

On a finding, choose Assess, select a state and the versions it applies to, and save. Assessing requires permission to manage the package’s versions. The package’s Assessments page lists your assessments.

How Assessments Apply

When you assess a finding, Not affected requires a justification, such as Vulnerable code not reachable. The choices are the justifications of CycloneDX VEX.

An assessment applies to all versions of the package or to one version, and optionally to one component. When several assessments apply, the one for the version wins over the one for the package, and one for a component wins over one for all components. Assessments use the vulnerability’s identifiers, so an assessment for a CVE also covers the Debian advisory with that CVE. Your assessments take precedence over statements imported from VEX documents.

Import VEX Documents

A VEX document states whether products are affected by vulnerabilities. Build tools, such as sbom-cve-check for Yocto, produce them. Nexigon imports OpenVEX, CycloneDX VEX, and SPDX 3 documents for one package. On the package’s Assessments page, under VEX Imports, choose Import VEX and select the document. Importing requires permission to manage the package’s versions and to upload assets to its repository.

Nexigon uploads the document to the package’s repository and resolves its statements in the background. You can close the panel while it does and review the import from the list later. Before anything changes, the preview shows how many statements resolve to versions, how many report findings, and the first statements with the versions they apply to. Choose Apply to apply the resolved statements or Discard to drop the import.

How Imported Statements Apply

Imported statements apply like assessments, with these additions:

• A statement that a version is affected or under investigation is a finding, also for vulnerabilities without an advisory and for components Nexigon cannot check, such as those of Yocto builds. Nexigon describes such a vulnerability with the description and CVSS score in the document.
• The reports of sbom-cve-check also cover recipes that are only needed to build an image and end up on no device. Nexigon skips statements about recipes that generate no package of the image.
• For each version, vulnerability, and component, the most recently applied statement applies. Importing the report of every build, or the same report again, never duplicates findings or assessments.
• Your assessments take precedence over imported statements. A finding shows the document its state comes from.

Deleting an import removes the statements it provides that later imports have not replaced, with the findings they report. Statements of earlier imports that it replaced do not return; import the earlier document again to restore them. The list marks imports of which no statement applies anymore.

The uploaded document remains an unused asset of the repository. Delete it on the repository’s Assets page, or enable automatic cleanup of unused assets.

For a Yocto build, import the SPDX 3 report of sbom-cve-check after you publish the version with the build’s SPDX document as its SBOM. The report references the SBOM’s document, so its statements resolve to that version.

How Statements Resolve to Versions

A statement’s product must be this package: its purl, CPE, or name must match the subject of one of the package’s SBOMs or the package’s name. Statements about other products are skipped. A statement whose product is a purl or CPE without a version applies to all versions of the package, and so does a statement without a product. A product given only by name needs a version. For a statement with a version, Nexigon tries the following in order:

1. SBOM reference: The statement references the serial number or namespace of a version’s SBOM, for example through a CycloneDX BOM-Link.
2. Product identifier: The product’s purl or CPE equals the subject of a version’s SBOM, the component the SBOM describes. CycloneDX stores it in metadata.component, and SPDX in the described package.
3. Version string: The product’s version equals a locked tag or the SBOM subject’s version of exactly one version. A leading v is ignored. A vers range, the version range syntax of the purl specification, such as vers:generic/>=2.0, is evaluated against locked tags. Ranges with more than one interval are not supported.

Floating tags and version names never resolve a statement, because they can refer to another build. Statements that resolve to no version, or ambiguously, are skipped.

The following statement resolves to the version whose SBOM describes pkg:generic/example/gateway-os@1.0:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/gateway-os-1.0",
  "author": "Example Product Security",
  "timestamp": "2026-10-20T00:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2026-24012" },
      "products": [{ "@id": "pkg:generic/example/gateway-os@1.0" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path"
    }
  ]
}

Statuses become states as follows:

Publish Your Own Advisories

Public databases do not know vulnerabilities in your own software. Publish an advisory for them in Organization Settings → Vulnerabilities. Choose New Advisory, give it an ID such as ACME-2026-001, a summary, and a severity or a CVSS v3 vector, which determines the severity. Nexigon stores CVSS v4 vectors without scoring them, so give a severity with a CVSS v4 vector. Describe what it affects:

• Component in SBOMs: An ecosystem, a package name, and the versions that introduce and fix the vulnerability. Without an introduced version, all versions before the fix are affected. For example, your Debian package acme-gateway-app in Debian:12, fixed in 2.0.0, matches components with a purl such as pkg:deb/debian/acme-gateway-app@1.4.0?distro=debian-12.
• Package versions: Versions of a Nexigon package, for software without an SBOM entry.

Findings for the advisory appear as soon as you save it. Advisories are visible only to your organization, and publishing them requires permission to manage organization settings. To add advisories you received in the OSV format, for example from a supplier, choose Import OSV.

Mark Internal Components

A public package can share the name of one of your own components, and its advisories would then cause false findings. In Organization Settings → Vulnerabilities, under Internal Components, add a purl pattern for your components. A pattern covers the purl’s type, namespace, and name, and * matches any characters. For example, pkg:deb/*/acme-* matches Debian packages starting with acme- in any distribution. Matching components are only checked against your organization’s advisories.