CycloneDX
CycloneDX Bill of Materials (BOM) file
| Type | object |
|---|---|
| File match |
bom.json
*.cdx.json
|
| Schema URL | https://catalog.lintel.tools/schemas/schemastore/cyclonedx/latest.json |
| Source | https://raw.githubusercontent.com/CycloneDX/specification/refs/heads/master/schema/bom-1.6.schema.json |
Versions
Validate with Lintel
npx @lintel/lintel checkProperties
Specifies the format of the BOM. This helps to identify the file as CycloneDX since BOMs do not have a filename convention, nor does JSON schema support namespaces. This value must be "CycloneDX".
The version of the CycloneDX specification the BOM conforms to.
Every BOM generated SHOULD have a unique serial number, even if the contents of the BOM have not changed over time. If specified, the serial number must conform to RFC 4122. Use of serial numbers is recommended.
Whenever an existing BOM is modified, either manually or through automated processes, the version of the BOM SHOULD be incremented by 1. When a system is presented with multiple BOMs with identical serial numbers, the system SHOULD use the most recent version of the BOM. The default version is '1'.
10 nested properties
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.
5 nested properties
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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.
33 nested properties
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.
5 nested properties
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.
5 nested properties
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.
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.
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.
7 nested properties
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.
[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.
6 nested properties
Describes zero or more components in which a component is derived from. This is commonly used to describe forks from existing projects where the forked version contains a ancestor node containing the original component it was forked from. For example, Component A is the original component. Component B is the component being used and documented in the BOM. However, Component B contains a pedigree node with a single ancestor documenting Component A - the original component from which Component B is derived from.
Descendants are the exact opposite of ancestors. This provides a way to document all forks (and their forks) of an original or root component.
Variants describe relations where the relationship between the components is not known. For example, if Component A contains nearly identical code to Component B. They are both related, but it is unclear if one is derived from the other, or if they share a common ancestor.
A list of zero or more commits which provide a trail describing how the component deviates from an ancestor, descendant, or variant.
A list of zero or more patches describing how the component deviates from an ancestor, descendant, or variant. Patches may be complementary to commits or may be used in place of commits.
Notes, observations, and other non-structured commentary describing the components pedigree.
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.
5 nested properties
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.
11 nested properties
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.
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.
5 nested properties
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.
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.
6 nested properties
Cryptographic assets occur in several forms. Algorithms and protocols are most commonly implemented in specialized cryptographic libraries. They may, however, also be 'hardcoded' in software components. Certificates and related cryptographic material like keys, tokens, secrets or passwords are other cryptographic assets to be modelled.
Additional properties specific to a cryptographic algorithm.
Properties for cryptographic assets of asset type 'certificate'
Properties for cryptographic assets of asset type: related-crypto-material
Properties specific to cryptographic assets of type: protocol.
The object identifier (OID) of the cryptographic asset.
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).
5 nested properties
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
5 nested properties
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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.
A list of services. This may include microservices, function-as-a-service, and other types of network or intra-process services.
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.
Provides the ability to document dependency relationships including provided & implemented components.
Compositions describe constituent parts (including components, services, and dependency relationships) and their completeness. The completeness of vulnerabilities expressed in a BOM may also be described.
Vulnerabilities identified in components or services.
Comments made by people, organizations, or tools about any object with a bom-ref, such as components, services, vulnerabilities, or the BOM itself. Unlike inventory information, annotations may contain opinions or commentary from various stakeholders. Annotations may be inline (with inventory) or externalized via BOM-Link and may optionally be signed.
Describes how a component or service was manufactured or deployed. This is achieved through the use of formulas, workflows, tasks, and steps, which declare the precise steps to reproduce along with the observed formulas describing the steps which transpired in the manufacturing process.
The list of declarations which describe the conformance to standards. Each declaration may include attestations, claims, and evidence.
7 nested properties
The list of assessors evaluating claims and determining conformance to requirements and confidence in that assessment.
The list of attestations asserted by an assessor that maps requirements to claims.
The list of claims.
The list of evidence
The list of targets which claims are made against.
3 nested properties
The list of organizations which claims are made against.
The list of components which claims are made against.
The list of services which claims are made against.
A concise statement affirmed by an individual regarding all declarations, often used for third-party auditor acceptance or recipient acknowledgment. It includes a list of authorized signatories who assert the validity of the document on behalf of the organization.
3 nested properties
The brief statement affirmed by an individual regarding all declarations. *- Notes This could be an affirmation of acceptance by a third-party auditor or receiving individual of a file.
The list of signatories authorized on behalf of an organization to assert validity of this document.
Enveloped signature in JSON Signature Format (JSF).
Enveloped signature in JSON Signature Format (JSF).
A collection of reusable objects that are defined and may be used elsewhere in the BOM.
1 nested properties
The list of standards which may consist of regulations, industry or organizational-specific standards, maturity models, best practices, or any other requirements which can be evaluated against or attested to.
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.
Enveloped signature in JSON Signature Format (JSF).
Definitions
Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.
Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.
Descriptor for another BOM document. See https://cyclonedx.org/capabilities/bomlink/
Descriptor for an element in a BOM document. See https://cyclonedx.org/capabilities/bomlink/
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.
5 nested properties
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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.
33 nested properties
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.
5 nested properties
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.
5 nested properties
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.
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.
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.
7 nested properties
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.
[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.
6 nested properties
Describes zero or more components in which a component is derived from. This is commonly used to describe forks from existing projects where the forked version contains a ancestor node containing the original component it was forked from. For example, Component A is the original component. Component B is the component being used and documented in the BOM. However, Component B contains a pedigree node with a single ancestor documenting Component A - the original component from which Component B is derived from.
Descendants are the exact opposite of ancestors. This provides a way to document all forks (and their forks) of an original or root component.
Variants describe relations where the relationship between the components is not known. For example, if Component A contains nearly identical code to Component B. They are both related, but it is unclear if one is derived from the other, or if they share a common ancestor.
A list of zero or more commits which provide a trail describing how the component deviates from an ancestor, descendant, or variant.
A list of zero or more patches describing how the component deviates from an ancestor, descendant, or variant. Patches may be complementary to commits or may be used in place of commits.
Notes, observations, and other non-structured commentary describing the components pedigree.
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.
5 nested properties
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.
11 nested properties
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.
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.
5 nested properties
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.
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.
6 nested properties
Cryptographic assets occur in several forms. Algorithms and protocols are most commonly implemented in specialized cryptographic libraries. They may, however, also be 'hardcoded' in software components. Certificates and related cryptographic material like keys, tokens, secrets or passwords are other cryptographic assets to be modelled.
Additional properties specific to a cryptographic algorithm.
Properties for cryptographic assets of asset type 'certificate'
Properties for cryptographic assets of asset type: related-crypto-material
Properties specific to cryptographic assets of type: protocol.
The object identifier (OID) of the cryptographic asset.
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).
5 nested properties
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
5 nested properties
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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.
[Deprecated] This will be removed in a future version. Use component or service instead. Information about the automated or manual tool used
The name of the vendor who created the tool
The name of the tool
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
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.
5 nested properties
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
5 nested properties
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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.
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.
7 nested properties
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.
3 nested properties
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 URL to the SWID file.
[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.
6 nested properties
Describes zero or more components in which a component is derived from. This is commonly used to describe forks from existing projects where the forked version contains a ancestor node containing the original component it was forked from. For example, Component A is the original component. Component B is the component being used and documented in the BOM. However, Component B contains a pedigree node with a single ancestor documenting Component A - the original component from which Component B is derived from.
Descendants are the exact opposite of ancestors. This provides a way to document all forks (and their forks) of an original or root component.
Variants describe relations where the relationship between the components is not known. For example, if Component A contains nearly identical code to Component B. They are both related, but it is unclear if one is derived from the other, or if they share a common ancestor.
A list of zero or more commits which provide a trail describing how the component deviates from an ancestor, descendant, or variant.
A list of zero or more patches describing how the component deviates from an ancestor, descendant, or variant. Patches may be complementary to commits or may be used in place of commits.
Notes, observations, and other non-structured commentary describing the components pedigree.
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.
5 nested properties
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.
1 nested properties
Within a call stack, a frame is a discrete unit that encapsulates an execution context, including local variables, parameters, and the return address. As function calls are made, frames are pushed onto the stack, forming an array-like structure that orchestrates the flow of program execution and manages the sequence of function invocations.
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.
11 nested properties
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.
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.
5 nested properties
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.
7 nested properties
The overall approach to learning used by the model for problem solving.
Directly influences the input and/or output. Examples include classification, regression, clustering, etc.
The model architecture family such as transformer network, convolutional neural network, residual neural network, LSTM neural network, etc.
The specific architecture of the model such as GPT-1, ResNet-50, YOLOv3, etc.
The datasets used to train and evaluate the model.
The input format(s) of the model
The output format(s) from the model
A quantitative analysis of the model
2 nested properties
The model performance metrics being reported. Examples may include accuracy, F1 score, precision, top-3 error rates, MSC, etc.
A collection of graphics that represent various measurements.
What considerations should be taken into account regarding the model's construction, training, and application?
7 nested properties
Who are the intended users of the model?
What are the intended use cases of the model?
What are the known technical limitations of the model? E.g. What kind(s) of data should the model be expected not to perform well on? What are the factors that might degrade model performance?
What are the known tradeoffs in accuracy/performance of the model?
What are the ethical risks involved in the application of this model?
Describes various environmental impact metrics.
How does the model affect groups at risk of being systematically disadvantaged? What are the harms and benefits to the various affected groups?
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.
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.
6 nested properties
Cryptographic assets occur in several forms. Algorithms and protocols are most commonly implemented in specialized cryptographic libraries. They may, however, also be 'hardcoded' in software components. Certificates and related cryptographic material like keys, tokens, secrets or passwords are other cryptographic assets to be modelled.
Additional properties specific to a cryptographic algorithm.
11 nested properties
Cryptographic building blocks used in higher-level cryptographic systems and protocols. Primitives represent different cryptographic routines: deterministic random bit generators (drbg, e.g. CTR_DRBG from NIST SP800-90A-r1), message authentication codes (mac, e.g. HMAC-SHA-256), blockciphers (e.g. AES), streamciphers (e.g. Salsa20), signatures (e.g. ECDSA), hash functions (e.g. SHA-256), public-key encryption schemes (pke, e.g. RSA), extended output functions (xof, e.g. SHAKE256), key derivation functions (e.g. pbkdf2), key agreement algorithms (e.g. ECDH), key encapsulation mechanisms (e.g. ML-KEM), authenticated encryption (ae, e.g. AES-GCM) and the combination of multiple algorithms (combiner, e.g. SP800-56Cr2).
An identifier for the parameter set of the cryptographic algorithm. Examples: in AES128, '128' identifies the key length in bits, in SHA256, '256' identifies the digest length, '128' in SHAKE128 identifies its maximum security level in bits, and 'SHA2-128s' identifies a parameter set used in SLH-DSA (FIPS205).
The specific underlying Elliptic Curve (EC) definition employed which is an indicator of the level of security strength, performance and complexity. Absent an authoritative source of curve names, CycloneDX recommends using curve names as defined at [https://neuromancer.sk/std/](https://neuromancer.sk/std/), the source of which can be found at [https://github.com/J08nY/std-curves](https://github.com/J08nY/std-curves).
The target and execution environment in which the algorithm is implemented in.
The target platform for which the algorithm is implemented. The implementation can be 'generic', running on any platform or for a specific platform.
The certification that the implementation of the cryptographic algorithm has received, if any. Certifications include revisions and levels of FIPS 140 or Common Criteria of different Extended Assurance Levels (CC-EAL).
The mode of operation in which the cryptographic algorithm (block cipher) is used.
The padding scheme that is used for the cryptographic algorithm.
The cryptographic functions implemented by the cryptographic algorithm.
The classical security level that a cryptographic algorithm provides (in bits).
The NIST security strength category as defined in https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/evaluation-criteria/security-(evaluation-criteria). A value of 0 indicates that none of the categories are met.
Properties for cryptographic assets of asset type 'certificate'
8 nested properties
The subject name for the certificate
The issuer name for the certificate
The date and time according to ISO-8601 standard from which the certificate is valid
The date and time according to ISO-8601 standard from which the certificate is not valid anymore
Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.
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 format of the certificate
The file extension of the certificate
Properties for cryptographic assets of asset type: related-crypto-material
12 nested properties
The type for the related cryptographic material
The optional unique identifier for the related cryptographic material.
The key state as defined by NIST SP 800-57.
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 date and time (timestamp) when the related cryptographic material was created.
The date and time (timestamp) when the related cryptographic material was activated.
The date and time (timestamp) when the related cryptographic material was updated.
The date and time (timestamp) when the related cryptographic material expires.
The associated value of the cryptographic material.
The size of the cryptographic asset (in bits).
The format of the related cryptographic material (e.g. P8, PEM, DER).
Specifies the mechanism by which the cryptographic asset is secured by
Properties specific to cryptographic assets of type: protocol.
5 nested properties
The concrete protocol type.
The version of the protocol.
A list of cipher suites related to the protocol.
The IKEv2 transform types supported (types 1-4), defined in RFC 7296 section 3.3.2, and additional properties.
The object identifier (OID) of the cryptographic asset.
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 metadata and content for ISO-IEC 19770-2 Software Identification (SWID) Tags.
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.
3 nested properties
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 URL to the SWID file.
Specifies the metadata and content for an attachment.
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.
"3942447fac867ae5cdb3229b658f4d48"
Specifies the details and attributes related to a software license. It can either include a valid SPDX license identifier or a named license, along with additional properties such as license acknowledgment, comprehensive commercial licensing information, and the full text of the license.
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.
3 nested properties
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 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
8 nested properties
License identifiers that may be used to manage licenses and their lifecycle
The individual or organization that grants a license to another individual or organization
The individual or organization for which a license was granted to
The individual or organization that purchased the license
The purchase order identifier the purchaser sent to a supplier or vendor to authorize a purchase
The type of license(s) that was granted to the licensee.
The timestamp indicating when the license was last renewed. For new purchases, this is often the purchase or acquisition date. For non-perpetual licenses or subscriptions, this is the timestamp of when the license was last renewed.
The timestamp indicating when the current license expires (if applicable).
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.
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.
EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one SPDX License Expression)
Specifies an individual commit
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
3 nested properties
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
Specifies an individual commit
3 nested properties
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 text description of the contents of the commit
Specifies an individual patch
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
2 nested properties
Specifies the metadata and content for an attachment.
3 nested properties
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.
Specifies the URL to the diff
A collection of issues the patch resolves
The patch file (or diff) that shows changes. Refer to https://en.wikipedia.org/wiki/Diff
Specifies the metadata and content for an attachment.
3 nested properties
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.
Specifies the URL to the diff
An individual issue that has been resolved.
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
2 nested properties
The name of the source.
The url of the issue documentation as provided by the source
A collection of URL's for reference. Multiple URLs are allowed.
Specifies an individual commit
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
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.
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).
Defines the direct dependencies of a component, service, or the components provided/implemented by a given component. Components or services that do not have their own dependencies must be declared as empty elements within the graph. Components or services that are not represented in the dependency graph may have unknown dependencies. It is recommended that implementations assume this to be opaque and not an indicator of an object being dependency-free. It is recommended to leverage compositions to indicate unknown dependency graphs.
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.
5 nested properties
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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.
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.
11 nested properties
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.
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.
3 nested properties
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.
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
Specifies the flow direction of the data. Direction is relative to the service.
A copyright notice informing users of the underlying claims to copyright ownership in a published work.
The textual content of the copyright.
Provides the ability to document evidence collected through various forms of extraction or analysis.
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.
1 nested properties
Within a call stack, a frame is a discrete unit that encapsulates an execution context, including local variables, parameters, and the return address. As function calls are made, frames are pushed onto the stack, forming an array-like structure that orchestrates the flow of program execution and manages the sequence of function invocations.
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).
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 property. Duplicate names are allowed, each potentially having a different value.
The value of the property.
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.
"major""minor""patch""pre-release""internal"
A note containing the locale and content.
Specifies the metadata and content for an attachment.
3 nested properties
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.
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.
Title and location where advisory information can be obtained. An advisory is a notification of a threat to a component, service, or system.
Location where the advisory can be obtained.
An optional name of the advisory.
Integer representation of a Common Weaknesses Enumerations (CWE). For example 399 (of https://cwe.mitre.org/data/definitions/399.html)
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.
Declares the current state of an occurrence of a vulnerability, after automated or manual analysis.
The rationale of why the impact analysis state was asserted.
Defines the severity or risk ratings of a vulnerability.
The source of vulnerability information. This is often the organization that published the vulnerability.
2 nested properties
The url of the vulnerability documentation as provided by the source.
The name of the source.
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 source of vulnerability information. This is often the organization that published the vulnerability.
The url of the vulnerability documentation as provided by the source.
The name of the source.
Defines a weakness in a component or service that could be exploited or triggered by a threat 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.
2 nested properties
The url of the vulnerability documentation as provided by the source.
The name of the source.
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.
3 nested properties
Precise steps to reproduce the vulnerability.
A description of the environment in which reproduction was possible.
Supporting material that helps in reproducing or understanding how reproduction is possible. This may include screenshots, payloads, and PoC exploit code.
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.
2 nested properties
The organizations credited with vulnerability discovery.
The individuals, not associated with organizations, that are credited with vulnerability discovery.
The tool(s) used to identify, confirm, or score the vulnerability.
An assessment of the impact and exploitability of the vulnerability.
6 nested properties
Declares the current state of an occurrence of a vulnerability, after automated or manual analysis.
The rationale of why the impact analysis state was asserted.
A response to the vulnerability by the manufacturer, supplier, or project responsible for the affected component or service. More than one response is allowed. Responses are strongly encouraged for vulnerabilities where the analysis state is exploitable.
Detailed description of the impact including methods used during assessment. If a vulnerability is not exploitable, this field should include specific details on why the component or service is not impacted by this vulnerability.
The date and time (timestamp) when the analysis was first issued.
The date and time (timestamp) when the analysis was last updated.
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 vulnerability status of a given version or range of versions of a product. The statuses 'affected' and 'unaffected' indicate that the version is affected or unaffected by the vulnerability. The status 'unknown' indicates that it is unknown or unspecified whether the given version is affected. There can be many reasons for an 'unknown' status, including that an investigation has not been undertaken or that a vendor has not disclosed the status.
A single disjunctive version identifier, for a component or service.
"9.0.14""v1.33.7""7.0.0-M1""2.0pre1""1.0.0-beta1""0.8.15"
A version range specified in Package URL Version Range syntax (vers) which is defined at https://github.com/package-url/vers-spec
"vers:cargo/9.0.14""vers:npm/1.2.3|>=2.0.0|<5.0.0""vers:pypi/0.0.0|0.0.1|0.0.2|0.0.3|1.0|2.0pre1""vers:tomee/>=1.0.0-beta1|<=1.7.5|>=7.0.0-M1|<=7.0.7|>=7.1.0|<=7.1.2|>=8.0.0-M1|<=8.0.1""vers:gem/>=2.2.0|!= 2.2.1|<2.3.0"
A version range specified in Package URL Version Range syntax (vers) which is defined at https://github.com/package-url/vers-spec
"vers:cargo/9.0.14""vers:npm/1.2.3|>=2.0.0|<5.0.0""vers:pypi/0.0.0|0.0.1|0.0.2|0.0.3|1.0|2.0pre1""vers:tomee/>=1.0.0-beta1|<=1.7.5|>=7.0.0-M1|<=7.0.7|>=7.1.0|<=7.1.2|>=8.0.0-M1|<=8.0.1""vers:gem/>=2.2.0|!= 2.2.1|<2.3.0"
A comment, note, explanation, or similar textual content which provides additional context to the object(s) being annotated.
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.
4 nested properties
5 nested properties
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.
4 nested properties
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.
33 nested properties
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.
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).
18 nested properties
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.
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).
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).
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.
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.
7 nested properties
The overall approach to learning used by the model for problem solving.
1 nested properties
Learning types describing the learning problem or hybrid learning problem.
Directly influences the input and/or output. Examples include classification, regression, clustering, etc.
The model architecture family such as transformer network, convolutional neural network, residual neural network, LSTM neural network, etc.
The specific architecture of the model such as GPT-1, ResNet-50, YOLOv3, etc.
The datasets used to train and evaluate the model.
The input format(s) of the model
The output format(s) from the model
A quantitative analysis of the model
2 nested properties
The model performance metrics being reported. Examples may include accuracy, F1 score, precision, top-3 error rates, MSC, etc.
What considerations should be taken into account regarding the model's construction, training, and application?
7 nested properties
Who are the intended users of the model?
What are the intended use cases of the model?
What are the known technical limitations of the model? E.g. What kind(s) of data should the model be expected not to perform well on? What are the factors that might degrade model performance?
What are the known tradeoffs in accuracy/performance of the model?
What are the ethical risks involved in the application of this model?
Describes various environmental impact metrics.
2 nested properties
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.
How does the model affect groups at risk of being systematically disadvantaged? What are the harms and benefits to the various affected groups?
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.
3 nested properties
Specifies the metadata and content for an attachment.
3 nested properties
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 URL to where the data can be retrieved.
Provides the ability to document name-value parameters used for configuration.
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.
2 nested properties
A description of this collection of graphics.
A collection of graphics.
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.
3 nested properties
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.
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.
5 nested properties
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
4 nested properties
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.
A collection of graphics that represent various measurements.
A description of this collection of graphics.
A collection of graphics.
The name of the graphic.
Specifies the metadata and content for an attachment.
3 nested properties
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 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.
2 nested properties
The lower bound of the confidence interval.
The upper bound of the confidence interval.
The name of the risk.
Strategy used to address this risk.
Information about the benefits and harms of the model to an identified at risk group.
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.
Data classification tags data according to its type, sensitivity, and value if altered, stolen, or destroyed.
Describes various environmental impact metrics.
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.
Describes energy consumption information incurred for the specified lifecycle activity.
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.
2 nested properties
Quantity of energy.
Unit of energy.
A measure of carbon dioxide (CO2).
2 nested properties
Quantity of carbon dioxide (CO2).
Unit of carbon dioxide (CO2).
A measure of carbon dioxide (CO2).
2 nested properties
Quantity of carbon dioxide (CO2).
Unit 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.
A measure of energy.
Quantity of energy.
Unit of energy.
A measure of carbon dioxide (CO2).
Quantity of carbon dioxide (CO2).
Unit of carbon dioxide (CO2).
Describes the physical provider of energy used for model development or operations.
5 nested properties
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.
7 nested properties
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.
The post office box number.
The postal code.
The street address.
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
The energy source for the energy provider.
A measure of energy.
2 nested properties
Quantity of energy.
Unit 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.
An address used to identify a contactable location.
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.
The post office box number.
The postal code.
The street address.
Describes workflows and resources that captures rules and other aspects of how the associated BOM component or service was formed.
Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.
Transient components that are used in tasks that constitute one or more of this formula's workflows
Transient services that are used in tasks that constitute one or more of this formula's workflows
List of workflows that can be declared to accomplish specific orchestrated goals and independently triggered.
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 specialized orchestration task.
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 unique identifier for the resource instance within its deployment context.
Indicates the types of activities performed by the set of workflow tasks.
The name of the resource instance.
A description of the resource instance.
References to component or service resources that are used to realize the resource instance.
The graph of dependencies between tasks within the workflow.
Represents a resource that can conditionally activate (or fire) tasks based upon associated events and their data.
12 nested properties
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 unique identifier for the resource instance within its deployment context.
The source type of event which caused the trigger to fire.
The name of the resource instance.
A description of the resource instance.
References to component or service resources that are used to realize the resource instance.
Represents something that happened that may trigger a response.
7 nested properties
The unique identifier of the event.
A description of the event.
The date and time (timestamp) when the event was received.
Specifies the metadata and content for an attachment.
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
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 list of conditions used to determine if a trigger should be activated.
The date and time (timestamp) when the trigger was activated.
Represents resources and data brought into a task at runtime by executor or task commands
Represents resources and data output from a task at runtime by executor or task commands
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.
Represents resources and data brought into a task at runtime by executor or task commands
Represents resources and data output from a task at runtime by executor or task commands
The date and time (timestamp) when the task started.
The date and time (timestamp) when the task ended.
A set of named filesystem or data resource shareable by workflow tasks.
A graph of the component runtime topology for workflow's instance.
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.
Describes the inputs, sequence of steps and resources used to accomplish a task and its output.
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 unique identifier for the resource instance within its deployment context.
Indicates the types of activities performed by the set of workflow tasks.
The name of the resource instance.
A description of the resource instance.
References to component or service resources that are used to realize the resource instance.
Represents a resource that can conditionally activate (or fire) tasks based upon associated events and their data.
12 nested properties
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 unique identifier for the resource instance within its deployment context.
The source type of event which caused the trigger to fire.
The name of the resource instance.
A description of the resource instance.
References to component or service resources that are used to realize the resource instance.
Represents something that happened that may trigger a response.
7 nested properties
The unique identifier of the event.
A description of the event.
The date and time (timestamp) when the event was received.
Specifies the metadata and content for an attachment.
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
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 list of conditions used to determine if a trigger should be activated.
The date and time (timestamp) when the trigger was activated.
Represents resources and data brought into a task at runtime by executor or task commands
Represents resources and data output from a task at runtime by executor or task commands
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.
Represents resources and data brought into a task at runtime by executor or task commands
Represents resources and data output from a task at runtime by executor or task commands
The date and time (timestamp) when the task started.
The date and time (timestamp) when the task ended.
A set of named filesystem or data resource shareable by workflow tasks.
A graph of the component runtime topology for task's instance.
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.
Executes specific commands or tools in order to accomplish its owning task as part of a sequence.
A name for the step.
A description of the step.
Ordered list of commands or directives for the step
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 text representation of the executed command.
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 named filesystem or data resource shareable by workflow tasks.
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 unique identifier for the resource instance within its deployment context.
The name of the resource instance.
The names for the workspace as referenced by other workflow tasks. Effectively, a name mapping so other tasks can use their own local name in their steps.
A description of the resource instance.
References to component or service resources that are used to realize the resource instance.
Describes the read-write access control for the workspace relative to the owning resource instance.
A path to a location on disk where the workspace will be available to the associated task's steps.
The name of a domain-specific data type the workspace represents.
Identifies the reference to the request for a specific volume type and parameters.
An identifiable, logical unit of data storage tied to a physical device.
8 nested properties
The unique identifier for the volume instance within its deployment context.
The name of the volume instance
The mode for the volume instance.
The underlying path created from the actual volume.
The allocated size of the volume accessible to the associated workspace. This should include the scalar size as well as IEC standard unit in either decimal or binary form.
Indicates if the volume persists beyond the life of the resource it is associated with.
Indicates if the volume is remotely (i.e., network) attached.
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.
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.
An identifiable, logical unit of data storage tied to a physical device.
The unique identifier for the volume instance within its deployment context.
The name of the volume instance
The mode for the volume instance.
The underlying path created from the actual volume.
The allocated size of the volume accessible to the associated workspace. This should include the scalar size as well as IEC standard unit in either decimal or binary form.
Indicates if the volume persists beyond the life of the resource it is associated with.
Indicates if the volume is remotely (i.e., network) attached.
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.
Represents a resource that can conditionally activate (or fire) tasks based upon associated events and their data.
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 unique identifier for the resource instance within its deployment context.
The source type of event which caused the trigger to fire.
The name of the resource instance.
A description of the resource instance.
References to component or service resources that are used to realize the resource instance.
Represents something that happened that may trigger a response.
7 nested properties
The unique identifier of the event.
A description of the event.
The date and time (timestamp) when the event was received.
Specifies the metadata and content for an attachment.
3 nested properties
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.
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
2 nested properties
References an object by its bom-ref attribute
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 reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
2 nested properties
References an object by its bom-ref attribute
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.
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 list of conditions used to determine if a trigger should be activated.
The date and time (timestamp) when the trigger was activated.
Represents resources and data brought into a task at runtime by executor or task commands
Represents resources and data output from a task at runtime by executor or task commands
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.
Represents something that happened that may trigger a response.
The unique identifier of the event.
A description of the event.
The date and time (timestamp) when the event was received.
Specifies the metadata and content for an attachment.
3 nested properties
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.
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
2 nested properties
References an object by its bom-ref attribute
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.
4 nested properties
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).
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
2 nested properties
References an object by its bom-ref attribute
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.
4 nested properties
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).
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.
Type that represents various input data types and formats.
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
2 nested properties
References an object by its bom-ref attribute
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.
4 nested properties
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).
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
2 nested properties
References an object by its bom-ref attribute
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.
4 nested properties
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).
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
2 nested properties
References an object by its bom-ref attribute
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.
4 nested properties
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).
Inputs that have the form of parameters with names and values.
Inputs that have the form of parameters with names and values.
Specifies the metadata and content for an attachment.
3 nested properties
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.
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.
Describes the type of data output.
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
2 nested properties
References an object by its bom-ref attribute
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.
4 nested properties
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).
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
2 nested properties
References an object by its bom-ref attribute
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.
4 nested properties
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).
A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
2 nested properties
References an object by its bom-ref attribute
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.
4 nested properties
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).
Specifies the metadata and content for an attachment.
3 nested properties
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.
Outputs that have the form of environment variables.
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 reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.
References an object by its bom-ref attribute
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.
4 nested properties
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).
A condition that was used to determine a trigger should be activated.
Describes the set of conditions which cause the trigger to activate.
The logical expression that was evaluated that determined the trigger should be fired.
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 representation of a functional parameter.
The name of the parameter.
The value of the parameter.
The data type of the parameter.
Evidence that substantiates the identity of a component.
The identity field of the component which the evidence describes.
The overall confidence of the evidence from 0 - 1, where 1 is 100% confidence.
The value of the field (cpe, purl, etc) that has been concluded based on the aggregate of all methods (if available).
The methods used to extract and/or analyze the evidence.
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. Tools used for analysis should already be defined in the BOM, either in the metadata/tools, components, or formulation.
A standard may consist of regulations, industry or organizational-specific standards, maturity models, best practices, or any other requirements which can be evaluated against or attested to.
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 standard. This will often be a shortened, single name of the standard.
The version of the standard.
The description of the standard.
The owner of the standard, often the entity responsible for its release.
The list of requirements comprising the standard.
The list of levels associated with the standard. Some standards have different levels of compliance.
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.
Enveloped signature in JSON Signature Format (JSF).
Enveloped signature in JSON Signature Format (JSF).
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.
Cryptographic assets occur in several forms. Algorithms and protocols are most commonly implemented in specialized cryptographic libraries. They may, however, also be 'hardcoded' in software components. Certificates and related cryptographic material like keys, tokens, secrets or passwords are other cryptographic assets to be modelled.
Additional properties specific to a cryptographic algorithm.
11 nested properties
Cryptographic building blocks used in higher-level cryptographic systems and protocols. Primitives represent different cryptographic routines: deterministic random bit generators (drbg, e.g. CTR_DRBG from NIST SP800-90A-r1), message authentication codes (mac, e.g. HMAC-SHA-256), blockciphers (e.g. AES), streamciphers (e.g. Salsa20), signatures (e.g. ECDSA), hash functions (e.g. SHA-256), public-key encryption schemes (pke, e.g. RSA), extended output functions (xof, e.g. SHAKE256), key derivation functions (e.g. pbkdf2), key agreement algorithms (e.g. ECDH), key encapsulation mechanisms (e.g. ML-KEM), authenticated encryption (ae, e.g. AES-GCM) and the combination of multiple algorithms (combiner, e.g. SP800-56Cr2).
An identifier for the parameter set of the cryptographic algorithm. Examples: in AES128, '128' identifies the key length in bits, in SHA256, '256' identifies the digest length, '128' in SHAKE128 identifies its maximum security level in bits, and 'SHA2-128s' identifies a parameter set used in SLH-DSA (FIPS205).
The specific underlying Elliptic Curve (EC) definition employed which is an indicator of the level of security strength, performance and complexity. Absent an authoritative source of curve names, CycloneDX recommends using curve names as defined at [https://neuromancer.sk/std/](https://neuromancer.sk/std/), the source of which can be found at [https://github.com/J08nY/std-curves](https://github.com/J08nY/std-curves).
The target and execution environment in which the algorithm is implemented in.
The target platform for which the algorithm is implemented. The implementation can be 'generic', running on any platform or for a specific platform.
The certification that the implementation of the cryptographic algorithm has received, if any. Certifications include revisions and levels of FIPS 140 or Common Criteria of different Extended Assurance Levels (CC-EAL).
The mode of operation in which the cryptographic algorithm (block cipher) is used.
The padding scheme that is used for the cryptographic algorithm.
The cryptographic functions implemented by the cryptographic algorithm.
The classical security level that a cryptographic algorithm provides (in bits).
The NIST security strength category as defined in https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/evaluation-criteria/security-(evaluation-criteria). A value of 0 indicates that none of the categories are met.
Properties for cryptographic assets of asset type 'certificate'
8 nested properties
The subject name for the certificate
The issuer name for the certificate
The date and time according to ISO-8601 standard from which the certificate is valid
The date and time according to ISO-8601 standard from which the certificate is not valid anymore
Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.
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 format of the certificate
The file extension of the certificate
Properties for cryptographic assets of asset type: related-crypto-material
12 nested properties
The type for the related cryptographic material
The optional unique identifier for the related cryptographic material.
The key state as defined by NIST SP 800-57.
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 date and time (timestamp) when the related cryptographic material was created.
The date and time (timestamp) when the related cryptographic material was activated.
The date and time (timestamp) when the related cryptographic material was updated.
The date and time (timestamp) when the related cryptographic material expires.
The associated value of the cryptographic material.
The size of the cryptographic asset (in bits).
The format of the related cryptographic material (e.g. P8, PEM, DER).
Specifies the mechanism by which the cryptographic asset is secured by
2 nested properties
Specifies the mechanism by which the cryptographic asset is secured by.
Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.
Properties specific to cryptographic assets of type: protocol.
5 nested properties
The concrete protocol type.
The version of the protocol.
A list of cipher suites related to the protocol.
The IKEv2 transform types supported (types 1-4), defined in RFC 7296 section 3.3.2, and additional properties.
The object identifier (OID) of the cryptographic asset.
Object representing a cipher suite
A common name for the cipher suite.
A list of algorithms related to the cipher suite.
A list of common identifiers for the cipher suite.
Specifies the mechanism by which the cryptographic asset is secured by
Specifies the mechanism by which the cryptographic asset is secured by.
Identifier for referable and therefore interlinkable elements. Value SHOULD not start with the BOM-Link intro 'urn:cdx:' to avoid conflicts with BOM-Links.
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.
"json-parser""object-persistence""text-to-image""translation""object-detection"