Not released yet. Vulnetix for VS Code is being built in the open. These pages document the design so it can be reviewed early; the extension is not on the marketplaces and the install steps do not work yet. Follow along on GitHub.

SBOM and VEX

CycloneDX, SPDX and OpenVEX generated from the editor, for the customer questionnaire you will eventually receive.

Planned Designed and scheduled, not yet built. Documented so the design can be reviewed early.

SBOM

A Software Bill of Materials is an inventory of what your software is made of. Increasingly it is contractual: US federal software procurement requires one, the EU Cyber Resilience Act will, and enterprise customers ask for one during security review.

Generate with Vulnetix: Generate SBOM.

  • CycloneDX 1.7 (also 1.2 through 1.6), with vulnerabilities, dependency graph, licences and evidence
  • SPDX 2.3 for tooling that expects it

Components carry package URL, ecosystem, scope, whether they are direct or transitive, the file that declared them, checksums, and evidence confidence graded by where the information came from: a manifest is high confidence, an unpinned install command in a shell script is low.

Beyond dependencies

CBOM, a cryptographic bill of materials: which algorithms your code and configuration use, classified for post-quantum readiness. If you have been asked about your PQC migration plan, this is the inventory that answers it.

AI BOM: which AI SDKs, models and agents a project uses, discovered from code, configuration and commit history. Useful when someone asks which models touch your data.

VEX

An SBOM lists what you use. A Vulnerability Exploitability eXchange document says what those vulnerabilities mean for you.

Most vulnerabilities in most dependencies are not exploitable in a given application, because the vulnerable function is never called. VEX is how you say that, in a form a customer’s tooling can consume: not affected, and why.

Triage decisions made in the editor become VEX statements. Mark a finding as not affected with a justification such as “vulnerable code not in execute path”, and it is exported as OpenVEX 0.2.0 or CycloneDX VEX.

This is the difference between answering a security questionnaire by hand every quarter and generating the answer.

Where they go

Artefacts are written under .vulnetix/ in your workspace, listed in the Compliance view, and exportable anywhere. Signed-in organisations can publish them so a release’s SBOM and VEX are retrievable later, which is what an auditor will ask for.

Didn't find what you needed? Tell us what's missing · Ask a question · Edit this page