.cyclonedx-core-java.8.0.0.source-code.bom-1.1.xsd Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of cyclonedx-core-java Show documentation
Show all versions of cyclonedx-core-java Show documentation
The CycloneDX core module provides a model representation of the BOM along with utilities to assist in creating, parsing, and validating BOMs.
CycloneDX Software Bill-of-Material Specification
https://cyclonedx.org/
Apache License, Version 2.0
Steve Springett
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.