CDX Command Reference

The cdx command generates one local CycloneDX JSON document without VDB lookup, uploads, memory updates, quality gates, image pulls, or a Docker/Podman daemon.

vulnetix sbom is an alias for vulnetix cdx, not the other way round. CycloneDX is the format this tool produces natively everywhere else — the SBOM in .vulnetix/sbom.cdx.json, VEX attestations, the AIBOM and the CBOM — so “sbom” resolves to CycloneDX by preference. An SPDX generator will land as its own command (vulnetix spdx) rather than changing what sbom means.

It combines:

• Package manifests and lock files
• Installed package directories such as node_modules, Python virtualenvs, Go module cache, Composer vendor trees, Ruby gems and NuGet packages
• Dockerfile/containerfile package installs and container image references
• CI/CD pipeline install commands (see CI/CD coverage)
• Shell-script, Makefile and task-recipe package installs
• Container root filesystem package databases such as dpkg, apk and pacman
• Packages compiled into binaries: Go build info, Rust cargo auditable data and JVM archive coordinates (see Binary package discovery)
• AIBOM and CBOM components in the same CycloneDX file
• Checksums, local signature sidecars and offline transparency-log metadata where present

Usage

vulnetix cdx [path] [flags]

Flags

Examples

# Generate .vulnetix/sbom.cdx.json
vulnetix cdx

# Print CycloneDX JSON to stdout and still write the file
vulnetix cdx -o cyclonedx-json

# Inspect an unpacked container filesystem
vulnetix cdx --container-rootfs ./rootfs

# Inspect a saved image tar without using Docker
vulnetix cdx --container-archive ./image.tar --output-file build/image.cdx.json

# Package SBOM only
vulnetix cdx --no-aibom --no-cbom

# Manifests and installed packages only — no inference from pipelines or scripts
vulnetix cdx --no-ci --no-shell --no-containerfiles

Recorded Metadata

Every component carries the same metadata vulnetix sca records, so an offline SBOM and a scanned one describe packages identically:

source-type values are manifest (declared in a manifest or lockfile), installed (found in an installed package tree), container-db (an OS package database inside a container root filesystem), command (inferred from a package manager install command in a Dockerfile, CI file or script) and binary (recovered from a compiled artefact).

Evidence confidence reflects how the package was found: high for a declared or installed package and for build-tool-recorded binary metadata, medium for a pinned install command or archive manifest attributes, low for an unpinned install command or a version read off a filename. A command-derived component is an inference — the command may be conditional or never executed — and is graded accordingly.

Existing findings are preserved

The default output path is the same file scan and sca use as scan memory. When that file already carries vulnerabilities (including VEX analysis), cdx carries those entries — and any component they reference but this run did not rediscover, marked vulnetix:sbom/carried-over — into the document it writes. An inventory run never deletes finding history.

CI/CD Coverage

Pipeline-as-code files are parsed for package-manager install commands, and GitHub-Actions-family workflows additionally contribute their uses: pins as github-actions packages.

Multi-document YAML streams are parsed in full, so a Tekton Task or an Argo Workflow that is not the first document in the file is still read. Per-vendor command keys are recognised — run, script, commands, cmds, steps, entrypoint, content, args, before_install, build_script, runcmd, installCommand, postCreateCommand and others — because a missed key silently drops every package the pipeline installs.

A line-oriented shell pass also runs over every pipeline file, not only as a fallback. Kotlin (TeamCity, JetBrains Space), Groovy (Jenkins shared libraries) and TOML (netlify.toml) files happen to parse as YAML scalars without error, so a “did it parse as YAML” test would silently skip them; the extra pass also catches commands sitting under a key no vendor list knows about.

A compose file or Kubernetes manifest that happens to live in a CI directory keeps its own, more specific classification.

Shell And Recipe Coverage

Line continuations are joined before parsing, so a multi-line apt-get install \ block is read as one command. Linux distro managers (apk, apt, dpkg, yum/dnf/zypper, rpm, pacman), language managers (npm/yarn/pnpm/bun, pip/uv/ poetry/pipenv, gem, composer, cargo, go, nuget/dotnet, mvn/gradle, conda) and the Windows managers used in CI (choco, scoop, winget) are all recognised.

Binary Package Discovery

Compiled artefacts are read for the package metadata their build tool embedded. Nothing is executed, and no bytes beyond those metadata sections are interpreted.

In a container root filesystem the file lists of the package databases (dpkg, apk, pacman) are read as well, so each binary is attributed to the package that installed it:

• the owning package component becomes the parent of the file component in the dependency graph
• the file component records vulnetix:binary/owner-package and vulnetix:binary/owner-ecosystem
• a binary that no package claims is flagged vulnetix:binary/unpackaged — a file that arrived outside the package manager

RPM databases are Berkeley DB or SQLite files that cannot be read without a native library, so rpm-based images get package components from the package-database pass but no per-file attribution; binaries in those images are not flagged unpackaged.

The same discovery runs during vulnetix containers, which prints what it found and merges the packages into .vulnetix/sbom.cdx.json; disable it there with --no-binary-package-analysis.

Signature And Transparency Log Metadata

cdx looks for local signature and attestation sidecars next to discovered manifest, package, and binary files: .sig, .asc, .minisig, .sigstore, .bundle, .bundle.json, .intoto.jsonl, .att, .attestation and .attestation.json.

When a Sigstore-style bundle carries Rekor transparency-log entries, cdx adds the offline inclusion metadata to the component as CycloneDX properties under vulnetix:tlog/*. It does not perform live Rekor lookups.