Skip to content
Start free

See which components your services actually run

The collector inventories the software inside running Linux applications, containers and pods, and records which components each process mapped, opened or executed. Tracix matches every release against OSV advisories, and exports any service as CycloneDX or SPDX, with VEX statements your team writes.

Start freeBook a demoRead the inventory docs
  • CycloneDX · SPDX · OpenVEX
  • Matched against OSV advisories
  • Runtime evidence per component

How it works

Six steps from a running process to an SBOM

Inventory, matches, evidence and assessments stay tied to the exact build they describe, so an export says what that build contains and nothing more.

  1. 01EnableTurn on the software inventory profile when you install the collector on Linux hosts, Kubernetes or Docker.
  2. 02IdentifyThe collector finds applications in containers, pods and host services, and reads their package databases and language metadata without running anything.
  3. 03ObserveeBPF records the libraries each process maps and the code files it opens. Sampled CPU profiles show what ran.
  4. 04MatchTracix checks every release against OSV advisories, with KEV and EPSS beside each CVE and the fixed version when one is published.
  5. 05AssessYour team writes VEX statements for an exact build, picking from its matched advisories and citing the evidence behind them.
  6. 06ExportDownload CycloneDX, SPDX or OpenVEX, each checked against its pinned schema before it leaves.

Runtime evidence

Installed is not the same as running

For every component, Tracix records whether a process mapped it, opened it or ran it. Each kind of evidence stays separate, with the process, instance and build it came from, so nothing is overstated.

  • eBPF sees a process map a native library or open a code file, such as a JAR, a Python module or a JavaScript file
  • With continuous profiling on, sampled CPU stacks show which packages actually ran
  • Vulnerability matches carry the same evidence: a package that ran stands out, and one never seen running is not marked safe
  • Versions the metadata cannot show are marked unknown, never guessed

SBOM and VEX export

SBOMs that hold up when someone checks them

Export one build or up to 50 at once, as CycloneDX, SPDX or OpenVEX. Every document is validated against its pinned schema and cross-checked before you can download it.

  • Pinned versions

    CycloneDX 1.7, SPDX 2.3 and 3.0.1, OpenVEX 0.2.0. No other version is substituted.

  • Validated first

    A file that fails its schema or cross-checks is refused, not downloaded.

  • Matches beside your VEX

    SBOM with VEX lists the matched advisories, without analysis. Statements come only from assessments people publish.

  • Never an empty VEX

    A build with no assessment and no match says so, instead of exporting a file that reads as clean.

Coverage

Gaps are reported, never hidden

The collector says what it could not see: a reader with nothing to read, a probe that failed to attach, a restart. Missing evidence is never shown as a clean result.

  • Every reader reports its own result, such as not present, partial or permission denied
  • Restarts, dropped events and polling-only operation appear as gaps in the window they affect
  • A release with no advisory source or no package URL reads not assessed, never no matches
  • A snapshot is published only when every row it declares has arrived

Better together

The inventory lives next to the service it describes

Components appear on each service beside its traces and profiles, and come from the collector that already runs on your hosts.

Export formats

Every format pinned to one version

Pick what to export and in which format. Tracix never swaps in another version, and refuses a combination a format cannot carry.

FormatEncodingSBOMVEXSBOM with VEX
CycloneDX 1.7JSONYesYesOne document per build, VEX embedded
SPDX 2.3JSONYesNot in this formatSPDX file plus an OpenVEX companion
SPDX 3.0.1JSON-LDYesYes, Security profileOne graph with native VEX
OpenVEX 0.2.0JSON-LDNoYesThe companion to SPDX 2.3
Tracix inventory v1JSONInventory onlyNoNo

Tracix inventory JSON carries provenance, relationships and coverage. Several builds download as one ZIP with a manifest, and the runtime evidence for the window can be added as its own file. SBOM with VEX lists matched advisories in CycloneDX and both SPDX versions; the OpenVEX companion carries only your statements. A VEX-only export needs at least one published assessment.

FAQ

Questions security teams ask first

Talk to a security engineer
Does Tracix tell me which components have known vulnerabilities?
Yes. Add the Vulnerability Enrichment integration and Tracix matches every release in the inventory against OSV advisories. Matches appear on the service's Components tab and in Security findings, with severity, KEV, EPSS, the fixed version and runtime evidence. A match is not a VEX statement: only an assessment your team writes closes one.
Which packages are matched?
OS packages from Debian, Ubuntu, Alpine, Red Hat, Rocky Linux, AlmaLinux, SUSE and openSUSE, and from Chainguard and Wolfi when you turn them on, plus Go, npm, PyPI, Maven, NuGet, crates.io, RubyGems and Packagist packages. Fedora, Amazon Linux, Oracle Linux, CentOS and Arch have no OSV data, so their packages read not assessed. An advisory that needs a version Tracix can't compare reads undetermined, never affected and never safe.
Why does the Components tab hide the base image?
For containers, the collector marks each component as application or base image. The application is the packages behind the executables and libraries its processes use, what those contain, and the language packages on its own module path; the base image is everything else, which never means unused or safe. The tab lists the application by default, and Show base image adds the rest. Exports always include the whole image, and an image the collector has not classified yet is listed in full.
Which platforms does it support?
On Linux: hosts installed with the software inventory option, Kubernetes through the Helm chart, and Docker through the compose profile. The collector needs the host PID namespace and read access to other processes. Without eBPF it falls back to polling and reports that coverage. Windows and macOS collectors do not receive it.
Does not observed mean a component is unused?
No. It means no execution was seen in the selected window. Capture gaps, such as a collector restart or a probe that failed to attach, are listed beside the results, and absence never means unused or safe.
Does the collector pull images or run a scanner?
No. It reads metadata that is already on the host, through each application's own root. It never executes what it inspects and pulls no images. Matching runs in Tracix against the inventory, so no image or registry is scanned.

See what your services really run

Install the collector with the software inventory profile, then open any service's Components tab.

Start freeRead the guide