Software composition analysis

vulnetix sca reads the package manifests and lockfiles in a directory, resolves every dependency to an exact version, and asks the Vulnetix VDB which known vulnerabilities, exploits, malware reports and end-of-life dates apply. It prints the findings, writes a CycloneDX SBOM, and exits non-zero when a gate you set is breached.

It is vulnetix scan with every other scanner switched off:

vulnetix scan --evaluate-sca --no-licenses --no-sast --no-containers --no-secrets --no-iac

The commands

Command	What it does	Page
vulnetix sca	Dependency vulnerabilities, malware, EOL, freshness, reachability	Ecosystems, Gates
vulnetix fix (alias autofix)	Moves vulnerable dependencies to a Safe Harbour version with your package manager, then rescans	vulnetix fix
vulnetix sca --sca-autofix	The same fix workflow inside an SCA or full scan	vulnetix fix
vulnetix containers	Dockerfile, Compose, Kubernetes and Helm rules, plus an ELF binary pass and rootfs or archive inspection	Containers
vulnetix image <ref>	Inventories one built image layer by layer for Container curation	Images
vulnetix license	Licence resolution, conflicts, allow lists, policy and exceptions	Licences
vulnetix vdb vuln <id>	Looks up one vulnerability, with tree-sitter reachability against your tree	Reachability

What runs where

Step	Where
Finding manifests, parsing them, resolving ranges from lockfiles or installed packages	Your machine
Vulnerability, exploit, malware, EOL and Safe Harbour lookups	VDB API, POST /v2/cli.sca, in batches of packages (purls)
Reachability: running the tree-sitter queries the VDB returns	Your machine
Licence detection	Your machine first, then the API, package registries, deps.dev and GitHub for anything still unknown
Gate evaluation and the exit code	Your machine, after the org quality gate is applied
Recording the scan as a snapshot in the console	VDB API, only when you are signed in to an organisation

Credentials are optional. With none configured the CLI uses the shared community credentials: lookups work, but nothing is persisted and no org quality gate applies. Sign in with vulnetix auth login (see Authentication) to record scans and apply your organisation’s policy.

Files a scan writes

Path	Written by	Content
.vulnetix/sbom.cdx.json	sca, scan, fix, license, containers	CycloneDX SBOM with components, vulnerabilities, licence findings and VEX
.vulnetix/memory.yaml	every scan unless --disable-memory	Finding state, triage decisions, reachability evidence
.vulnetix/containers.sarif	containers	SARIF 2.1.0 for container rules
.vulnetix/vex-autofix.json	fix, --sca-autofix	OpenVEX for findings a fix resolved
.vulnetix/vex-risk-accepted.json	fix, --sca-autofix	OpenVEX for findings with no safe version

Paths are relative to the git root of --path when it is a repository.

Where to go next

• Quickstart: a first scan, a CI gate, a fix.
• Supported ecosystems: every manifest and lockfile.
• Gates and exit codes: how --fail-on and the org quality gate decide the exit code.
• Resolve Platform findings: what an uploaded scan becomes in Resolve.

GitHub Actions

Run it in a workflow with the sca, containers and license GitHub Actions. They publish sca.sarif and license.sarif to code scanning, upload the files as an artifact and attest them.

Platform IaC

SCA has no config kind of its own. Its thresholds come from the organisation’s quality gate, the QualityGate kind. The licence files that vulnetix license reads are the LicensePolicy and LicenseExceptions kinds; the server stores neither, so they stay in the repository. Findings you have decided do not matter are Suppression documents or a VexSource. See the kind catalogue.

When Drift protection is on, a change made in the console or through a legacy API to the quality gate is refused with HTTP 409 managed_by_platform_iac if the quality gate is managed as code (by Terraform or a repository). Change it where it is declared, or ask an admin to turn Drift protection off.