Software Bill of Materials (SBOM)

df-cli can generate a Software Bill of Materials for your workspace in CycloneDX 1.6 format. The SBOM lists every dependency your project uses, along with its version, license, author, and other supply-chain information.

Generating an SBOM

df-cli sbom MyWorkspace.sws sbom.cdx.json

The command takes two required arguments: the workspace file and the output file path. The generated CycloneDX JSON is written to the specified output file.

An optional --format flag selects the output format (default: cyclonedx-json):

df-cli sbom MyWorkspace.sws sbom.cdx.json --format cyclonedx-json

The output includes: - A root component representing your workspace. - A component entry for every resolved dependency (local, Git, or server-based). - Dependency relationships between components. - Tool metadata identifying the df-cli version that produced the SBOM. - DataFlex runtime services for each project in the workspace.

Enriching SBOM Output with Metadata

By default, df-cli populates each dependency's SBOM entry from its workspace configuration: name, version, license, and description. You can provide additional metadata in the package section of your .sws file to produce richer SBOM output for consumers of your library.

This is useful for compliance, auditing, and vulnerability tracking workflows that consume CycloneDX SBOMs.

All metadata fields below go inside the package section of the .sws file. Fields that have sub-properties (author, manufacturer, supplier) are written as JSON objects. Their dot-separated paths below reflect how they map to the SBOM — in the .sws file they are nested:

"author": {
    "name": "Jane Developer",
    "email": "jane@acme.com"
}

Author

Identifies the person or team that wrote the library.

Field	Description
`author.name`	Author name
`author.email`	Author email address
`author.phone`	Author phone number

If no author is specified, the publisher name is used as the author.

Publisher, Copyright, and Group

These are simple string fields in the package section.

Field	Description
`publisher`	The entity that published the package. Overrides the repository publisher name.
`copyright`	Copyright notice (e.g. `"Copyright 2026 Acme Corp"`). Used when no project-level copyright is set.
`group`	Logical grouping for the component (e.g. `"com.acme.dataflex"`). When omitted, df-cli generates a group from the upstream host and publisher name.

Manufacturer and Supplier

The manufacturer is the organization that created the software. The supplier is the organization that distributes it. These may differ (e.g. an open-source project manufactured by a community but supplied through a commercial repository).

Both are JSON objects in the package section:

Field	Description
`manufacturer.name`	Name of the manufacturing organization
`manufacturer.email`	Contact email
`manufacturer.url`	Organization URL
`supplier.name`	Name of the supplying organization
`supplier.url`	Supplier URL

External References

Links to project resources. These are simple string fields in the package section. Each URL is included in the SBOM's externalReferences array.

Field	Reference Type	Description
`website`	Website	Project homepage
`homepage`	Website	Alias for `website`
`repository`	VCS	Source code repository URL
`vcs`	VCS	Alias for `repository`
`documentation`	Documentation	Link to documentation
`issue-tracker`	Issue tracker	Bug/issue tracker URL
`issues`	Issue tracker	Alias for `issue-tracker`

Scope

Controls whether the dependency is marked as required, optional, or excluded in the SBOM.

Value	Meaning
`required`	The dependency is needed at runtime (default)
`optional`	The dependency is optional at runtime
`excluded`	The dependency is not used at runtime (e.g. test-only or tooling)

Full Example

Here is a .sws file for a library that provides rich SBOM metadata:

{
  "workspaceName": "AwesomeUI",
  "df": 25.0,
  "description": "Modern UI components for DataFlex web applications",
  "package": {
    "version": "2.1.0",
    "license": "MIT",
    "licenseFile": "LICENSE.txt",
    "publisher": "Acme Corp",
    "copyright": "Copyright 2026 Acme Corp",
    "author": {
      "name": "Jane Developer",
      "email": "jane@acme.com"
    },
    "manufacturer": {
      "name": "Acme Corp",
      "url": "https://acme.com"
    },
    "supplier": {
      "name": "Acme Distribution",
      "url": "https://dist.acme.com"
    },
    "website": "https://acme.com/awesome-ui",
    "repository": "https://github.com/acme/awesome-ui",
    "documentation": "https://docs.acme.com/awesome-ui",
    "issue-tracker": "https://github.com/acme/awesome-ui/issues",
    "tags": "ui, components, web",
    "scope": "required",
    "install": [
      "${Programs}/AwesomeUI.dll"
    ]
  }
}

When a consumer generates an SBOM for a workspace that depends on this library, the output will include all of the above information in the CycloneDX component entry for AwesomeUI.

What Gets Populated Automatically

Even without any extra metadata, df-cli populates the following for every dependency:

Name and version from the workspace configuration.
License from the license field, including license text from licenseFile when present.
Description from the workspace description or README file.
Package URL (purl) — pkg:dfpkg/ for server and Git dependencies, pkg:dfpkg/local/ for local dependencies.
CPE identifier for server and Git dependencies.
Upstream reference as an external reference for non-local dependencies.
File hashes for installed files (BLAKE2b-256).
Dependency tree showing which components depend on which.
Scope — dependencies with install files (runtime artifacts) are scoped as required; compile-time-only dependencies are scoped as optional. This can be overridden via the scope metadata tag.
Component properties — dfpkg:library:type (local, git, or server) and dfpkg:library:source (the package source identifier) are set on every dependency component.
Git pedigree — for Git dependencies, the resolved ref is recorded as a pedigree commit with the upstream URL.

For each project in the workspace, df-cli also generates:

A project component (.src suffix stripped from the name) with version, description, copyright, and manufacturer from the project's version info. The license is inherited from the workspace; if no license is configured, NOASSERTION is used. Projects marked as test projects are automatically scoped as excluded.
Version info properties — dfpkg:version:legal_trademarks, dfpkg:version:comments, dfpkg:version:internal_name, dfpkg:version:original_filename, dfpkg:version:special_build, and dfpkg:version:private_build when set in the project's version info.
A DataFlex Runtime platform component as a dependency of each project. The runtime version is resolved from the project's toolchain or the workspace's DataFlex version. If multiple projects use the same runtime version, a single shared component is emitted. The runtime license is read from DataFlex License.rtf in the toolchain root directory (as DocumentRef-DataFlex); if the file is not found, NOASSERTION is used.

The metadata tags documented above let you fill in the gaps that df-cli cannot infer automatically: authorship, organizational context, and links to external resources.