SBOM, CBOM and AI-BOM: what four scanners build, and what each leaves out

Vendors ship continuously, so check the linked sources before quoting any of this.

How these verdicts were reached

• Sourced, not asserted. Every competitor cell traces to vendor documentation, a vendor issue tracker, or a written vendor answer.
• Partial beats no. Where a vendor covers part of a capability the verdict is "partial", never "no". "No" appears only where the vendor documents the absence, states it in writing, or publishes nothing on the capability, and the note says which.
• Our own column is not spared. Vulnetix is marked partial on lockfile-free resolution, vendored source, private registry authentication and container images. Snyk beats us on vendored C/C++ detection and on CycloneDX XML output.
• Capability, not price. Tier gating gets its own row rather than colouring the capability rows.

The comparison

SBOM — software bill of materials

How the inventory is built decides what is missing from it. These rows are about resolution, not export buttons.

CBOM — cryptography bill of materials

CycloneDX added crypto assets in 1.6 (ECMA-424). Post-quantum migration planning needs an inventory before it needs a plan.

AI-BOM — AI bill of materials

Models, agents, tool calls and MCP servers are dependencies now. Most SCA tools cannot see any of them.

Palo Alto Networks: Prisma Cloud — Application Security (SCA)

A cloud security platform whose SCA module produces an SBOM as one output among many. Strongest where the rest of the platform is: the cloud runtime.

Evidence. Prisma Cloud publishes less implementation detail than the other two vendors here, so we sent Palo Alto Networks a ten-question SBOM questionnaire and they answered it in writing. Every Prisma Cloud verdict below is either from that written answer or from the public SCA documentation. Their answers were candid about limitations, and the gaps listed here are largely ones they named themselves.

What Prisma Cloud does well

• Runs the real package manager. For Python, Maven, Gradle, Go, PHP, Ruby and .NET the platform invokes the ecosystem's own build tool against the cloned repository, so resolution rules like Maven nearest-wins or Go module selection are the tool's native behaviour rather than a reimplementation.
• Container image scanning inspects what is actually in the image — OS packages from the distro database and language packages really installed — so it catches things a Dockerfile RUN line installed that no manifest declares.
• Infrastructure-as-code and cloud posture coverage means an AI or crypto asset deployed into the estate is visible to the platform even though it is not in any repository-scoped bill of materials.
• Image-to-repository tracing connects a CVE found at runtime back to the repository that introduced it, which is the platform's real differentiator and something a code scanner alone cannot do.
• Automatic build-system detection with disambiguation rules when several candidate files sit in one folder, so a lockfile takes precedence over its manifest without the user configuring anything.
• Infrastructure BOM (IBOM) alongside the SBOM, which is a genuinely useful artefact for cloud estates and something none of the other tools here produce.
• Third-party ingestion for SARIF and SonarQube findings, plus a package dependency graph view, so the platform is not a closed shop even though SBOM ingestion specifically is undocumented.

Documented gaps

• No CBOM. Nothing in the Application Security documentation covers cryptographic assets, quantum posture or certificate inventory.
• No AI-BOM from code scanning. AI-SPM and Prisma AIRS discover AI assets in cloud and SaaS environments, but that is a different product line and does not produce a repository-scoped CycloneDX AI-BOM.
• Vendored and embedded components are explicitly not detected — in the vendor's words, a committed vendor/ folder, a bundled .jar or .dll, or third-party code pasted into the repository "will not be detected". Image scanning does not close the gap either, because it also reads package databases rather than arbitrary files.
• Modern JavaScript workflows are a stated weak point: Yarn v1 workspaces "produce incomplete results", and npm workspaces (v7+), Yarn Berry, pnpm, Lerna/Nx and Poetry are "not supported at all".
• Dev versus production dependency handling is, in the vendor's own framing, "inconsistent across ecosystems" — present for npm and Yarn, absent for Java, Ruby and PHP even where the package metadata supports it.
• Private registry support covers JFrog only, and only for some languages.
• No repository-level SBOM metadata customisation: application name, repository URL, branch and organisation context cannot be set from a config file in the repo.
• Source-repo scanning does not parse Dockerfiles or CI configuration for dependencies. Image scanning covers some of it, as a separate output that is not merged into the source SBOM.

Where Prisma Cloud is genuinely ahead

Live resolution is the real strength. For seven ecosystems the platform runs the actual package manager against the cloned repository, which means the dependency tree matches what the customer's own build would produce — including transitive resolution rules that are painful to emulate correctly. Vulnetix parses committed manifests and lockfiles and, for a few ecosystems, asks you to build or generate a lockfile first rather than guess at a tree. Where no lockfile exists and nobody will add one, Prisma Cloud gets an answer and Vulnetix asks a question.

The second strength is the platform around the SBOM. Image-to-repository tracing, runtime context and an infrastructure BOM are things a repository-scoped tool cannot produce, and for an organisation whose primary risk surface is the cloud estate, that context is worth more than a more complete manifest parse.

Where the inventory has holes

The gaps cluster in one place: anything that is not a recognised manifest file. Vendored source, committed binaries, Dockerfile RUN installs and CI-installed tooling are all invisible to source-repo scanning, and the vendor says so plainly. Container image scanning recovers part of that, but as a separate output with its own scope — packages installed through a package manager during the image build — and it is not merged into the source SBOM. So the answer to "is this component in my SBOM" depends on which of two SBOMs you are looking at.

Vulnetix takes the opposite approach on both counts: Dockerfile and Containerfile parsing happens in the same pass as manifest parsing and lands in the same BOM, and committed ELF binaries are hashed and looked up against CIRCL hashlookup and MalwareBazaar. We are not better everywhere — Snyk fingerprints vendored C/C++ source, which neither Prisma Cloud nor Vulnetix does — but the specific case of "somebody committed a binary" is covered here and explicitly not there.

The JavaScript and Python gaps are the ones most likely to bite an ordinary engineering org. pnpm, Yarn Berry, npm workspaces and Poetry are not exotic; a monorepo read only at its root produces an SBOM that looks complete and is not. Vulnetix reads all of those lockfiles wherever they appear in the tree, and so does GitLab.

The same shape of gap covers two newer rows in this comparison. A statically linked Go service carries its whole module list inside the binary, and a CI job that apt-gets a package puts that package in the build; Prisma Cloud reads neither — the vendor answer says bundled binaries "will not be detected" and that source scanning does not parse CI configuration. Vulnetix reads Go build info, Rust cargo-auditable data and JVM archive coordinates out of the artefacts themselves, and parses install commands out of around forty CI systems plus shell scripts and Makefiles, into the same document.

CBOM and AI-BOM: not a comparison

There is nothing to compare here. Prisma Cloud produces no cryptography bill of materials and no repository-scoped AI-BOM. Palo Alto Networks does have serious AI security products — AI-SPM for cloud AI posture, and Prisma AIRS for discovering agents and models across cloud, SaaS and endpoints — and an organisation buying AI runtime security should look at them. But an AI asset inventory in a cloud console is not a CycloneDX AI-BOM attached to a commit, and it does not satisfy a customer or regulator asking for one.

If a CBOM is on your roadmap because of post-quantum migration deadlines, this is a hard gap rather than a soft one: no crypto inventory, no algorithm classification, no certificate posture.

Verdict against Vulnetix. Prisma Cloud is a cloud platform with an SBOM feature, not a bill-of-materials tool. If your problem is "what is running in my cloud and where did it come from", it answers that better than Vulnetix does. If your problem is "produce a complete, accurate, signed inventory of this repository, including crypto and AI", the vendor's own answers describe several holes in that inventory, and two of the three BOM types do not exist at all.

Sources: Prisma Cloud — Software Composition Analysis · Prisma Cloud — SBOM · Palo Alto Networks — AI-SPM · Written vendor answers to our SBOM questionnaire (reproduced on this page)

GitLab: GitLab Ultimate — Dependency Scanning (SBOM-based)

SBOM-based dependency scanning went generally available in GitLab 19.0. If your code already lives in GitLab, this is the least friction available to anyone.

Evidence. All GitLab verdicts come from GitLab's public documentation and its own issue tracker, which is unusually candid — where something is not shipped, there is generally an open issue saying so.

What GitLab does well

• Zero integration cost for GitLab users. The analyzer runs as a CI job in your own runners, so no third party clones your repository and the SBOM is produced where the code already is.
• Broad, current ecosystem coverage: npm, pnpm, Yarn and bun; pip, pipenv, Poetry and uv; Maven, Gradle and Ivy; Go, Cargo, Composer, NuGet, bundler, Dart, Swift, Scala, Conda and CocoaPods.
• Automatic dependency resolution for Maven, Gradle and Python generates the lockfile or graph export when the project has not committed one, running the ecosystem-native tool to do it.
• Dev versus runtime dependency distinction via DS_INCLUDE_DEV_DEPENDENCIES across Composer, Conda, Gradle, Maven, npm, pnpm, Pipenv, Poetry and uv.
• Ingests third-party CycloneDX reports into the same dependency list, so BOMs from other tools are first-class rather than a separate silo.
• A static reachability phase parses source files to mark which SBOM components are actually used, and writes that back into the SBOM — so the BOM itself carries prioritisation signal, not just an inventory.
• Container scanning can be told to report non-OS packages as well, including Go binaries and jar files inside the image, by setting CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN to "false" — off by default, but available without leaving the platform.
• Artefact provenance is a genuine strength elsewhere in the product: SLSA level 2/3 provenance for artefacts the pipeline builds, Sigstore signing components, and an Attestations API that returns Sigstore bundles.
• Dependency paths went GA in 18.2, so you can see which direct dependency pulled in a transitive one — the question every triage conversation starts with.

Documented gaps

• No CBOM. Crypto asset support is an open epic (gitlab-org epic 14930) and an open SCA issue (585268), not a shipped feature.
• No AI-BOM. GitLab 19.0 put agentic AI into the platform, but there is no AI bill of materials for models, agents or MCP servers.
• No SPDX. Exports are GitLab JSON, CSV, CycloneDX 1.4 (pipeline scope) and CycloneDX 1.6 (project scope); SPDX export is an open issue (436388).
• No VEX. Adding VEX to SBOM reports is an open issue (413694), so exploitability statements have to come from somewhere else.
• Lockfile-first by design: vendored source, committed binaries and anything not declared in a manifest or graph export are outside the analyzer's remit.
• Ultimate tier only, which puts the whole capability behind GitLab's top plan.
• Build-time dependencies from Dockerfiles are covered by container scanning as a separate report rather than folded into the dependency SBOM.

Where GitLab is genuinely ahead

Friction. The analyzer is a CI job in a pipeline you already run, the results land in a UI your developers already have open, and dependency paths are one click from the finding. Vulnetix runs as a CLI in your pipeline and posts results to a separate console; for a team that lives inside GitLab, that is one more place to look.

Automatic dependency resolution deserves credit too. For Maven, Gradle and Python, GitLab will generate the missing lockfile or graph export by running the ecosystem's own tooling rather than refusing to produce an answer. Vulnetix is more conservative here — for Cargo and Composer we ask you to build or generate a lockfile instead of inferring a tree we cannot verify. Both positions are defensible; GitLab's produces an SBOM in more situations, ours produces fewer SBOMs that are quietly wrong.

And the CycloneDX ingestion path is genuinely good design: any CycloneDX report from any tool joins the same dependency list. That is the same instinct behind Vulnetix accepting CycloneDX, SPDX, SARIF, OpenVEX and CSAF-VEX uploads.

The static reachability phase deserves particular credit. GitLab parses source files to mark which SBOM components are actually used and writes that back into the SBOM, so the artefact carries prioritisation signal rather than just an inventory. Vulnetix builds a tree-sitter call graph and walks it from entry points to the vulnerable symbol named in the advisory, which is a different route to the same goal; the point worth making here is that GitLab is doing this properly and it is the second vendor in this comparison that does.

One BOM out of three

The substantive difference is scope. GitLab produces an SBOM. It produces no CBOM — that work is an open epic — and no AI-BOM at all. If your driver is post-quantum readiness or an AI transparency obligation, GitLab does not have an answer today, and its own tracker is where you can watch for one.

Vulnetix emits all three from the same CLI, into the same CycloneDX 1.6/1.7 family, with the AI-BOM covering models, agents, MCP servers, AI infrastructure declared in Kubernetes and compose files, and shadow-AI signals from tool configs and environment variable names. The CBOM classifies every algorithm for quantum posture and annotates it against nine regulators.

Format and evidence gaps

Two smaller gaps matter in regulated procurement. SPDX is not available — the export menu offers GitLab JSON, CSV and CycloneDX — and a customer whose supply-chain policy is written around SPDX will not accept "we can give you CycloneDX instead" as an answer forever. Vulnetix emits SPDX 2.3 JSON as well as CycloneDX.

The other is VEX. GitLab has an open issue to add VEX to SBOM reports; until it ships, an SBOM handed to a customer says what is in the product but not which of the listed CVEs actually affect it. Vulnetix mints OpenVEX from triage decisions and alongside each BOM type, which is the difference between shipping a list of 400 CVEs and shipping a defensible statement about them.

A third is quieter and shows up in the new dependency-graph row. GitLab ingests dependency paths and shows them in the dependency list, which is genuinely useful in the UI — but adding a CycloneDX dependencies array with ref and dependsOn to the emitted SBOM is still open issue 428073. So the graph exists inside GitLab and not inside the artefact you hand to someone else. Snyk emits the array; so does Vulnetix, built from lockfile and installed-tree edges plus the module graph recovered from binaries.

Verdict against Vulnetix. GitLab has the best SBOM story of the three competitors here, and for a GitLab-native team the friction argument is close to unanswerable. The comparison is not really about SBOM quality — it is that GitLab produces one of the three bills of materials, in one format family, without VEX, and only on Ultimate.

Sources: GitLab — Dependency scanning by using SBOM · GitLab — Dependency list · GitLab — Dependency list export API (formats) · GitLab epic 14930 — Add support for crypto assets [CBOM] (open) · GitLab issue 436388 — Export dependency list in SPDX format (open) · GitLab issue 413694 — Support VEX in SBOM reports (open) · GitLab issue 428073 — Add CycloneDX dependency relationship and author fields (open) · GitLab — Container scanning (CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN) · GitLab — Offline environments · GitLab — SLSA provenance attestations

Snyk: Snyk Open Source — snyk sbom, snyk sbom test, snyk aibom

The strongest BOM tooling of the three competitors, and the only one besides Vulnetix shipping an AI-BOM. Format support is excellent; the constraint is what sits behind the Enterprise plan.

Evidence. All Snyk verdicts come from Snyk's CLI documentation and supported-language pages.

What Snyk does well

• The widest format support here: CycloneDX 1.4, 1.5 and 1.6 in JSON or XML, plus SPDX 2.3 JSON, from one command.
• snyk aibom is a real AI-BOM and it is GA, not a lab experiment: models with model-card and licence information, agents, tool calls and MCP servers, for Python, Java, JavaScript and Go, emitted as CycloneDX 1.6 with an optional HTML view.
• snyk sbom test closes the loop by testing an existing CycloneDX 1.4–1.6 or SPDX 2.3 document for vulnerabilities, including SBOMs produced by other tools or received from a third-party vendor.
• The --unmanaged mode fingerprints C and C++ source files against Snyk's database, which genuinely finds vendored open source that no manifest declares — a capability neither Prisma Cloud nor Vulnetix offers.
• Deep, mature ecosystem coverage with per-ecosystem documentation, and container SBOM generation as a first-class command.
• Snyk Container reverse-parses Go binaries built with module support and unpacks nested JARs to whatever depth you ask for, on by default since CLI 1.1090.0 — so a statically linked Go service in an image is not a blind spot.
• CycloneDX output carries a real dependencies array with ref and dependsOn, so the graph survives leaving Snyk — something GitLab has open as an issue rather than shipped.

Documented gaps

• No CBOM. Snyk publishes no cryptography bill of materials, no algorithm-level quantum posture and no certificate inventory.
• snyk sbom is Enterprise-plan only, so SBOM generation is gated behind the top commercial tier.
• uv support is Early Access and Enterprise-only, which is a strange place for a package manager this widely adopted.
• CycloneDX output does not differentiate development dependencies. The --dev flag includes them, and SPDX marks them with a DEV_DEPENDENCY_OF relationship, but in CycloneDX they arrive undistinguished.
• Vendored detection is real but narrow: C/C++ source fingerprinting only, and Snyk notes that modified dependency source reduces accuracy. Custom-built JARs, even those containing open source, are not supported.
• No VEX output documented, so exploitability statements are not part of the deliverable.
• AI-BOM coverage is source-code-centric: models, agents and MCP servers from four languages, without AI infrastructure declared in Kubernetes or compose files.

Where Snyk is genuinely ahead

Vendored C/C++ is the honest one. snyk test --unmanaged converts files into hashes and matches them against Snyk's database, so a copied-in library with no manifest still resolves to a package, a version and its CVEs. Vulnetix hashes committed ELF binaries and looks them up against CIRCL hashlookup and MalwareBazaar, which answers "is this binary known and is it malicious" but not "which open source library is this source tree a copy of". For C and C++ estates where vendoring is the norm rather than the exception, that is a real advantage and it should weigh in the decision.

Format breadth is the second. CycloneDX in three spec versions and two encodings plus SPDX 2.3 covers essentially any customer request. Vulnetix emits CycloneDX 1.6/1.7 JSON and SPDX 2.3 JSON — no XML — so a customer with an XML-only intake pipeline is better served by Snyk today.

And snyk sbom test is a genuinely useful piece of the ecosystem: point it at a vendor-supplied SBOM and get vulnerabilities back. Vulnetix ingests third-party CycloneDX, SPDX, SARIF, OpenVEX and CSAF-VEX for the same reason.

Binaries inside images are close to a draw. Snyk Container reverse-parses Go binaries built with module support and unpacks nested JARs as deep as you ask, on by default since CLI 1.1090.0, which covers the common case well. Vulnetix reads the same Go build info plus Rust cargo-auditable crate lists and JVM archive coordinates, and does it for binaries committed to a repository as well as ones inside an unpacked image or a saved tar — then attributes each file to the dpkg, apk or pacman package that installed it, so a binary that arrived outside the package manager is visible as such. Snyk covers more languages in the image; Vulnetix covers more places and says where each artefact came from.

AI-BOM: the one comparison that is close

Both tools ship an AI-BOM and both emit CycloneDX 1.6. Snyk covers Python, Java, JavaScript and Go, identifying foundational and open-source models with model-card and licence metadata where available, agents from popular agent libraries, tool calls from common patterns, and MCP servers from the official SDK. That is a strong, well-scoped product.

Vulnetix approaches the same problem from more directions: SDK call sites and the model literals passed to them (anchored on the SDK parameter, so a model released next month is still captured); AI tool and provider environment variable names, read as names only, never values; agent and assistant config directories, instructions, skills, hooks, plugins and MCP manifests; and AI infrastructure declared in Kubernetes manifests including KServe, Kubeflow and KubeRay CRDs, compose files and Dockerfiles — serving runtimes such as vLLM, TGI, Triton and Ollama, vector databases, model-artifact volumes and GPU requests.

The practical difference is what counts as AI in your organisation. If AI means SDK calls in application code, the two are comparable. If it means a self-hosted inference stack, a vector database and a fleet of coding agents configured per developer, more of that is visible to a scanner that also reads IaC and tool configuration. Vulnetix also drops values it cannot verify — templated Helm values, secret-referenced envs, non-semver image tags — rather than guessing, which is the behaviour you want in an artefact you may have to defend.

CBOM, VEX and the plan gate

Snyk has no CBOM. For an organisation with a post-quantum migration on its roadmap — and after EO 14412 that is a growing number of them — that is a hard gap: no crypto asset inventory, no quantum-vulnerable classification, no certificate or key posture, no regulator matrix. Vulnetix classifies every detected algorithm as quantum-safe, quantum-vulnerable, deprecated or hybrid, records its NIST quantum-security level, and annotates approval status for NIST, CNSA 2.0, BSI, ACSC, CCCS, NUKIB, AIVD, NCSC and KpqC.

VEX is the second gap. Neither an SBOM nor an AI-BOM tells a customer which listed vulnerabilities actually affect the product; Vulnetix mints OpenVEX from triage decisions and per BOM type, versioned so an auditor can see what was asserted and when.

The third is commercial rather than technical, and worth stating plainly because it decides who can act: snyk sbom requires an Enterprise plan, and uv support sits behind Enterprise Early Access. Vulnetix generates SBOM, CBOM and AI-BOM from the free CLI. That is not a claim about which product is better — it is a claim about who gets to produce a bill of materials at all.

One consequence of that is worth its own row: Snyk documents that snyk sbom "requires an internet connection", so there is no way to produce a bill of materials on an air-gapped build agent or during an evaluation without an account. vulnetix cdx writes a schema-validated document with zero API calls and no credentials, which is the difference between a capability you can try today and one you can try after procurement.

Verdict against Vulnetix. Snyk is the closest competitor in this comparison and beats Vulnetix outright on vendored C/C++ detection and on CycloneDX XML output. The differences that remain are CBOM (Snyk has none), the breadth of the AI-BOM beyond source code, VEX, and the fact that generating an SBOM at all requires an Enterprise plan.

Sources: Snyk — snyk sbom · Snyk — snyk sbom test · Snyk — snyk aibom · Snyk — C/C++ unmanaged scanning · Snyk — support for uv · Snyk — detect application vulnerabilities in container images (Go binaries, nested JARs) · Snyk — container sbom

What Palo Alto Networks told us, in writing

Prisma Cloud publishes less SBOM implementation detail than the other two vendors, so rather than infer, we asked. These are the ten questions we sent and the substance of the answers Palo Alto Networks returned. Their answers were candid, and most of the gaps in the Prisma Cloud column are ones they named themselves.

1. How does Prisma Cloud generate an SBOM from source code — does it clone the repository?

Yes. The platform authenticates to the customer's VCS provider with a configured integration token, runs a real git clone, and stages the working tree into cloud storage as a snapshot that all scanners read. The SCA scanner then finds manifests and lockfiles per language and either parses the lockfile directly or runs the real package manager against the cloned files.

2. What types of files does the SBOM scanner inspect?

Source-repo scanning inspects manifests and lockfiles detected by filename — package.json and its lockfile, pom.xml, requirements.txt, go.mod and so on. Container image scanning is a separate layer that builds or pulls the image and reads OS and language package databases. The two are tracked as separate outputs and are not merged into one dependency graph.

3. Can it detect vendored or embedded components — binaries or library source committed into the repository?

No. In the vendor's words, a committed vendor/ folder, a bundled .jar or .dll, or third-party code pasted in rather than pulled via a package manager "will not be detected". Image scanning does not close the gap: it detects packages via OS and language package-manager databases, not arbitrary files copied in outside a package manager.

4. How is the build system determined?

Fully automatically, from which manifest and lockfile files are present, with disambiguation rules when several candidates share a folder (a lockfile takes precedence over its manifest). There is no way for a user to configure or override detection from a file in the repository.

5. How are alternative package managers and workflows handled — for example Yarn workspaces?

Yarn v1 workspaces produce incomplete results: only the root package.json and yarn.lock are read, so per-workspace direct dependencies and cross-workspace links are missed. npm-native workspaces (v7+), Yarn Berry (v2+), pnpm, Lerna/Nx and Poetry are not supported at all.

6. Does the SBOM distinguish test and development dependencies from runtime ones?

Inconsistently. The distinction exists for npm and Yarn but not for Java, Ruby or PHP, even where the underlying package metadata supports it. The vendor asked for this to be treated as a current limitation rather than a uniform guarantee.

7. Can it identify build-time dependencies, such as those installed by a Dockerfile or CI configuration?

Not at the source-repo level — Dockerfile instructions and CI pipeline files are not parsed for dependencies. Container image scanning partially covers this by inspecting the built image, as a separate scan and output that is not merged into the source SBOM.

8. What dependency resolution strategy is applied?

The package manager's own. Where a lockfile exists it is trusted and parsed directly; where one does not, the platform invokes the real build tool (Python, Maven, Gradle, Go, PHP, Ruby, .NET) so that resolution rules such as Maven nearest-wins are native behaviour rather than a reimplementation.

9. What support exists for private registries and authentication?

Private registries are recognised and credentials are handled securely through a platform-side integration, but coverage today is narrow — JFrog only, and only part of the languages. Other ecosystems are a current gap.

10. Can SBOM metadata — application name, repository URL, branch, organisation context — be customised per repository?

No. There is currently no supported mechanism for a repository owner to customise or override SBOM metadata from a configuration file in the repository.

Generate all three from one CLI

Vulnetix emits an SBOM, a CBOM and an AI-BOM in CycloneDX 1.6 or 1.7, SPDX 2.3 for licences, and OpenVEX beside each one. It runs on your machine or your CI runner: no repository clone into anyone's cloud, and no source content uploaded.

vulnetix scan     # SBOM  → .vulnetix/sbom.cdx.json
vulnetix cbom     # CBOM  → .vulnetix/cbom.cdx.json
vulnetix aibom    # AIBOM → .vulnetix/ai-bom.cdx.json

See how the code scanner works or read why SCA tools miss what they miss.

Get Started Free →