CycloneDX
1.4Schema 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. This value MUST be "CycloneDX".
The version of the CycloneDX specification a BOM conforms to (starting at version 1.2).
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'.
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 are RECOMMENDED.
8 nested properties
The date and time (timestamp) when the BOM 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.
25 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. Types include:
- application = A software application. Refer to [https://en.wikipedia.org/wiki/Application_software](https://en.wikipedia.org/wiki/Application_software) for information about applications.
- framework = A software framework. Refer to [https://en.wikipedia.org/wiki/Software_framework](https://en.wikipedia.org/wiki/Software_framework) for information on how frameworks vary slightly from libraries.
- library = A software library. Refer to [https://en.wikipedia.org/wiki/Library_(computing)](https://en.wikipedia.org/wiki/Library_(computing)) for information about libraries. All third-party and open source reusable components will likely be a library. If the library also has key features of a framework, then it should be classified as a framework. If not, or is unknown, then specifying library is RECOMMENDED.
- container = A packaging and/or runtime format, not specific to any particular technology, which isolates software inside the container from software outside of a container through virtualization technology. Refer to [https://en.wikipedia.org/wiki/OS-level_virtualization](https://en.wikipedia.org/wiki/OS-level_virtualization)
- operating-system = A software operating system without regard to deployment model (i.e. installed on physical hardware, virtual machine, image, etc) Refer to [https://en.wikipedia.org/wiki/Operating_system](https://en.wikipedia.org/wiki/Operating_system)
- device = A hardware device such as a processor, or chip-set. A hardware device containing firmware SHOULD include a component for the physical hardware itself, and another component of type 'firmware' or 'operating-system' (whichever is relevant), describing information about the software running on the device. See also the list of known device properties.
- firmware = A special type of software that provides low-level control over a devices hardware. Refer to [https://en.wikipedia.org/wiki/Firmware](https://en.wikipedia.org/wiki/Firmware)
- file = A computer file. Refer to [https://en.wikipedia.org/wiki/Computer_file](https://en.wikipedia.org/wiki/Computer_file) for information about files.
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.
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.
The component version. The version should ideally comply with semantic versioning but is not enforced.
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.
A copyright notice informing users of the underlying claims to copyright ownership in a published work.
Specifies a well-formed CPE name that conforms to the CPE 2.2 or 2.3 specification. See [https://nvd.nist.gov/products/cpe](https://nvd.nist.gov/products/cpe)
Specifies the 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)
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 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 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.
External references provide a way to document systems, sites, and information that may be relevant but which are not included with 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.
2 nested properties
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).
One or more tags that may aid in search or retrieval of the release note.
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.
Enveloped signature in JSON Signature Format (JSF).
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. 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 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.
Vulnerabilities identified in components or services.
Enveloped signature in JSON Signature Format (JSF).
Definitions
The date and time (timestamp) when the BOM 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.
25 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. Types include:
- application = A software application. Refer to [https://en.wikipedia.org/wiki/Application_software](https://en.wikipedia.org/wiki/Application_software) for information about applications.
- framework = A software framework. Refer to [https://en.wikipedia.org/wiki/Software_framework](https://en.wikipedia.org/wiki/Software_framework) for information on how frameworks vary slightly from libraries.
- library = A software library. Refer to [https://en.wikipedia.org/wiki/Library_(computing)](https://en.wikipedia.org/wiki/Library_(computing)) for information about libraries. All third-party and open source reusable components will likely be a library. If the library also has key features of a framework, then it should be classified as a framework. If not, or is unknown, then specifying library is RECOMMENDED.
- container = A packaging and/or runtime format, not specific to any particular technology, which isolates software inside the container from software outside of a container through virtualization technology. Refer to [https://en.wikipedia.org/wiki/OS-level_virtualization](https://en.wikipedia.org/wiki/OS-level_virtualization)
- operating-system = A software operating system without regard to deployment model (i.e. installed on physical hardware, virtual machine, image, etc) Refer to [https://en.wikipedia.org/wiki/Operating_system](https://en.wikipedia.org/wiki/Operating_system)
- device = A hardware device such as a processor, or chip-set. A hardware device containing firmware SHOULD include a component for the physical hardware itself, and another component of type 'firmware' or 'operating-system' (whichever is relevant), describing information about the software running on the device. See also the list of known device properties.
- firmware = A special type of software that provides low-level control over a devices hardware. Refer to [https://en.wikipedia.org/wiki/Firmware](https://en.wikipedia.org/wiki/Firmware)
- file = A computer file. Refer to [https://en.wikipedia.org/wiki/Computer_file](https://en.wikipedia.org/wiki/Computer_file) for information about files.
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.
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.
The component version. The version should ideally comply with semantic versioning but is not enforced.
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.
A copyright notice informing users of the underlying claims to copyright ownership in a published work.
Specifies a well-formed CPE name that conforms to the CPE 2.2 or 2.3 specification. See [https://nvd.nist.gov/products/cpe](https://nvd.nist.gov/products/cpe)
Specifies the 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)
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 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 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.
External references provide a way to document systems, sites, and information that may be relevant but which are not included with 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.
2 nested properties
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).
One or more tags that may aid in search or retrieval of the release note.
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.
Enveloped signature in JSON Signature Format (JSF).
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. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is OPTIONAL.
Information about the automated or manual tool used
The name of the vendor who created the tool
The name of the tool
The version 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 which are not included with the BOM.
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. Types include:
- application = A software application. Refer to [https://en.wikipedia.org/wiki/Application_software](https://en.wikipedia.org/wiki/Application_software) for information about applications.
- framework = A software framework. Refer to [https://en.wikipedia.org/wiki/Software_framework](https://en.wikipedia.org/wiki/Software_framework) for information on how frameworks vary slightly from libraries.
- library = A software library. Refer to [https://en.wikipedia.org/wiki/Library_(computing)](https://en.wikipedia.org/wiki/Library_(computing)) for information about libraries. All third-party and open source reusable components will likely be a library. If the library also has key features of a framework, then it should be classified as a framework. If not, or is unknown, then specifying library is RECOMMENDED.
- container = A packaging and/or runtime format, not specific to any particular technology, which isolates software inside the container from software outside of a container through virtualization technology. Refer to [https://en.wikipedia.org/wiki/OS-level_virtualization](https://en.wikipedia.org/wiki/OS-level_virtualization)
- operating-system = A software operating system without regard to deployment model (i.e. installed on physical hardware, virtual machine, image, etc) Refer to [https://en.wikipedia.org/wiki/Operating_system](https://en.wikipedia.org/wiki/Operating_system)
- device = A hardware device such as a processor, or chip-set. A hardware device containing firmware SHOULD include a component for the physical hardware itself, and another component of type 'firmware' or 'operating-system' (whichever is relevant), describing information about the software running on the device. See also the list of known device properties.
- firmware = A special type of software that provides low-level control over a devices hardware. Refer to [https://en.wikipedia.org/wiki/Firmware](https://en.wikipedia.org/wiki/Firmware)
- file = A computer file. Refer to [https://en.wikipedia.org/wiki/Computer_file](https://en.wikipedia.org/wiki/Computer_file) for information about files.
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.
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.
The component version. The version should ideally comply with semantic versioning but is not enforced.
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.
A copyright notice informing users of the underlying claims to copyright ownership in a published work.
Specifies a well-formed CPE name that conforms to the CPE 2.2 or 2.3 specification. See [https://nvd.nist.gov/products/cpe](https://nvd.nist.gov/products/cpe)
Specifies the 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)
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 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 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 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.
External references provide a way to document systems, sites, and information that may be relevant but which are not included with 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.
2 nested properties
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).
One or more tags that may aid in search or retrieval of the release note.
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.
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 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. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.
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. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.
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. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.
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.
- unofficial = A patch which is not developed by the creators or maintainers of the software being patched. Refer to [https://en.wikipedia.org/wiki/Unofficial_patch](https://en.wikipedia.org/wiki/Unofficial_patch)
- monkey = A patch which dynamically modifies runtime behavior. Refer to [https://en.wikipedia.org/wiki/Monkey_patch](https://en.wikipedia.org/wiki/Monkey_patch)
- backport = A patch which takes code from a newer version of software and applies it to older versions of the same software. Refer to [https://en.wikipedia.org/wiki/Backporting](https://en.wikipedia.org/wiki/Backporting)
- cherry-pick = A patch created by selectively applying commits from other versions or branches of the same software.
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. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.
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. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.
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
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. 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.
External references provide a way to document systems, sites, and information that may be relevant but which are not included with 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).
One or more tags that may aid in search or retrieval of the release note.
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.
Enveloped signature in JSON Signature Format (JSF).
Specifies the flow direction of the data. Direction is relative to the service. Inbound flow states that data enters the service. Outbound flow states that data leaves the service. Bi-directional states that data flows both ways, and unknown states that the direction is not known.
Data classification tags data according to its type, sensitivity, and value if altered, stolen, or destroyed.
Specifies the flow direction of the data. Direction is relative to the service. Inbound flow states that data enters the service. Outbound flow states that data leaves the service. Bi-directional states that data flows both ways, and unknown states that the direction is not known.
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.
Enveloped signature in JSON Signature Format (JSF).
The name of the property. Duplicate names are allowed, each potentially having a different value.
The value of the property.
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 content type of the text. Defaults to text/plain if not specified.
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).
One or more tags that may aid in search or retrieval of the release note.
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.
- CVSSv2 - Common Vulnerability Scoring System v2
- CVSSv3 - Common Vulnerability Scoring System v3
- CVSSv31 - Common Vulnerability Scoring System v3.1
- OWASP - OWASP Risk Rating Methodology
Declares the current state of an occurrence of a vulnerability, after automated or manual analysis.
- resolved = the vulnerability has been remediated.
- resolved_with_pedigree = the vulnerability has been remediated and evidence of the changes are provided in the affected components pedigree containing verifiable commit history and/or diff(s).
- exploitable = the vulnerability may be directly or indirectly exploitable.
- in_triage = the vulnerability is being investigated.
- false_positive = the vulnerability is not specific to the component or service and was falsely identified or associated.
- not_affected = the component or service is not affected by the vulnerability. Justification should be specified for all not_affected cases.
The rationale of why the impact analysis state was asserted.
- code_not_present = the code has been removed or tree-shaked.
- code_not_reachable = the vulnerable code is not invoked at runtime.
- requires_configuration = exploitability requires a configurable option to be set/unset.
- requires_dependency = exploitability requires a dependency that is not present.
- requires_environment = exploitability requires a certain environment which is not present.
- protected_by_compiler = exploitability requires a compiler flag to be set/unset.
- protected_at_runtime = exploits are prevented at runtime.
- protected_at_perimeter = attacks are blocked at physical, logical, or network perimeter.
- protected_by_mitigating_control = preventative measures have been implemented that reduce the likelihood and/or impact of the vulnerability.
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.
- CVSSv2 - Common Vulnerability Scoring System v2
- CVSSv3 - Common Vulnerability Scoring System v3
- CVSSv31 - Common Vulnerability Scoring System v3.1
- OWASP - OWASP Risk Rating Methodology
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 an component or service that could be exploited or triggered by a threat source.
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
List of Common Weaknesses Enumerations (CWEs) codes that describes this vulnerability. For example 399 (of https://cwe.mitre.org/data/definitions/399.html)
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 examples, proof-of-concepts, and other information useful in understanding root cause.
Recommendations of how the vulnerability can be remediated or mitigated.
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.
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.
4 nested properties
Declares the current state of an occurrence of a vulnerability, after automated or manual analysis.
- resolved = the vulnerability has been remediated.
- resolved_with_pedigree = the vulnerability has been remediated and evidence of the changes are provided in the affected components pedigree containing verifiable commit history and/or diff(s).
- exploitable = the vulnerability may be directly or indirectly exploitable.
- in_triage = the vulnerability is being investigated.
- false_positive = the vulnerability is not specific to the component or service and was falsely identified or associated.
- not_affected = the component or service is not affected by the vulnerability. Justification should be specified for all not_affected cases.
The rationale of why the impact analysis state was asserted.
- code_not_present = the code has been removed or tree-shaked.
- code_not_reachable = the vulnerable code is not invoked at runtime.
- requires_configuration = exploitability requires a configurable option to be set/unset.
- requires_dependency = exploitability requires a dependency that is not present.
- requires_environment = exploitability requires a certain environment which is not present.
- protected_by_compiler = exploitability requires a compiler flag to be set/unset.
- protected_at_runtime = exploits are prevented at runtime.
- protected_at_perimeter = attacks are blocked at physical, logical, or network perimeter.
- protected_by_mitigating_control = preventative measures have been implemented that reduce the likelihood and/or impact of the vulnerability.
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 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 version of a component or service.
A version range specified in Package URL Version Range syntax (vers) which is defined at https://github.com/package-url/vers-spec
Enveloped signature in JSON Signature Format (JSF).