CycloneDX
1.3Schema URL
Properties
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.
The version of the CycloneDX specification a BOM is written to (starting at version 1.2)
The version allows component publishers/authors to make changes to existing BOMs to update various aspects of the document such as description or licenses. When a system is presented with multiple BOMs for the same component, the system should use the most recent version of the BOM. The default version is '1' and should be incremented for each version of the BOM that is published. Each version of a component should have a unique BOM and if no changes are made to the BOMs, then each BOM will have a version of '1'.
Every BOM generated should have a unique serial number, even if the contents of the BOM being generated have not changed over time. The process or tool responsible for creating the BOM should create random UUID's for every BOM generated.
8 nested properties
The date and time (timestamp) when the document was created.
The tool(s) used in the creation of the BOM.
The person(s) who created the BOM. Authors are common in BOMs created through manual processes. BOMs created through automated means may not have authors.
23 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 component version. The version should ideally comply with semantic versioning but is not enforced.
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.
3 nested properties
The name of the organization
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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
An optional copyright notice informing users of the underlying claims to copyright ownership in a published work.
DEPRECATED - DO NOT USE. This will be removed in a future version. Specifies a well-formed CPE name. See https://nvd.nist.gov/products/cpe
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 - DO NOT USE. 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 is 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 are 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 complimentary to commits or may be used in place of commits.
Notes, observations, and other non-structured commentary describing the components pedigree.
Provides the ability to document evidence collected through various forms of extraction or analysis.
2 nested properties
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.
3 nested properties
The name of the organization
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
3 nested properties
The name of the organization
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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.
External references provide a way to document systems, sites, and information that may be relevant but which are not included with the BOM.
Provides the ability to document dependency relationships.
Compositions describe constituent parts (including components, services, and dependency relationships) and their completeness.
Definitions
The date and time (timestamp) when the document was created.
The tool(s) used in the creation of the BOM.
The person(s) who created the BOM. Authors are common in BOMs created through manual processes. BOMs created through automated means may not have authors.
23 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 component version. The version should ideally comply with semantic versioning but is not enforced.
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.
3 nested properties
The name of the organization
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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
An optional copyright notice informing users of the underlying claims to copyright ownership in a published work.
DEPRECATED - DO NOT USE. This will be removed in a future version. Specifies a well-formed CPE name. See https://nvd.nist.gov/products/cpe
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 - DO NOT USE. 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 is 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 are 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 complimentary to commits or may be used in place of commits.
Notes, observations, and other non-structured commentary describing the components pedigree.
Provides the ability to document evidence collected through various forms of extraction or analysis.
2 nested properties
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.
3 nested properties
The name of the organization
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
3 nested properties
The name of the organization
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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.
The tool used to create the BOM.
The date and time (timestamp) when the document was created.
The date and time (timestamp) when the document was created.
The date and time (timestamp) when the document was created.
The hashes of the tool (if applicable).
The name of the organization
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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 component version. The version should ideally comply with semantic versioning but is not enforced.
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.
3 nested properties
The name of the organization
The URL of the organization. Multiple URLs are allowed.
A contact at the organization. Multiple contacts are allowed.
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
An optional copyright notice informing users of the underlying claims to copyright ownership in a published work.
DEPRECATED - DO NOT USE. This will be removed in a future version. Specifies a well-formed CPE name. See https://nvd.nist.gov/products/cpe
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
Specifies the content type of the text. Defaults to text/plain if not specified.
Specifies the optional encoding the text is represented in.
The URL to the SWID file.
DEPRECATED - DO NOT USE. 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 is 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 are 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 complimentary to commits or may be used in place of commits.
Notes, observations, and other non-structured commentary describing the components pedigree.
Provides the ability to document evidence collected through various forms of extraction or analysis.
2 nested properties
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.
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
Specifies the content type of the text. Defaults to text/plain if not specified.
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
Specifies the content type of the text. Defaults to text/plain if not specified.
Specifies the optional encoding the text is represented in.
"3942447fac867ae5cdb3229b658f4d48"
A valid SPDX license ID
If SPDX does not define the license used, this field may be used to provide the license name
Specifies the metadata and content for an attachment.
3 nested properties
The attachment data
Specifies the content type of the text. Defaults to text/plain if not specified.
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
4 nested properties
A valid SPDX license ID
If SPDX does not define the license used, this field may be used to provide the license name
Specifies the metadata and content for an attachment.
3 nested properties
The attachment data
Specifies the content type of the text. Defaults to text/plain if not specified.
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
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 show 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
Specifies the content type of the text. Defaults to text/plain if not specified.
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 show changes. Refer to https://en.wikipedia.org/wiki/Diff
Specifies the metadata and content for an attachment.
3 nested properties
The attachment data
Specifies the content type of the text. Defaults to text/plain if not specified.
Specifies the optional encoding the text is represented in.
Specifies the URL to the diff
The patch file (or diff) that show changes. Refer to https://en.wikipedia.org/wiki/Diff
Specifies the type of issue
The identifier of the issue assigned by the source of the issue
The name of the issue
A description of the issue
The source of the issue where it is documented
2 nested properties
The name of the source. For example 'National Vulnerability Database', 'NVD', and 'Apache'
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
Specifies an individual external reference
The URL to the external reference
Specifies the type of external reference. There are built-in types to describe common references. If a type does not exist for the reference being referred to, use the "other" type.
An optional comment describing the external reference
The hashes of the external reference (if applicable).
Defines the direct dependencies of a component. Components that do not have their own dependencies MUST be declared as empty elements within the graph. Components 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 a component being dependency-free.
The name of the service. This will often be a shortened, single name of the service.
3 nested properties
The name of the organization
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.
The service version.
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.
Specifies the data classification.
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.
Provides the ability to document evidence collected through various forms of extraction or analysis.
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 name of the property. Duplicate names are allowed, each potentially having a different value.
The value of the property.