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.

Authoring identity

The document names its producer as vulnetix-cdx, at the version that ran, and records the organization running the scan as metadata.manufacturer — omitted rather than guessed when nothing resolves it.

Because cdx reads several kinds of source in one pass, it usually claims several lifecycle phases at once: pre-build for the manifests, build for an installed tree, post-build for a container rootfs or compiled artefacts, and discovery for the AIBOM and CBOM passes. Skipping a pass drops its phase, so --no-aibom --no-cbom removes discovery. Override the whole set with --lifecycle. The rules are the same for every command that writes a document and are described once under BOM authoring identity.

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.

Signing the document itself

--sign signs the document cdx just produced, using the machine’s own ambient OIDC identity — a workflow reference in CI, a SPIFFE ID for a workload. Deliberately not a Vulnetix credential: a scan run in your pipeline is more usefully attested by you than by the tool vendor, and the result verifies with stock cosign verify-blob against no Vulnetix trust root.

vulnetix cdx --sign

Writes three sidecars beside the document — .sig, .pem and .intoto.jsonl — plus an embedded JSF signature. On a laptop there is no ambient identity, and that is not an error: signing is skipped with a reason and the scan completes, because losing scan results over a missing signature would be the worse outcome.

Verify with attest verify:

vulnetix attest verify .vulnetix/sbom.cdx.json

Reading documents back

cdx writes. bom reads — CycloneDX 1.0–1.7, SPDX 2.2/2.3, and in-toto attestation envelopes, whether this CLI produced them or not.

vulnetix bom diff before.cdx.json after.cdx.json   # what changed
vulnetix bom tree sbom.cdx.json --invert           # what pulls this in
vulnetix bom skew --from ./sboms/                  # inconsistent versions