CycloneDX

The date and time (timestamp) when the BOM was created.

Lifecycles communicate the stage(s) in which data in the BOM was captured. Different types of data may be available at various phases of a lifecycle, such as the Software Development Lifecycle (SDLC), IT Asset Management (ITAM), and Software Asset Management (SAM). Thus, a BOM may include data specific to or only obtainable in a given lifecycle.

The tool(s) used in the creation, enrichment, and validation of the BOM.

The person(s) who created the BOM. Authors are common in BOMs created through manual processes. BOMs created through automated means may have @.manufacturer instead.

EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one SPDX License Expression)

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is optional.

The name of the vendor who created the tool

The name of the tool

A single disjunctive version identifier, for a component or service.

The hashes of the tool (if applicable).

External references provide a way to document systems, sites, and information that may be relevant, but are not included with the BOM. They may also establish specific relationships within or external to the BOM.

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

The name of the organization

An address used to identify a contactable location.

The URL of the organization. Multiple URLs are allowed.

A contact at the organization. Multiple contacts are allowed.

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

The name of a contact

The email address of the contact.

The phone number of the contact.

Specifies the type of component. For software components, classify as application if no more specific appropriate classification is available or cannot be determined for the component.

The name of the component. This will often be a shortened, single name of the component. Examples: commons-lang3 and jquery

The optional mime-type of the component. When used on file components, the mime-type can provide additional context about the kind of file being represented, such as an image, font, or executable. Some library or framework components may also have an associated mime-type.

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

The person(s) who created the component. Authors are common in components created through manual processes. Components created through automated means may have @.manufacturer instead.

[Deprecated] This will be removed in a future version. Use @.authors or @.manufacturer instead. The person(s) or organization(s) that authored the component

The person(s) or organization(s) that published the component

The grouping name or identifier. This will often be a shortened, single name of the company or project that produced the component, or the source package or domain name. Whitespace and special characters should be avoided. Examples include: apache, org.apache.commons, and apache.org.

A single disjunctive version identifier, for a component or service.

Specifies a description for the component

Specifies the scope of the component. If scope is not specified, 'required' scope SHOULD be assumed by the consumer of the BOM.

The hashes of the component.

EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one SPDX License Expression)

A copyright notice informing users of the underlying claims to copyright ownership in a published work.

Asserts the identity of the component using CPE. The CPE must conform to the CPE 2.2 or 2.3 specification. See [https://nvd.nist.gov/products/cpe](https://nvd.nist.gov/products/cpe). Refer to @.evidence.identity to optionally provide evidence that substantiates the assertion of the component's identity.

Asserts the identity of the component using package-url (purl). The purl, if specified, must be valid and conform to the specification defined at: [https://github.com/package-url/purl-spec](https://github.com/package-url/purl-spec). Refer to @.evidence.identity to optionally provide evidence that substantiates the assertion of the component's identity.

Asserts the identity of the component using the OmniBOR Artifact ID. The OmniBOR, if specified, must be valid and conform to the specification defined at: [https://www.iana.org/assignments/uri-schemes/prov/gitoid](https://www.iana.org/assignments/uri-schemes/prov/gitoid). Refer to @.evidence.identity to optionally provide evidence that substantiates the assertion of the component's identity.

Asserts the identity of the component using the Software Heritage persistent identifier (SWHID). The SWHID, if specified, must be valid and conform to the specification defined at: [https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html](https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html). Refer to @.evidence.identity to optionally provide evidence that substantiates the assertion of the component's identity.

Specifies metadata and content for ISO-IEC 19770-2 Software Identification (SWID) Tags.

[Deprecated] This will be removed in a future version. Use the pedigree element instead to supply information on exactly how the component was modified. A boolean value indicating if the component has been modified from the original. A value of true indicates the component is a derivative of the original. A value of false indicates the component has not been modified from the original.

Component pedigree is a way to document complex supply chain scenarios where components are created, distributed, modified, redistributed, combined with other components, etc. Pedigree supports viewing this complex chain from the beginning, the end, or anywhere in the middle. It also provides a way to document variants where the exact relation may not be known.

External references provide a way to document systems, sites, and information that may be relevant but are not included with the BOM. They may also establish specific relationships within or external to the BOM.

A list of software and hardware components included in the parent component. This is not a dependency tree. It provides a way to specify a hierarchical representation of component assemblies, similar to system → subsystem → parts assembly in physical supply chains.

Provides the ability to document evidence collected through various forms of extraction or analysis.

A model card describes the intended uses of a machine learning model and potential limitations, including biases and ethical considerations. Model cards typically contain the training parameters, which datasets were used to train the model, performance metrics, and other relevant data useful for ML transparency. This object SHOULD be specified for any component of type machine-learning-model and must not be specified for other component types.

This object SHOULD be specified for any component of type data and must not be specified for other component types.

Cryptographic assets have properties that uniquely define them and that make them actionable for further reasoning. As an example, it makes a difference if one knows the algorithm family (e.g. AES) or the specific variant or instantiation (e.g. AES-128-GCM). This is because the security level and the algorithm primitive (authenticated encryption) are only defined by the definition of the algorithm variant. The presence of a weak cryptographic algorithm like SHA1 vs. HMAC-SHA1 also makes a difference.

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is optional.

Textual strings that aid in discovery, search, and retrieval of the associated object. Tags often serve as a way to group or categorize similar or related objects by various attributes.

Enveloped signature in JSON Signature Format (JSF).

Maps to the tagId of a SoftwareIdentity.

Maps to the name of a SoftwareIdentity.

Maps to the version of a SoftwareIdentity.

Maps to the tagVersion of a SoftwareIdentity.

Maps to the patch of a SoftwareIdentity.

Specifies the metadata and content for an attachment.

The URL to the SWID file.

The attachment data. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.

Specifies the format and nature of the data being attached, helping systems correctly interpret and process the content. Common content type examples include application/json for JSON data and text/plain for plain text documents. RFC 2045 section 5.1 outlines the structure and use of content types. For a comprehensive list of registered content types, refer to the IANA media types registry.

Specifies the optional encoding the text is represented in.

The algorithm that generated the hash value.

The value of the hash.

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

A valid SPDX license identifier. If specified, this value must be one of the enumeration of valid SPDX license identifiers defined in the spdx.schema.json (or spdx.xml) subschema which is synchronized with the official SPDX license list.

The name of the license. This may include the name of a commercial or proprietary license or an open source license that may not be defined by SPDX.

Declared licenses and concluded licenses represent two different stages in the licensing process within software development. Declared licenses refer to the initial intention of the software authors regarding the licensing terms under which their code is released. On the other hand, concluded licenses are the result of a comprehensive analysis of the project's codebase to identify and confirm the actual licenses of the components used, which may differ from the initially declared licenses. While declared licenses provide an upfront indication of the licensing intentions, concluded licenses offer a more thorough understanding of the actual licensing within a project, facilitating proper compliance and risk management. Observed licenses are defined in @.evidence.licenses. Observed licenses form the evidence necessary to substantiate a concluded license.

Specifies the metadata and content for an attachment.

The URL to the license file. If specified, a 'license' externalReference should also be specified for completeness

Licensing details describing the licensor/licensee, license type, renewal and expiration dates, and other important metadata

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is optional.

A unique identifier of the commit. This may be version control specific. For example, Subversion uses revision numbers whereas git uses commit hashes.

The URL to the commit. This URL will typically point to a commit in a version control system.

Specifies an individual commit

Specifies an individual commit

The text description of the contents of the commit

Specifies the purpose for the patch including the resolution of defects, security issues, or new behavior or functionality.

The patch file (or diff) that shows changes. Refer to https://en.wikipedia.org/wiki/Diff

A collection of issues the patch resolves

Specifies the metadata and content for an attachment.

Specifies the URL to the diff

Specifies the type of issue

The identifier of the issue assigned by the source of the issue

The name of the issue

A description of the issue

The source of the issue where it is documented

A collection of URL's for reference. Multiple URLs are allowed.

The timestamp in which the action occurred

The name of the individual who performed the action

The email address of the individual who performed the action

The URI (URL or URN) to the external reference. External references are URIs and therefore can accept any URL scheme including https (RFC-7230), mailto (RFC-2368), tel (RFC-3966), and dns (RFC-4501). External references may also include formally registered URNs such as CycloneDX BOM-Link to reference CycloneDX BOMs or any object within a BOM. BOM-Link transforms applicable external references into relationships that can be expressed in a BOM or across BOMs.

Specifies the type of external reference.

An optional comment describing the external reference

The hashes of the external reference (if applicable).

Descriptor for an element identified by the attribute 'bom-ref' in the same BOM document. In contrast to bomLinkElementType.

The bom-ref identifiers of the components or services that are dependencies of this dependency object.

The bom-ref identifiers of the components or services that define a given specification or standard, which are provided or implemented by this dependency object. For example, a cryptographic library which implements a cryptographic algorithm. A component which implements another component does not imply that the implementation is in use.

The name of the service. This will often be a shortened, single name of the service.

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

The grouping name, namespace, or identifier. This will often be a shortened, single name of the company or project that produced the service or domain name. Whitespace and special characters should be avoided.

A single disjunctive version identifier, for a component or service.

Specifies a description for the service

The endpoint URIs of the service. Multiple endpoints are allowed.

A boolean value indicating if the service requires authentication. A value of true indicates the service requires authentication prior to use. A value of false indicates the service does not require authentication.

A boolean value indicating if use of the service crosses a trust zone or boundary. A value of true indicates that by using the service, a trust boundary is crossed. A value of false indicates that by using the service, a trust boundary is not crossed.

The name of the trust zone the service resides in.

Specifies information about the data including the directional flow of data and the data classification.

EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one SPDX License Expression)

External references provide a way to document systems, sites, and information that may be relevant but are not included with the BOM. They may also establish specific relationships within or external to the BOM.

A list of services included or deployed behind the parent service. This is not a dependency tree. It provides a way to specify a hierarchical representation of service assemblies.

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is optional.

Textual strings that aid in discovery, search, and retrieval of the associated object. Tags often serve as a way to group or categorize similar or related objects by various attributes.

Enveloped signature in JSON Signature Format (JSF).

Specifies the flow direction of the data. Direction is relative to the service.

Data classification tags data according to its type, sensitivity, and value if altered, stolen, or destroyed.

Name for the defined data

Short description of the data content and usage

Data governance captures information regarding data ownership, stewardship, and custodianship, providing insights into the individuals or entities responsible for managing, overseeing, and safeguarding the data throughout its lifecycle.

The URI, URL, or BOM-Link of the components or services the data came in from

The URI, URL, or BOM-Link of the components or services the data is sent to

The textual content of the copyright.

Evidence that substantiates the identity of a component. The identity may be an object or an array of identity objects. Support for specifying identity as a single object was introduced in CycloneDX v1.5. Arrays were introduced in v1.6. It is recommended that all implementations use arrays, even if only one identity object is specified.

Evidence of individual instances of a component spread across multiple locations.

Evidence of the components use through the callstack.

EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one SPDX License Expression)

Copyright evidence captures intellectual property assertions, providing evidence of possible ownership and legal protection.

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

The bom-ref identifiers of the components or services being described. Assemblies refer to nested relationships whereby a constituent part may include other constituent parts. References do not cascade to child parts. References are explicit for the specified constituent part only.

The bom-ref identifiers of the components or services being described. Dependencies refer to a relationship whereby an independent constituent part requires another independent constituent part. References do not cascade to transitive dependencies. References are explicit for the specified dependency only.

The bom-ref identifiers of the vulnerabilities being described.

Enveloped signature in JSON Signature Format (JSF).

The name of the property. Duplicate names are allowed, each potentially having a different value.

The value of the property.

Specifies the metadata and content for an attachment.

Defines a syntax for representing two character language code (ISO-639) followed by an optional two character country code. The language code must be lower case. If the country code is specified, the country code must be upper case. The language code and country code must be separated by a minus sign. Examples: en, en-US, fr, fr-CA

The software versioning type. It is recommended that the release type use one of 'major', 'minor', 'patch', 'pre-release', or 'internal'. Representing all possible software release types is not practical, so standardizing on the recommended values, whenever possible, is strongly encouraged.

• major = A major release may contain significant changes or may introduce breaking changes.
• minor = A minor release, also known as an update, may contain a smaller number of changes than major releases.
• patch = Patch releases are typically unplanned and may resolve defects or important security issues.
• pre-release = A pre-release may include alpha, beta, or release candidates and typically have limited support. They provide the ability to preview a release prior to its general availability.
• internal = Internal releases are not for public consumption and are intended to be used exclusively by the project or manufacturer that produced it.

The title of the release.

The URL to an image that may be prominently displayed with the release note.

The URL to an image that may be used in messaging on social media platforms.

A short description of the release.

The date and time (timestamp) when the release note was created.

One or more alternate names the release may be referred to. This may include unofficial terms used by development and marketing teams (e.g. code names).

Textual strings that aid in discovery, search, and retrieval of the associated object. Tags often serve as a way to group or categorize similar or related objects by various attributes.

A collection of issues that have been resolved.

Zero or more release notes containing the locale and content. Multiple note objects may be specified to support release notes in a wide variety of languages.

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is optional.

Location where the advisory can be obtained.

An optional name of the advisory.

The source of vulnerability information. This is often the organization that published the vulnerability.

The numerical score of the rating.

Textual representation of the severity of the vulnerability adopted by the analysis method. If the analysis method uses values other than what is provided, the user is expected to translate appropriately.

Specifies the severity or risk scoring methodology or standard used.

Textual representation of the metric values used to score the vulnerability

An optional reason for rating the vulnerability as it was

The url of the vulnerability documentation as provided by the source.

The name of the source.

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

The identifier that uniquely identifies the vulnerability.

The source of vulnerability information. This is often the organization that published the vulnerability.

Zero or more pointers to vulnerabilities that are the equivalent of the vulnerability specified. Often times, the same vulnerability may exist in multiple sources of vulnerability intelligence, but have different identifiers. References provide a way to correlate vulnerabilities across multiple sources of vulnerability intelligence.

List of vulnerability ratings. Consumers SHOULD consider ratings in prioritization decisions; source ratings may differ and aid prioritization.

List of Common Weaknesses Enumerations (CWEs) codes that describes this vulnerability.

A description of the vulnerability as provided by the source.

If available, an in-depth description of the vulnerability as provided by the source organization. Details often include information useful in understanding root cause.

Recommendations of how the vulnerability can be remediated or mitigated.

A bypass, usually temporary, of the vulnerability that reduces its likelihood and/or impact. Workarounds often involve changes to configuration or deployments.

Evidence used to reproduce the vulnerability.

Published advisories of the vulnerability if provided.

The date and time (timestamp) when the vulnerability record was created in the vulnerability database.

The date and time (timestamp) when the vulnerability record was first published.

The date and time (timestamp) when the vulnerability record was last updated.

The date and time (timestamp) when the vulnerability record was rejected (if applicable).

Individuals or organizations credited with the discovery of the vulnerability.

The tool(s) used to identify, confirm, or score the vulnerability.

An assessment of the impact and exploitability of the vulnerability.

The components or services that are affected by the vulnerability.

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is optional.

The object in the BOM identified by its bom-ref. This is often a component or service, but may be any object type supporting bom-refs.

The organization, person, component, or service which created the textual content of the annotation.

The date and time (timestamp) when the annotation was created.

The textual content of the annotation.

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

Enveloped signature in JSON Signature Format (JSF).

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

Hyper-parameters for construction of the model.

A quantitative analysis of the model

What considerations should be taken into account regarding the model's construction, training, and application?

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is optional.

The data format for input/output to the model.

The general theme or subject matter of the data being specified.

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

The name of the dataset.

The contents or references to the contents of the data being described.

Data classification tags data according to its type, sensitivity, and value if altered, stolen, or destroyed.

A description of any sensitive data in a dataset.

A collection of graphics that represent various measurements.

A description of the dataset. Can describe size of dataset, whether it's used for source code, training, testing, or validation, etc.

Data governance captures information regarding data ownership, stewardship, and custodianship, providing insights into the individuals or entities responsible for managing, overseeing, and safeguarding the data throughout its lifecycle.

Data custodians are responsible for the safe custody, transport, and storage of data.

Data stewards are responsible for data content, context, and associated business rules.

Data owners are concerned with risk and appropriate access to data.

A description of this collection of graphics.

A collection of graphics.

The name of the graphic.

Specifies the metadata and content for an attachment.

The type of performance metric.

The value of the performance metric.

The name of the slice this metric was computed on. By default, assume this metric is not sliced.

The confidence interval of the metric.

The name of the risk.

Strategy used to address this risk.

The groups or individuals at risk of being systematically disadvantaged by the model.

Expected benefits to the identified groups.

Expected harms to the identified groups.

With respect to the benefits and harms outlined, please describe any mitigation strategy implemented.

Describes energy consumption information incurred for one or more component lifecycle activities.

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is optional.

The type of activity that is part of a machine learning model development or operational lifecycle.

The provider(s) of the energy consumed by the associated model development lifecycle activity.

A measure of energy.

A measure of carbon dioxide (CO2).

A measure of carbon dioxide (CO2).

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is optional.

Quantity of energy.

Unit of energy.

Quantity of carbon dioxide (CO2).

Unit of carbon dioxide (CO2).

The energy source for the energy provider.

A measure of energy.

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

A description of the energy provider.

External references provide a way to document systems, sites, and information that may be relevant but are not included with the BOM. They may also establish specific relationships within or external to the BOM.

Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.

The country name or the two-letter ISO 3166-1 country code.

The region or state in the country.

The locality or city within the country.