CycloneDX Software Bill-of-Material Specification https://cyclonedx.org/ Apache License, Version 2.0 Steve Springett 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. The component that the BOM describes. The organization that manufactured the component that the BOM describes. The organization that supplied the component that the BOM describes. The supplier may often be the manufacture, but may also be a distributor or repackager. Allows any undeclared elements as long as the elements are placed in a different namespace. User-defined attributes may be used on this element as long as they do not have the same name as an existing attribute used by the schema. The name of the organization The URL of the organization. Multiple URLs are allowed. A contact person at the organization. Multiple contacts are allowed. Allows any undeclared elements as long as the elements are placed in a different namespace. User-defined attributes may be used on this element as long as they do not have the same name as an existing attribute used by the schema. Specifies a tool (manual or automated). The vendor of the tool used to create the BOM. The name of the tool used to create the BOM. The version of the tool used to create the BOM. Allows any undeclared elements as long as the elements are placed in a different namespace. User-defined attributes may be used on this element as long as they do not have the same name as an existing attribute used by the schema. The name of the contact The email address of the contact. Multiple email addresses are allowed. The phone number of the contact. Multiple phone numbers are allowed. Allows any undeclared elements as long as the elements are placed in a different namespace. User-defined attributes may be used on this element as long as they do not have the same name as an existing attribute used by the schema. Allows any undeclared elements as long as the elements are placed in a different namespace. User-defined attributes may be used on this element as long as they do not have the same name as an existing attribute used by the schema. The organization that supplied the component. The supplier may often be the manufacture, but may also be a distributor or repackager. 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 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. Specifies a description for the component Specifies the scope of the component. If scope is not specified, 'runtime' scope should be assumed by the consumer of the BOM A valid SPDX license expression. Refer to https://spdx.org/specifications for syntax requirements 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 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 Specifies metadata and content for ISO-IEC 19770-2 Software Identification (SWID) Tags. 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. Provides the ability to document external references related to the component or to the project the component describes. Specifies optional sub-components. 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. Allows any undeclared elements as long as the elements are placed in a different namespace. Allows any undeclared elements as long as the elements are placed in a different namespace. 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 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. An optional identifier which can be used to reference the component elsewhere in the BOM. Uniqueness is enforced within all elements and children of the root-level bom element. User-defined attributes may be used on this element as long as they do not have the same name as an existing attribute used by the schema. 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 optional full text of the attachment The URL to the attachment file. If the attachment is a license or BOM, an externalReference should also be specified for completeness. Allows any undeclared elements as long as the elements are placed in a different namespace. Specifies attributes of the 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 file hash of the component Specifies the algorithm used to create the hash The component is required for runtime The component is optional at runtime. Optional components are components that are not capable of being called due to them not be installed or otherwise accessible by any means. Components that are installed but due to configuration or other restrictions are prohibited from being called must be scoped as 'required'. Components that are excluded provide the ability to document component usage for test and other non-runtime purposes. Excluded components are not reachable within a call graph at runtime. A software application. Refer to https://en.wikipedia.org/wiki/Application_software for information about applications. A software framework. Refer to https://en.wikipedia.org/wiki/Software_framework for information on how frameworks vary slightly from libraries. A software library. Refer to 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. 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 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 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. A special type of software that provides low-level control over a devices hardware. Refer to https://en.wikipedia.org/wiki/Firmware A computer file. Refer to https://en.wikipedia.org/wiki/Computer_file for information about files. Define the format for acceptable CPE URIs. Supports CPE 2.2 and CPE 2.3 formats. Refer to https://nvd.nist.gov/products/cpe for official specification. Specifies the full content of the SWID tag. The URL to the SWID file. Allows any undeclared elements as long as the elements are placed in a different namespace. 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. Defines a string representation of a UUID conforming to RFC 4122. Version Control System Issue or defect tracking system, or an Application Lifecycle Management (ALM) system Website Security advisories Bill-of-material document (CycloneDX, SPDX, SWID, etc) Mailing list or discussion group Social media account Real-time chat platform Documentation, guides, or how-to instructions Community or commercial support Direct or repository download location The URL to the license file. If a license URL has been defined in the license node, it should also be defined as an external reference for completeness Build-system specific meta file (i.e. pom.xml, package.json, .nuspec, etc) URL to an automated build system Use this if no other types accurately describe the purpose of the external reference External references provide a way to document systems, sites, and information that may be relevant but which are not included with the BOM. Zero or more external references can be defined The URL to the external reference An optional comment describing 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. User-defined attributes may be used on this element as long as they do not have the same name as an existing attribute used by the schema. Zero or more commits can be specified. Specifies an individual commit. Allows any undeclared elements as long as the elements are placed in a different namespace. 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. The author who created the changes in the commit The person who committed or pushed the commit The text description of the contents of the commit Allows any undeclared elements as long as the elements are placed in a different namespace. Zero or more patches can be specified. Specifies an individual patch. Allows any undeclared elements as long as the elements are placed in a different namespace. The patch file (or diff) that show changes. Refer to https://en.wikipedia.org/wiki/Diff Allows any undeclared elements as long as the elements are placed in a different namespace. Specifies the purpose for the patch including the resolution of defects, security issues, or new behavior or functionality 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 A patch which dynamically modifies runtime behavior. Refer to https://en.wikipedia.org/wiki/Monkey_patch 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 A patch created by selectively applying commits from other versions or branches of the same software. A fault, flaw, or bug in software A new feature or behavior in software A special type of defect which impacts security Specifies the optional text of the diff Specifies the URL to the diff Allows any undeclared elements as long as the elements are placed in a different namespace. 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. The name of the source. For example "National Vulnerability Database", "NVD", and "Apache" The url of the issue documentation as provided by the source Allows any undeclared elements as long as the elements are placed in a different namespace. Specifies the type of issue 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 Allows any undeclared elements as long as the elements are placed in a different namespace. 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. 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. Allows any undeclared elements as long as the elements are placed in a different namespace. References a component or service by the its bom-ref attribute User-defined attributes may be used on this element as long as they do not have the same name as an existing attribute used by the schema. 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. Allows any undeclared elements as long as the elements are placed in a different namespace. User-defined attributes may be used on this element as long as they do not have the same name as an existing attribute used by the schema. The organization that provides the service. 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 name of the service. This will often be a shortened, single name of the service. The service version. Specifies a description for the service. A service endpoint URI. 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. A valid SPDX license expression. Refer to https://spdx.org/specifications for syntax requirements Provides the ability to document external references related to the service. Specifies optional sub-service. This is not a dependency tree. It provides a way to specify a hierarchical representation of service assemblies, similar to system -> subsystem -> parts assembly in physical supply chains. Allows any undeclared elements as long as the elements are placed in a different namespace. Allows any undeclared elements as long as the elements are placed in a different namespace. An optional identifier which can be used to reference the service elsewhere in the BOM. Uniqueness is enforced within all elements and children of the root-level bom element. User-defined attributes may be used on this element as long as they do not have the same name as an existing attribute used by the schema. Specifies the data classification. Specifies the flow direction of the data. Specifies the flow direction of the data. Valid values are: inbound, outbound, bi-directional, and unknown. 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 additional information about a BOM. Provides the ability to document a list of components. Provides the ability to document a list of external services. Provides the ability to document external references related to the BOM or to the project the BOM describes. Provides the ability to document dependency relationships. Allows any undeclared elements as long as the elements are placed in a different namespace. 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. User-defined attributes may be used on this element as long as they do not have the same name as an existing attribute used by the schema.