Software inventory and SBOM export

The collector can list the software inside the applications running on a Linux host, in containers and Kubernetes pods as well as host services, and record which of those components each process actually loads. Tracix matches that inventory against OSV vulnerability advisories. This page shows how to turn both on, read the inventory and its matches, and export it as an SBOM with VEX statements your team writes.

What the collector reads

The Software Inventory integration reads local metadata through each application's own file system and never runs what it inspects. There is no external scanner, and nothing is downloaded or pulled.

Version strings found in binaries are marked low confidence. Anything the collector can't read or identify is reported as a coverage gap, never as "no components".

Turn on software inventory

1. 1

   Add the integration

   Add the Software Inventory integration to the policy of the collectors on your Linux hosts. Adding integrations needs permission to manage them, which admins have by default; see Manage collectors with policies. Collectors on macOS and Windows in the same policy skip it and run the rest of the policy.

2. 2

   Give the collector the access it needs

   To read every process and its files, the collector needs extra privileges. When the policy includes Software Inventory, the install command the console shows adds them:

   • Linux: --enable-software-inventory, which grants the collector service CAP_SYS_PTRACE, CAP_DAC_READ_SEARCH, CAP_BPF, CAP_PERFMON and CAP_SYS_RESOURCE. The service keeps running as its own user.
   • Kubernetes: softwareInventory.enabled=true, which runs the collector as root with those capabilities, never as a privileged pod, in the host PID namespace.
   • Docker: a container in the host's PID namespace with the same capabilities and the host's root mounted read-only.

   A collector installed before you added the integration doesn't have this access. Until you reinstall it with these settings, it polls /proc and reports what it can't read.

3. 3

   Link processes to services

   The inventory shows up per APM service. A process belongs to a service when it declares OTEL_SERVICE_NAME or service.name in OTEL_RESOURCE_ATTRIBUTES, when its pod's Kubernetes metadata names one, or when you map it in the integration's Service mappings field, one mapping per line, such as k8s_namespace=shop k8s_workload=checkout service_name=checkout. A process with none of these stays unattributed; Tracix never names a service after an executable.

Two Linux installer flags are separate opt-ins: --enable-software-docker lets the collector read Docker's API for container image IDs, which is root-equivalent access, and --enable-software-probes-sysadmin adds CAP_SYS_ADMIN for execution probes on kernels that refuse them otherwise. Without the extra privileges, the integration falls back to polling /proc and reports the applications it can't read as permission denied.

Turn on vulnerability matching

Matching needs advisories. Connect the Vulnerability Enrichment integration under Collectors › Integrations (see Connect an integration). It reads public feeds and needs no credentials.

1. Keep OSV vulnerability advisories on.
2. Under Ecosystems, keep the ones your applications use: Go, npm, PyPI, Maven, NuGet, crates.io, RubyGems, Packagist, Debian, Ubuntu, Alpine, Red Hat, Rocky Linux, AlmaLinux, SUSE and openSUSE are on by default. Chainguard (about 1 GB) and Wolfi are off unless you run them.
3. Keep CISA Known Exploited Vulnerabilities and FIRST EPSS on to see exploitation data beside each CVE.

The first load downloads each ecosystem's full set of advisories, which takes minutes for the large ones. After that the integration checks for changes every hour and reloads everything once a week. Tracix matches the inventory against the advisories every 15 minutes for what changed, and every release again once a day.

Each release is looked up the way its source publishes advisories: distribution packages under their distribution release, by source package where the distribution keys advisories that way, and language packages by name. Versions are compared with each ecosystem's own rules. Fedora, Amazon Linux, Oracle Linux, CentOS and Arch have no OSV data, so their packages can't be matched.

Read the inventory

Open the service under Applications › APM & Traces and select its Components tab. It has five sections:

• Inventory: the components of the current builds of the service, each with its version, ecosystem, how it was identified and its vulnerability matches.
• Vulnerabilities: the advisories that match those components.
• Evidence: runtime observations of those components in the page's time range.
• VEX assessments: the statements your team has written about vulnerabilities in these builds.
• Capture coverage: what the collector couldn't see, such as restarts, dropped events or missing permissions.

For containers, the collector marks each component as application or base image. The application is the packages behind the executables and libraries the container's processes use, what those files contain, and the language packages on the application's own module path. The base image is everything else, which never means unused or safe. The Inventory and Vulnerabilities sections list the application by default, and their counts follow; select Show base image to add the rest. An image the collector hasn't classified yet is listed in full, with a note.

Each component carries evidence labels:

Inventory and runtime evidence are kept for 90 days by default.

Review vulnerability matches

A match says that an advisory names a component's package and version. In the Inventory section, the Vulnerabilities column shows each release's highest open severity, its number of open matches, KEV, EPSS and the fixed version, or why it wasn't assessed:

The Vulnerabilities section lists one row per advisory, with its Severity, Exploitation (KEV and EPSS), Affected components, Instances, Runtime evidence, Fixed in and VEX status. Filter it by severity, exploitation, fix, VEX status, runtime evidence, match, advisory source or ecosystem, or search by ID, CVE, component or fix.

• Severity comes from the advisory's CVSS score, else the highest CVSS score of its CVEs, else the source's own rating. Without any of them it is Unknown, never low.
• Exploitation shows whether a CVE is on the CISA Known Exploited Vulnerabilities catalog and its FIRST EPSS score. No KEV or EPSS record doesn't mean the CVE isn't exploited.
• An advisory whose version check can't be decided reads Undetermined. It is never counted as affected or as safe.

Select an advisory to open its details: the affected releases with their ranges and instances, Introduced via (the dependency chains that pulled each release into the build), the runtime evidence and the VEX statements for each build. The runtime evidence follows the page's time range in four steps: Present, Mapped, loaded or opened, Executed, and Vulnerable function, which reads Not checked because Tracix doesn't check vulnerable functions yet. Evidence can raise a match; nothing observed never lowers one. The matches themselves follow the current inventory, whatever the time range.

In Security findings

Matches also appear under Security › Findings, as one finding per CVE, or per advisory ID when the advisory names no CVE, for each service that runs an affected release. Tracix refreshes them every 15 minutes, applies your VEX assessments when you read the page, and shows the runtime evidence for the selected time range, which defaults to the last 15 minutes. A coverage line says what was and wasn't assessed, so an empty list never hides releases that weren't assessed. As on the Components tab, findings only in the base image wait behind Show base image.

Reading the matches on the Components tab needs the security.read permission.

Export an SBOM

Select Export on the Components tab and choose what to export:

Then choose the product builds to include, up to 50, and the scope: the Full snapshot, or a Filtered subset that matches the inventory's current filters and is labeled partial. Tick Include evidence bundle (ZIP) to add the runtime evidence. Every document is validated against the format's pinned schema before it downloads, and several documents download together as a ZIP with a manifest. Exports always cover the whole image, base image included, and each component keeps its layer.

SBOM + VEX lists the matched advisories beside the statements your team wrote, without an analysis of their own: a match is not a VEX statement. CycloneDX lists each one with the components it affects, its ratings, and KEV and EPSS as recorded; SPDX 3.0.1 links each component to its vulnerabilities; SPDX 2.3 adds advisory references. The OpenVEX companion carries only your statements. A build with matches but no assessment still exports, and the dialog says its matches are listed without analysis.

A VEX only export needs at least one published assessment, and SBOM + VEX needs an assessment or a match. Otherwise the dialog says No VEX assessments available before anything downloads; Tracix never produces an empty VEX document, because it would read as a clean result.

Write VEX assessments

A VEX assessment is a statement a person writes about one vulnerability in one exact product build. Runtime evidence can support it; it never decides it.

In the VEX assessments section, select New assessment, or select Assess on an advisory's details. Pick the Vulnerability ID from the advisories that match the build, or type any other ID. Choose the Product build and optionally the Assessed component, then pick a status:

An assessment speaks about a match when it names the same build and any ID the advisory is known by. An advisory that names several CVEs, such as a Debian security advisory or an Ubuntu security notice, is assessed per CVE: a statement on one CVE covers that CVE only, a statement on the advisory's own ID covers all of them, and the match closes when every CVE is closed. The VEX column shows progress, such as 1 of 2 CVEs assessed. Assessments of the same ID and configuration scope that disagree are flagged as conflicting, and exports refuse them until one is revised or withdrawn.

You can attach supporting facts from the build's inventory and from positive runtime observations; missing samples or probe hits are never offered as evidence. Tracix records the author from your session. To change a published assessment, select Revise, which keeps the earlier revision, or Withdraw. Assessments never carry over from one build to another. Writing assessments needs the security.manage permission, which admins have by default; exporting VEX needs security.read.

Next steps