SBOM Output Reference

Preview Feature — Available in VIPM 2026 Q3 Preview

The SBOM and sync commands are available in the VIPM 2026 Q3 Preview. Download it to try these features and share your feedback.

This page documents the structure and content of CycloneDX 1.5 SBOMs generated by vipm sbom. Use it to understand what data appears in your SBOM, where that data comes from, and how to interpret each field.

Document structure

The generated JSON follows the CycloneDX 1.5 specification. At the top level, every SBOM contains these sections:

{
  "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "serialNumber": "urn:uuid:...",
  "metadata": { ... },
  "components": [ ... ],
  "dependencies": [ ... ]
}

Field	Description
`$schema`	JSON schema URL for validation. Derived from `--schema-version` — e.g., `--schema-version 1.5` produces `http://cyclonedx.org/schema/bom-1.5.schema.json`.
`bomFormat`	Set by `--format`. Currently the only supported value is `"CycloneDX"`.
`specVersion`	Set by `--schema-version`. Currently the only supported value is `"1.5"`.
`version`	Document revision number. Starts at `1`; increment with `--document-version` when re-issuing an SBOM for the same product release.
`serialNumber`	Unique identifier in `urn:uuid:...` format. Auto-generated unless set with `--document-serial-number`. Use the same serial number across revisions of the same SBOM.

Metadata section

The metadata object describes your product and how the SBOM was created.

`metadata.timestamp`

ISO 8601 UTC timestamp recording when the SBOM was generated. Example: "2026-03-18T14:30:00.000Z".

`metadata.tools`

Identifies the tool that produced the SBOM:

"tools": {
  "components": [
    {
      "type": "application",
      "publisher": "JKI",
      "name": "vipm-cli",
      "version": "2026.3.0"
    }
  ]
}

The version reflects the installed VIPM Desktop version, falling back to the CLI build version if VIPM Desktop is not available.

`metadata.component`

The root component — your product. This is set by the --product-name, --product-version, and --product-type CLI options.

"component": {
  "type": "application",
  "name": "My Instrument",
  "version": "2.1.0",
  "bom-ref": "pkg:vipm/My-Instrument@2-1-0"
}

Field	Source
`type`	`--product-type` (default: `application`)
`name`	`--product-name`, or the input filename stem if omitted (e.g., `MyProject.lvproj` becomes `MyProject`)
`version`	`--product-version`. Omitted entirely from the SBOM if not provided.
`bom-ref`	Auto-generated Package URL derived from the product name and version

Components array

Each entry in components represents one dependency found in your project. All dependency components have type set to "library".

Component fields

{
  "type": "library",
  "name": "oglib_file",
  "version": "6.0.2.28",
  "bom-ref": "pkg:vipm/oglib_file@6.0.2.28",
  "purl": "pkg:vipm/oglib_file@6.0.2.28",
  "supplier": {
    "name": "OpenG.org"
  },
  "description": "File and directory utility VIs for LabVIEW.",
  "licenses": [
    { "license": { "id": "BSD-3-Clause" } }
  ],
  "hashes": [
    { "alg": "SHA-256", "content": "0123456789abcdef..." },
    { "alg": "MD5", "content": "abcdef0123456789..." }
  ]
}

The table below describes each field and where the data originates.

Field	Description	Data source
`type`	Always `"library"` for dependencies.	Static
`name`	Package identifier (e.g., `oglib_file`, `ni-daqmx`).	Input file or lock file
`version`	Exact installed version string.	Input file or lock file
`bom-ref`	Package URL used to link this component in the dependency graph. Same value as `purl`.	Generated
`purl`	Package URL — a standardized identifier. See Package URLs below.	Generated
`supplier.name`	Package vendor or publisher.	VIPM: `vendor` from package spec. NIPM: `Maintainer` field.
`description`	Package description. For NIPM packages, the feed name and URL are appended when available.	VIPM: `description` from package spec. NIPM: `Description` field.
`licenses`	Array of license entries. See License handling.	VIPM: `license` from package spec. NIPM: `Eula` field.
`hashes`	Cryptographic checksums. See Hash algorithms.	VIPM: cached hashes. NIPM: hash fields from NIPM CLI.

Fields are omitted from the JSON when no data is available (e.g., if a package has no description, the description key is absent).

Dependencies array

The dependencies section records the relationship between your product and its components:

"dependencies": [
  {
    "ref": "pkg:vipm/My-Instrument@2-1-0",
    "dependsOn": [
      "pkg:vipm/oglib_file@6.0.2.28",
      "pkg:vipm/jki_state_machine@2020.0.2.50",
      "pkg:nipkg/ni-daqmx@23.8.0.49349-0%2Bf197"
    ]
  }
]

The ref field points to your root component. The dependsOn array lists the Package URL of every dependency. This gives downstream tools a machine-readable dependency graph.

If the project has no dependencies, the dependsOn field is omitted.

Package URLs

Every component includes a Package URL (purl) that uniquely identifies it. The format depends on the package manager.

VIPM packages

pkg:vipm/<package-name>@<version>

Example: pkg:vipm/oglib_file@6.0.2.28

NIPM packages

pkg:nipkg/<package-name>@<version>[?feed=<feed-url>]

Examples:

pkg:nipkg/ni-daqmx@23.8.0.49349-0%2Bf197
pkg:nipkg/ni-daqmx@23.8.0.49349-0%2Bf197?feed=https://download.ni.com/support/nipkg/products/ni-d/ni-daqmx/23.8/released

The feed query parameter is included when the source feed URL is known (from Dragon file feed configuration or vipm.toml feed declarations). Special characters in version strings (such as +) are percent-encoded per the purl specification.

License handling

VIPM normalizes license identifiers to SPDX format when possible. The CLI embeds a copy of the official SPDX license list that is current as of the VIPM release date.

VIPM packages

The license field from the VIPM package specification is normalized:

Package license value	SBOM output	Format
`MIT`	`{ "license": { "id": "MIT" } }`	SPDX identifier
`BSD` or `BSD-3-Clause`	`{ "license": { "id": "BSD-3-Clause" } }`	SPDX identifier
`Apache-2.0`	`{ "license": { "id": "Apache-2.0" } }`	SPDX identifier
Unrecognized string	Omitted	—
Empty or missing	Omitted	—

Common license names (case-insensitive) are mapped to their SPDX identifiers — for example, "bsd" becomes BSD-3-Clause and "apache 2.0" becomes Apache-2.0.

NIPM packages

NIPM package metadata includes an Eula field that references EULA package names (e.g., eula-ni-standard). Each EULA name appears as a license entry in the SBOM:

"licenses": [
  { "license": { "name": "eula-ni-standard" } }
]

Multiple EULAs (comma-separated in the NIPM metadata) produce multiple license entries.

Hash algorithms

Cryptographic hashes verify component integrity. The algorithms included depend on the package manager.

VIPM packages

VIPM includes hashes from its local package cache:

Algorithm	Availability
SHA-256	Included when available
MD5	Included when available

NIPM packages

NIPM provides hashes from the NI Package Manager CLI:

Algorithm	Availability
SHA-256	Included when available
SHA-1	Included when available
MD5	Included when available

CycloneDX 1.5 also supports SHA-384, SHA-512, SHA3-256/384/512, BLAKE2b-256/384/512, and BLAKE3. These are included in the SBOM when present in the package metadata.

Metadata enrichment

VIPM enriches each dependency with additional metadata beyond what the input file provides. Enrichment uses local caches only — no network requests are made during SBOM generation.

VIPM package enrichment

Metadata is read from the VIPM PackageStore (the local cache of installed packages):

Enriched field	PackageStore source
Description	`description`
Vendor/supplier	`vendor`
License	`license` (normalized to SPDX)
Hashes	Cached SHA-256 and MD5

If the PackageStore has no entry for a package (e.g., cache not populated), the component still appears in the SBOM with its name and version, but the enriched fields are omitted.

NIPM package enrichment

When NI Package Manager is installed, VIPM queries it for package metadata:

Enriched field	NIPM CLI source
Description	`Description`
Vendor/supplier	`Maintainer`
EULAs	`Eula`
Hashes	`SHA256` / `SHA-256`, `SHA1` / `SHA-1`, `MD5sum` / `MD5Sum`

If NIPM is not installed or a query fails, the component appears with name, version, and feed information only.

NIPM packages require Windows

NI Package Manager is currently available on Windows only. When generating an SBOM from vipm.toml on Linux, NIPM packages declared in the manifest appear with basic information (name, version, feed) but without enriched metadata. When generating from an .lvproj on Linux, NIPM package dependencies cannot be discovered at all — only VIPM packages are included.

How dependencies are discovered

Each input type uses a different strategy to find your project's dependencies.

From `.lvproj` files

The CLI scans the LabVIEW project file to build a dependency list:

Parse file references — extracts all VI, library, and class references from the project XML, including auto-populating folders.
Resolve symbolic paths — converts LabVIEW symbolic paths (like <userlib>, <vilib>, <instrlib>) to disk paths using the target LabVIEW installation and LVAddons.
Look up file ownership — maps each resolved file to the VIPM or NIPM package that installed it.
Deduplicate — multiple files from the same package produce a single component (package) entry.

This means the SBOM reflects the packages that provide files actually referenced by your project, not every package installed on the system.

--follow-linker extends this by invoking the LabVIEW linker to trace subVI call chains, discovering dependencies that are loaded at runtime but not directly listed in the project file. Use --follow-depth to control how many levels deep the traversal goes.

From `vipm.toml` files

The CLI reads the declared dependencies from your manifest:

Check for lock file — if vipm.lock exists and is fresh (matches the manifest), it uses the resolved versions from the lock file.
Read dependencies — collects VIPM and NIPM dependencies. Dev-dependencies are included by default; use --no-dev to exclude them. Use --no-vipm or --no-nipm to exclude a package manager.

With a lock file, the SBOM includes the exact resolved versions. Without one, version specifiers from the manifest are used directly.

Path, git, and URL dependencies are excluded from the SBOM — only registry dependencies with version specifiers are included.

The SBOM is only as accurate as the dependencies declared in vipm.toml. Use vipm sync to reconcile your manifest with the packages actually used by your LabVIEW project before generating an SBOM.

From `.dragon` files

Dragon files declare dependencies inline and can reference a VIPC file:

Parse Dragon metadata — extracts VIPM dependencies, NIPM dependencies, and feed mappings.
Delegate to VIPC — if the Dragon file references a .vipc file, its packages are also included.
Deduplicate — if the same package appears in both the Dragon file and the VIPC, the Dragon entry takes precedence.

From `.vipc` files

VIPC files are zip archives containing a package list:

Extract package list — reads the package identifiers from the archive.
Parse name-version pairs — splits each entry into a package name and version.

VIPC files contain only VIPM packages — NIPM dependencies are not represented.

Annotated example

Below is an annotated example of a complete CycloneDX 1.5 SBOM generated from a LabVIEW project with one VIPM package and one NIPM package.

{
  "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",

  "metadata": {
    "timestamp": "2026-03-18T14:30:00.000Z",
    "tools": {
      "components": [
        {
          "type": "application",
          "publisher": "JKI",
          "name": "vipm-cli",
          "version": "2026.3.0"
        }
      ]
    },
    "component": {
      "type": "application",
      "name": "Acme Widget Tester",
      "version": "2.1.0",
      "bom-ref": "pkg:vipm/Acme-Widget-Tester@2-1-0"
    }
  },

  "components": [
    {
      "type": "library",
      "name": "oglib_file",
      "version": "6.0.2.28",
      "bom-ref": "pkg:vipm/oglib_file@6.0.2.28",
      "purl": "pkg:vipm/oglib_file@6.0.2.28",
      "supplier": { "name": "OpenG.org" },
      "description": "File and directory utility VIs for LabVIEW.",
      "licenses": [
        { "license": { "id": "BSD-3-Clause" } }
      ],
      "hashes": [
        { "alg": "SHA-256", "content": "a1b2c3d4e5f6..." },
        { "alg": "MD5", "content": "1a2b3c4d..." }
      ]
    },
    {
      "type": "library",
      "name": "ni-daqmx",
      "version": "23.8.0.49349-0+f197",
      "bom-ref": "pkg:nipkg/ni-daqmx@23.8.0.49349-0%2Bf197?feed=https://download.ni.com/support/nipkg/products/ni-d/ni-daqmx/23.8/released",
      "purl": "pkg:nipkg/ni-daqmx@23.8.0.49349-0%2Bf197?feed=https://download.ni.com/support/nipkg/products/ni-d/ni-daqmx/23.8/released",
      "supplier": { "name": "National Instruments" },
      "description": "NI-DAQmx driver for data acquisition.\nFeed: ni-daqmx-2023 Q4-released (https://download.ni.com/support/nipkg/products/ni-d/ni-daqmx/23.8/released)",
      "licenses": [
        { "license": { "name": "eula-ni-standard" } }
      ],
      "hashes": [
        { "alg": "MD5", "content": "9a8b7c6d..." },
        { "alg": "SHA-1", "content": "f1e2d3c4b5a6..." },
        { "alg": "SHA-256", "content": "b2c3d4e5f6a7..." }
      ]
    }
  ],

  "dependencies": [
    {
      "ref": "pkg:vipm/Acme-Widget-Tester@2-1-0",
      "dependsOn": [
        "pkg:vipm/oglib_file@6.0.2.28",
        "pkg:nipkg/ni-daqmx@23.8.0.49349-0%2Bf197?feed=https://download.ni.com/support/nipkg/products/ni-d/ni-daqmx/23.8/released"
      ]
    }
  ]
}

CycloneDX features not currently generated

The following CycloneDX 1.5 capabilities are not produced by vipm sbom. However, the JKI Security Tools do address many of these. You can reach out to us at security@jki.net for more information.

Feature	Description
Vulnerabilities	Known security vulnerabilities for components. Use a vulnerability scanner on the generated SBOM for this.
Services	External service dependencies (APIs, databases).
External references	URLs beyond the package URL (source repos, documentation, advisories).
Compositions	Completeness assertions about the dependency list.
Formulation	Build environment and process provenance.
Properties	Custom key-value metadata on components or the document.
Annotations	Review notes or audit commentary.

Need Help?

Report issues on GitHub
Join our community on Discord
Check the Support page for additional resources

SBOM Output Reference

Document structure

Metadata section

metadata.timestamp

metadata.tools

metadata.component

Components array

Component fields

Dependencies array

Package URLs

VIPM packages

NIPM packages

License handling

VIPM packages

NIPM packages

Hash algorithms

VIPM packages

NIPM packages

Metadata enrichment

VIPM package enrichment

NIPM package enrichment

How dependencies are discovered

From .lvproj files

From vipm.toml files

From .dragon files

From .vipc files

Annotated example

CycloneDX features not currently generated

Need Help?

`metadata.timestamp`

`metadata.tools`

`metadata.component`

From `.lvproj` files

From `vipm.toml` files

From `.dragon` files

From `.vipc` files