CycloneDX Software Bill-of-Material Specification https://cyclonedx.org/ Apache License, Version 2.0 Steve Springett Identifier-DataType for interlinked elements. 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 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 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. Valid choices are: application, framework, library, operating-system, device, or file Refer to the bom:classification documentation for information describing each one 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 license The URL to the license file. If specified, a 'license' 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 license text Specifies the content type of the license text. Defaults to text/plain if not specified. Specifies the optional encoding the license 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 software operating system without regard to deployment model (i.e. installed on physical hardware, virtual machine, container 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 'application' or 'operating-system' (whichever is relevant), describing information about the 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. 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. 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. 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. Provides the ability to document external references related to the BOM or to the project the BOM describes. 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.