.cyclonedx-core-java.8.0.0.source-code.bom-1.5.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 Materials Standard
https://cyclonedx.org/
Apache License, Version 2.0
Identifier for referable and therefore interlink-able elements.
Descriptor for an element identified by the attribute "bom-ref" in the same BOM document.
In contrast to `bomLinkElementType`.
Descriptor for another BOM document.
See https://cyclonedx.org/capabilities/bomlink/
Descriptor for an element in another BOM document.
See https://cyclonedx.org/capabilities/bomlink/
The date and time (timestamp) when the BOM was created.
The product lifecycle(s) that this BOM represents.
A pre-defined phase in the product lifecycle.
The name of the lifecycle phase
The description of the lifecycle phase
The tool(s) used in the creation of the BOM.
DEPRECATED. Use tools\components or tools\services instead.
A list of software and hardware components used as tools.
A list of services used as tools.
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 manufacturer, but may also be a distributor or repackager.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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.
BOM produced early in the development lifecycle containing inventory of components and services
that are proposed or planned to be used. The inventory may need to be procured, retrieved,
or resourced prior to use.
BOM consisting of information obtained prior to a build process and may contain source files
and development artifacts and manifests. The inventory may need to be resolved and retrieved
prior to use.
BOM consisting of information obtained during a build process where component inventory is
available for use. The precise versions of resolved components are usually available at this
time as well as the provenance of where the components were retrieved from.
BOM consisting of information obtained after a build process has completed and the resulting
components(s) are available for further analysis. Built components may exist as the result of a
CI/CD process, may have been installed or deployed to a system or device, and may need to be
retrieved or extracted from the system or device.
BOM produced that represents inventory that is running and operational. This may include staging
or production environments and will generally encompass multiple SBOMs describing the applications
and operating system, along with HBOMs describing the hardware that makes up the system. Operations
Bill of Materials (OBOM) can provide full-stack inventory of runtime environments, configurations,
and additional dependencies.
BOM consisting of information observed through network discovery providing point-in-time
enumeration of embedded, on-premise, and cloud-native services such as server applications,
connected devices, microservices, and serverless functions.
BOM containing inventory that will be, or has been retired from operations.
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.
An optional identifier which can be used to reference the object 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.
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
Provides the ability to document external references related to the tool.
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.
The phone number of the contact.
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 object 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.
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 manufacturer, 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, '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
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 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.
Provides the ability to document external references related to the
component or to the project the component describes.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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.
Allows any undeclared elements as long as the elements are placed in a different namespace.
Provides the ability to document evidence collected through various forms of extraction or analysis.
Specifies optional release notes.
A model card describes the intended uses of a machine learning model and potential
limitations, including biases and ethical considerations. Model cards typically contain the
training parameters, which datasets were used to train the model, performance metrics, and other
relevant data useful for ML transparency. This object SHOULD be specified for any component of
type `machine-learning-model` and MUST NOT be specified for other component types.
This object SHOULD be specified for any component of type `data` and MUST NOT be
specified for other component types.
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.
Licensing details describing the licensor/licensee, license type, renewal and
expiration dates, and other important metadata
License identifiers that may be used to manage licenses and
their lifecycle
The individual or organization that grants a license to another
individual or organization
The organization that granted the license
The individual, not associated with an organization,
that granted the license
The individual or organization for which a license was granted to
The organization that was granted the license
The individual, not associated with an organization,
that was granted the license
The individual or organization that purchased the license
The organization that purchased the license
The individual, not associated with an organization,
that purchased the license
The purchase order identifier the purchaser sent to a supplier or
vendor to authorize a purchase
The type of license(s) that was granted to the licensee
The timestamp indicating when the license was last
renewed. For new purchases, this is often the purchase or acquisition date.
For non-perpetual licenses or subscriptions, this is the timestamp of when the
license was last renewed.
The timestamp indicating when the current license
expires (if applicable).
Allows any undeclared elements as long as the elements are placed in a different namespace.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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 license elsewhere in the BOM.
Uniqueness is enforced within all elements and children of the root-level bom element.
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 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 runtime environment which interprets or executes software. This may include
runtimes such as those that execute bytecode or low-code/no-code application platforms.
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.
See also the list of known device properties: https://github.com/CycloneDX/cyclonedx-property-taxonomy/blob/main/cdx/device.md
A special type of software that operates or controls a particular type of device.
Refer to https://en.wikipedia.org/wiki/Device_driver
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.
A model based on training data that can make predictions or decisions without
being explicitly programmed to do so.
A collection of discrete values that convey information.
A license that grants use of software solely for the purpose
of education or research.
A license covering use of software embedded in a specific
piece of hardware.
A Client Access License (CAL) allows client computers to access
services provided by server software.
A Concurrent User license (aka floating license) limits the
number of licenses for a software application and licenses are shared among
a larger number of users.
A license where the core of a computer's processor is assigned
a specific number of points.
A license for which consumption is measured by non-standard
metrics.
A license that covers a defined number of installations on
computers and other types of devices.
A license that grants permission to install and use software
for trial purposes.
A license that grants access to the software to one or more
pre-defined users.
A license that grants access to the software on one or more
pre-defined computers or devices.
An Original Equipment Manufacturer license that is delivered
with hardware, cannot be transferred to other hardware, and is valid for the
life of the hardware.
A license where the software is sold on a one-time basis and
the licensee can use a copy of the software indefinitely.
A license where each installation consumes points per
processor.
A license where the licensee pays a fee to use the software
or service.
A license that grants access to the software or service by a
specified number of users.
Another license type.
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-materials (SBOM, OBOM, HBOM, SaaSBOM, 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 location where a component was published to. This is often the same as "distribution" but may also include specialized publishing processes that act as an intermediary
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
URL to release notes
Specifies a way to contact the maintainer, supplier, or provider in the event of a security incident. Common URIs include links to a disclosure procedure, a mailto (RFC-2368) that specifies an email address, a tel (RFC-3966) that specifies a phone number, or dns (RFC-4501]) that specifies the records containing DNS Security TXT.
A model card describes the intended uses of a machine learning model, potential
limitations, biases, ethical considerations, training parameters, datasets used to train the
model, performance metrics, and other relevant data useful for ML transparency.
A record of events that occurred in a computer system or application, such as problems, errors, or information on current operations.
Parameters or settings that may be used by other components or services.
Information used to substantiate a claim.
Describes how a component or service was manufactured or deployed.
Human or machine-readable statements containing facts, evidence, or testimony
An enumeration of identified weaknesses, threats, and countermeasures, dataflow diagram (DFD), attack tree, and other supporting documentation in human-readable or machine-readable format
The defined assumptions, goals, and capabilities of an adversary.
Identifies and analyzes the potential of future events that may negatively impact individuals, assets, and/or the environment. Risk assessments may also include judgments on the tolerability of each risk.
A Vulnerability Disclosure Report (VDR) which asserts the known and previously unknown vulnerabilities that affect a component, service, or product including the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on a component, service, or product.
A Vulnerability Exploitability eXchange (VEX) which asserts the known vulnerabilities that do not affect a product, product family, or organization, and optionally the ones that do. The VEX should include the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on the product, product family, or organization.
Results from an authorized simulated cyberattack on a component or service, otherwise known as a penetration test
SARIF or proprietary machine or human-readable report for which static analysis has identified code quality, security, and other potential issues with the source code
Dynamic analysis report that has identified issues such as vulnerabilities and misconfigurations
Report generated by analyzing the call stack of a running application
Report generated by Software Composition Analysis (SCA), container analysis, or other forms of component analysis
Report containing a formal assessment of an organization, business unit, or team against a maturity model
Industry, regulatory, or other certification from an accredited (if applicable) certification body
Report or system in which quality metrics can be obtained
Code or configuration that defines and provisions virtualized infrastructure, commonly referred to as Infrastructure as Code (IaC)
Plans of Action and Milestones (POAM) compliment an "attestation" external reference. POAM is defined by NIST as a "document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks and scheduled completion dates for the milestones".
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 are not included with the BOM. They may also establish specific relationships
within or external to the BOM.
Zero or more external references can be defined
The URI (URL or URN) to the external reference. External references
are URIs and therefore can accept any URL scheme including https, mailto, tel, and dns.
External references may also include formally registered URNs such as CycloneDX BOM-Link to
reference CycloneDX BOMs or any object within a BOM. BOM-Link transforms applicable external
references into relationships that can be expressed in a BOM or across BOMs. Refer to:
https://cyclonedx.org/capabilities/bomlink/
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.
An individual issue that has been resolved.
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 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.
Defines the direct dependencies of a component or service. Components or services
that do not have their own dependencies MUST be declared as empty elements within the graph.
Components or services 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 object being dependency-free. It is RECOMMENDED to leverage compositions to
indicate unknown dependency graphs.
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.
The name of the trust zone the service resides in.
DEPRECATED: Specifies the data classification. THIS FIELD IS DEPRECATED AS OF v1.5. Use dataflow\classification instead
Specifies the data classification.
Specifies the data classification.
The URI, URL, or BOM-Link of the components or services the data came in from.
The URI, URL, or BOM-Link of the components or services the data is sent to.
Name for the defined data.
Short description of the data content and usage.
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.
Provides the ability to document external references related to the service.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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.
Allows any undeclared elements as long as the elements are placed in a different namespace.
Specifies optional release notes.
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.
A valid SPDX license expression.
Refer to https://spdx.org/specifications for syntax requirements
An optional identifier which can be used to reference the license elsewhere in the BOM.
Uniqueness is enforced within all elements and children of the root-level bom element.
Evidence that substantiates the identity of a component.
The identity field of the component which the evidence describes.
The overall confidence of the evidence from 0 - 1, where 1 is 100% confidence.
The methods used to extract and/or analyze the evidence.
The technique used in this method of analysis.
The confidence of the evidence from 0 - 1, where 1 is 100% confidence. Confidence is specific to the technique used. Each technique of analysis can have independent confidence.
The value or contents of the evidence.
The object in the BOM identified by its bom-ref. This is often a component or service,
but may be any object type supporting bom-refs. Tools used for analysis should already
be defined in the BOM, either in the metadata/tools, components, or formulation.
Evidence of individual instances of a component spread across multiple locations.
The location or path to where the component was found.
An optional identifier which can be used to reference the occurrence elsewhere
in the BOM. Every bom-ref MUST be unique within the BOM.
Evidence of the components use through the callstack.
A package organizes modules into namespaces, providing a unique namespace for each type it contains.
A module or class that encloses functions/methods and other code.
A block of code designed to perform a particular task.
Optional arguments that are passed to the module or function.
The line number the code that is called resides on.
The column the code that is called resides.
The full path and filename of the module.
The object in the BOM identified by its bom-ref. This is often a component or service,
but may be any object type supporting bom-refs. Tools used for analysis should already
be defined in the BOM, either in the metadata/tools, components, or formulation.
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.
Specifies an aggregate type that describe how complete a relationship is.
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.
Allows any undeclared elements as long as the elements are placed in a different namespace.
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.
Allows any undeclared elements as long as the elements are placed in a different namespace.
The bom-ref identifiers of the vulnerabilities being described.
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 composition elsewhere in the BOM.
Uniqueness is enforced within all elements and children of the root-level bom element.
The relationship is complete. No further relationships including constituent components, services, or dependencies are known to exist.
The relationship is incomplete. Additional relationships exist and may include constituent components, services, or dependencies.
The relationship is incomplete. Only relationships for first-party components, services, or their dependencies are represented.
The relationship is incomplete. Only relationships for third-party components, services, or their dependencies are represented, limited specifically to those that are proprietary.
The relationship is incomplete. Only relationships for third-party components, services, or their dependencies are represented, limited specifically to those that are opensource.
The relationship is incomplete. Only relationships for third-party components, services, or their dependencies are represented.
The relationship is incomplete. Only relationships for third-party components, services, or their dependencies are represented, limited specifically to those that are proprietary.
The relationship is incomplete. Only relationships for third-party components, services, or their dependencies are represented, limited specifically to those that are opensource.
The relationship may be complete or incomplete. This usually signifies a 'best-effort' to obtain constituent components, services, or dependencies but the completeness is inconclusive.
The relationship completeness is not specified.
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 elements may be specified to support release notes in a wide variety of languages.
The ISO-639 (or higher) language code and optional ISO-3166
(or higher) country code. Examples include: "en", "en-US", "fr" and "fr-CA".
Specifies the full content of the release note.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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.
A model card describes the intended uses of a machine learning model and potential limitations, including
biases and ethical considerations. Model cards typically contain the training parameters, which datasets
were used to train the model, performance metrics, and other relevant data useful for ML transparency.
This object SHOULD be specified for any component of type `machine-learning-model` and MUST NOT be specified
for other component types.
Hyper-parameters for construction of the model.
The overall approach to learning used by the model for problem solving.
Learning types describing the learning problem or hybrid learning problem.
Directly influences the input and/or output. Examples include classification,
regression, clustering, etc.
The model architecture family such as transformer network, convolutional neural
network, residual neural network, LSTM neural network, etc.
The specific architecture of the model such as GPT-1, ResNet-50, YOLOv3, etc.
The datasets used to train and evaluate the model.
References a data component by the components bom-ref attribute
The input format(s) of the model
The data format for input to the model. Example formats include string, image, time-series
The output format(s) from the model
The data format for output from the model. Example formats include string, image, time-series
A quantitative analysis of the model
The type of performance metric.
The value of the performance metric.
The name of the slice this metric was computed on. By default, assume
this metric is not sliced.
The confidence interval of the metric.
The lower bound of the confidence interval.
The upper bound of the confidence interval.
A collection of graphics that represent various measurements
A description of this collection of graphics.
A collection of graphics.
The name of the graphic.
The graphic (vector or raster). Base64 encoding MUST be specified for binary images.
What considerations should be taken into account regarding the model's construction, training,
and application?
Who are the intended users of the model?
What are the intended use cases of the model?
What are the known technical limitations of the model? E.g. What kind(s) of data
should the model be expected not to perform well on? What are the factors that might
degrade model performance?
What are the known tradeoffs in accuracy/performance of the model?
What are the ethical (or environmental) risks involved in the application of this model?
The name of the risk
Strategy used to address this risk
How does the model affect groups at risk of being systematically disadvantaged?
What are the harms and benefits to the various affected groups?
The groups or individuals at risk of being systematically disadvantaged by the model.
Expected benefits to the identified groups.
Expected harms to the identified groups.
With respect to the benefits and harms outlined, please
describe any mitigation strategy implemented.
An optional identifier which can be used to reference the model card elsewhere in the BOM.
Every bom-ref MUST be unique within the BOM.
TODO
TODO
TODO
TODO
TODO
The general theme or subject matter of the data being specified.
The name of the dataset.
The contents or references to the contents of the data being described.
An optional way to include textual or encoded data.
The URL to where the data can be retrieved.
Provides the ability to document name-value parameters used for configuration.
Data classification tags data according to its type, sensitivity, and value if altered, stolen, or destroyed.
A description of any sensitive data in a dataset.
A collection of graphics that represent various measurements.
A description of the dataset. Can describe size of dataset, whether it's used for source code,
training, testing, or validation, etc.
An optional identifier which can be used to reference the dataset elsewhere in the BOM.
Every bom-ref MUST be unique within the BOM.
Data custodians are responsible for the safe custody, transport, and storage of data.
Data stewards are responsible for data content, context, and associated business rules.
Data owners are concerned with risk and appropriate access to data.
A collection of graphics that represent various measurements.
A description of this collection of graphics.
A collection of graphics.
The name of the graphic.
The graphic (vector or raster). Base64 encoding MUST be specified for binary images.
Any type of code, code snippet, or data-as-code.
Parameters or settings that may be used by other components.
A collection of data.
Data that can be used to create new instances of what the definition defines.
Any other type of data that does not fit into existing definitions.
References a component or service by 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.
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 an individual property with a name and value.
The name of the property. Duplicate names are allowed, each potentially having a different value.
Defines a weakness in a component or service that could be exploited or triggered by a threat source.
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 identifier that uniquely identifies the vulnerability. For example:
CVE-2021-39182, GHSA-35m5-8cvj-8783, and SNYK-PYTHON-ENROCRYPT-1912876.
The source that published the vulnerability.
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.
A pointer to a vulnerability that is the equivalent of the
vulnerability specified.
The identifier that uniquely identifies the vulnerability. For example:
CVE-2021-39182, GHSA-35m5-8cvj-8783, and SNYK-PYTHON-ENROCRYPT-1912876.
The source that published the vulnerability.
Allows any undeclared elements as long as the elements are placed in a different namespace.
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 information useful in understanding root cause.
Recommendations of how the vulnerability can be remediated or mitigated.
A bypass, usually temporary, of the vulnerability that reduces its likelihood and/or impact. Workarounds often involve changes to configuration or deployments.
Evidence used to reproduce the vulnerability.
Precise steps to reproduce the vulnerability.
A description of the environment in which reproduction was possible.
Supporting material that helps in reproducing or understanding how reproduction is possible. This may include screenshots, payloads, and PoC exploit code.
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.
The date and time (timestamp) when the vulnerability record was rejected (if applicable).
Individuals or organizations credited with the discovery of the vulnerability.
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.
DEPRECATED. Use tools\components or tools\services instead.
A list of software and hardware components used as tools.
A list of services used as tools.
An assessment of the impact and exploitability of the vulnerability.
Declares the current state of an occurrence of a vulnerability, after automated or manual analysis.
The rationale of why the impact analysis state was asserted.
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 date and time (timestamp) when the analysis was first issued.
The date and time (timestamp) when the analysis was last updated.
The components or services that are affected by the vulnerability.
References a component or service by the objects bom-ref.
Zero or more individual versions or range of versions.
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/purl-spec/VERSION-RANGE-SPEC.rst
The vulnerability status for the version or range of versions.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
An optional identifier which can be used to reference the vulnerability elsewhere in the BOM.
Uniqueness is enforced within all elements and children of the root-level bom element.
The name of the source.
For example: NVD, National Vulnerability Database, OSS Index, VulnDB, and GitHub Advisories
The url of the vulnerability documentation as provided by the source.
For example: https://nvd.nist.gov/vuln/detail/CVE-2021-39182
The source that calculated the severity or risk rating of the vulnerability.
The numerical score of the rating.
Textual representation of the severity that corresponds to the numerical score of the rating.
The risk scoring methodology/standard used.
Textual representation of the metric values used to score the vulnerability.
An optional reason for rating the vulnerability as it was.
An optional name of the advisory.
Location where the advisory can be obtained.
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 created the annotation
The person that created the annotation
The tool or component that created the annotation
The service that created the annotation
The objects in the BOM identified by their bom-ref's. This is often components or services, but may be any object type supporting bom-refs.
Allows any undeclared elements as long as the elements are placed in a different namespace.
The organization, individual, component, or service which created the textual content
of the annotation.
The date and time (timestamp) when the annotation was created.
The textual content of the annotation.
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 annotation 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.
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.
Declares the current state of an occurrence of a vulnerability, after automated or manual analysis.
The vulnerability has been remediated.
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).
The vulnerability may be directly or indirectly exploitable.
The vulnerability is being investigated.
The vulnerability is not specific to the component or service and was falsely identified or associated.
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.
The code has been removed or tree-shaked.
The vulnerable code is not invoked at runtime.
Exploitability requires a configurable option to be set/unset.
Exploitability requires a dependency that is not present.
Exploitability requires a certain environment which is not present.
Exploitability requires a compiler flag to be set/unset.
Exploits are prevented at runtime.
Attacks are blocked at physical, logical, or network perimeter.
Preventative measures have been implemented that reduce the likelihood and/or impact of the vulnerability.
Specifies the severity or risk scoring methodology or standard used.
The rating is based on CVSS v2 standard
https://www.first.org/cvss/v2/
The rating is based on CVSS v3.0 standard
https://www.first.org/cvss/v3-0/
The rating is based on CVSS v3.1 standard
https://www.first.org/cvss/v3-1/
The rating is based on CVSS v4.0 standard
https://www.first.org/cvss/v4-0/
The rating is based on OWASP Risk Rating
https://owasp.org/www-community/OWASP_Risk_Rating_Methodology
The rating is based on Stakeholder Specific Vulnerability Categorization (all versions)
https://github.com/CERTCC/SSVC
Use this if the risk scoring methodology is not based on any of the options above
The rationale of why the impact analysis state was asserted.
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.
Describes how a component or service was manufactured or deployed. This is achieved through the use
of formulas, workflows, tasks, and steps, which declare the precise steps to reproduce along with the
observed formulas describing the steps which transpired in the manufacturing process.
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.
Describes workflows and resources that captures rules and other aspects of how the associated
BOM component or service was formed.
Transient components that are used in tasks that constitute one or more of
this formula's workflows
Transient services that are used in tasks that constitute one or more of
this formula's workflows
List of workflows that can be declared to accomplish specific orchestrated goals
and independently triggered.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
An optional identifier which can be used to reference the formula 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.
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 unique identifier for the resource instance within its deployment context.
The name of the resource instance.
The description of the resource instance.
References to component or service resources that are used to realize
the resource instance.
The tasks that comprise the workflow.
The graph of dependencies between tasks within the workflow.
Indicates the types of activities performed by the set of workflow tasks.
The trigger that initiated the task.
The sequence of steps for the task.
Represents resources and data brought into a task at runtime by executor
or task commands
Represents resources and data output from a task at runtime by executor
or task commands
The date and time (timestamp) when the task started.
The date and time (timestamp) when the task ended.
A set of named filesystem or data resource shareable by workflow tasks.
A graph of the component runtime topology for workflow's instance.
A description of the runtime component and service topology. This can describe a partial or
complete topology used to host and execute the task (e.g., hardware, operating systems,
configurations, etc.)
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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 workflow 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.
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.
References an object by its bom-ref attribute
Reference to an externally accessible resource.
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 unique identifier for the resource instance within its deployment context.
The name of the resource instance.
The description of the resource instance.
References to component or service resources that are used to realize the resource instance.
Indicates the types of activities performed by the set of workflow tasks.
The trigger that initiated the task.
The sequence of steps for the task.
Represents resources and data brought into a task at runtime by executor or task commands.
Represents resources and data output from a task at runtime by executor or task commands
The date and time (timestamp) when the task started.
The date and time (timestamp) when the task ended.
A set of named filesystem or data resource shareable by workflow tasks.
A graph of the component runtime topology for task's instance.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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 task 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.
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.
A named filesystem or data resource shareable by workflow tasks.
The unique identifier for the resource instance within its deployment context.
The name of the resource instance.
The names for the workspace as referenced by other workflow tasks. Effectively, a name mapping
so other tasks can use their own local name in their steps.
The description of the resource instance.
References to component or service resources that are used to realize the resource instance.
Describes the read-write access control for the workspace relative to the owning resource instance.
A path to a location on disk where the workspace will be available to the associated task's steps.
The name of a domain-specific data type the workspace represents. This property is for CI/CD
frameworks that are able to provide access to structured, managed data at a more granular level
than a filesystem.
Identifies the reference to the request for a specific volume type and parameters.
Information about the actual volume instance allocated to the workspace.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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 workflow 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.
An identifiable, logical unit of data storage tied to a physical device.
The unique identifier for the volume instance within its deployment context.
The name of the volume instance
The mode for the volume instance.
The underlying path created from the actual volume.
The allocated size of the volume accessible to the associated workspace. This should include
the scalar size as well as IEC standard unit in either decimal or binary form.
Indicates if the volume persists beyond the life of the resource it is associated with.
Indicates if the volume is remotely (i.e., network) attached.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
Executes specific commands or tools in order to accomplish its owning task as part of a sequence.
A name for the step.
A description of the step.
Ordered list of commands or directives for the step
A text representation of the executed command.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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 unique identifier for the resource instance within its deployment context.
The name of the resource instance.
The description of the resource instance.
References to component or service resources that are used to realize the resource instance.
The source type of event which caused the trigger to fire.
The event data that caused the associated trigger to activate.
A condition that was used to determine a trigger should be activated.
Describes the set of conditions which cause the trigger to activate.
The logical expression that was evaluated that determined the trigger should be fired.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
The date and time (timestamp) when the trigger was activated.
Represents resources and data brought into a task at runtime by executor or task commands
Represents resources and data output from a task at runtime by executor or task commands
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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 trigger 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.
The unique identifier of the event.
A description of the event.
The date and time (timestamp) when the event was received.
Encoding of the raw event data.
References the component or service that was the source of the event
References the component or service that was the target of the event
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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.
Type that represents various input data types and formats.
A reference to an independent resource provided as an input to a task by the workflow runtime.
Inputs that have the form of parameters with names and values.
Inputs that have the form of parameters with names and values.
Inputs that have the form of data.
A references to the component or service that provided the input to the task
(e.g., reference to a service with data flow value of inbound)
A reference to the component or service that received or stored the input if not the task
itself (e.g., a local, named storage workspace)
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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.
Represents resources and data output from a task at runtime by executor or task commands
A reference to an independent resource generated as output by the task.
Outputs that have the form of environment variables.
Outputs that have the form of data.
Describes the type of data output.
Component or service that generated or provided the output from the task (e.g., a build tool)
Component or service that received the output from the task
(e.g., reference to an artifactory service with data flow value of outbound)
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
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.
A representation of a functional parameter.
The name of the parameter.
The value of the parameter.
The data type of the parameter.
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.
Provides additional information about a BOM.
A list of software and hardware components.
A list of services. This may include microservices, function-as-a-service, and other types of network or intra-process 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.
Compositions describe constituent parts (including components, services, and dependency relationships) and their completeness. The completeness of vulnerabilities expressed in a BOM may also be described.
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. Property names
of interest to the general public are encouraged to be registered in the
CycloneDX Property Taxonomy - https://github.com/CycloneDX/cyclonedx-property-taxonomy.
Formal registration is OPTIONAL.
Vulnerabilities identified in components or services.
Comments made by people, organizations, or tools about any object with
a bom-ref, such as components, services, vulnerabilities, or the BOM itself. Unlike
inventory information, annotations may contain opinion or commentary from various
stakeholders. Annotations may be inline (with inventory) or externalized via BOM-Link,
and may optionally be signed.
Describes how a component or service was manufactured or deployed. This is
achieved through the use of formulas, workflows, tasks, and steps, which declare the precise
steps to reproduce along with the observed formulas describing the steps which transpired
in the manufacturing process.
Allows any undeclared elements as long as the elements are placed in a different namespace.
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.
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.