Leveraging Data Components
Data components provide the ability to inventory data as part of a bill of material. This specialized type of component benefits from all the other capabilities that CycloneDX provides, including tracking the provenance and pedigree of data.
A data “type” describes the general theme or subject matter of the data being specified. The following are supported types:
|configuration||Parameters or settings that may be used by other components.|
|dataset||A collection of data.|
|definition||Data that can be used to create new instances of what the definition defines.|
|source-code||Any type of code, code snippet, or data-as-code.|
|other||Any other type of data that does not fit into existing definitions.|
To help visualize a typical scenario, let’s describe an application with a few different data components that represent custom source code and configurations bundled in an application.
Other possible scenarios include:
- Inclusion of all source code that makes up a component.
- Inclusion of inline datasets bundled with a component.
- Externalizing the data components using an External Reference of type ‘bom’.
- Leveraging CycloneDX lifecycles and External References to create an Operations Bill of Materials (OBOM) linking the SBOM of the application, the HBOM of the hardware it’s running on, and describing the runtime configuration of the system in the OBOM.
CycloneDX does not attempt to normalize configurations into a common vocabulary. Systems and applications may have specialized ways of representing configurations that are specific to them. Rather, CycloneDX leverages existing support for name/value pairs (properties), attachments, and URLs to external resources. With this approach, common and specialized configuration mechanisms are supported. Consumers of BOMs with data components will need to understand the context and semantics of the data specified.