.cyclonedx-core-java.10.0.0.source-code.bom-1.6.xsd Maven / Gradle / Ivy
CycloneDX 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`.
=2.0.0|<5.0.0"
- "vers:pypi/0.0.0|0.0.1|0.0.2|0.0.3|1.0|2.0pre1"
- "vers:tomee/>=1.0.0-beta1|<=1.7.5|>=7.0.0-M1|<=7.0.7|>=7.1.0|<=7.1.2|>=8.0.0-M1|<=8.0.1"
- "vers:gem/>=2.2.0|!= 2.2.1|<2.3.0"
]]>
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.
Lifecycles communicate the stage(s) in which data in the BOM was captured. Different types of data may be available at various phases of a lifecycle, such as the Software Development Lifecycle (SDLC), IT Asset Management (ITAM), and Software Asset Management (SAM). Thus, a BOM may include data specific to or only obtainable in a given lifecycle.
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 have './manufacturer' instead.
The component that the BOM describes.
The organization that created the BOM.
Manufacturer is common in BOMs created through automated processes. BOMs created through manual means may have './authors' instead.
DEPRECATED - DO NOT USE. This will be removed in a future version. Use the `./component/manufacturer` instead.
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.
The license information for the BOM document.
This may be different from the license(s) of the component(s) that the BOM 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.
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 physical address (location) of the organization.
The URL of the organization. Multiple URLs are allowed.
Example: https://example.com
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 organization that created the component.
Manufacturer is common in components created through automated processes. Components created through manual means may have './authors' instead.
The person(s) who created the component.
Authors are common in components created through manual processes. Components created through automated means may have `./manufacturer` instead.
DEPRECATED - DO NOT USE. This will be removed in a future version. Use `./authors` or `./manufacturer` instead.
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.
The hashes of the component.
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 the OmniBOR Artifact ID. The OmniBOR, if specified, must be valid and conform
to the specification defined at: https://www.iana.org/assignments/uri-schemes/prov/gitoid
Specifies the Software Heritage persistent identifier (SWHID). The SWHID, if specified, must
be valid and conform to the specification defined at:
https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html
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.
Cryptographic assets have properties that uniquely define them and that make them actionable
for further reasoning. As an example, it makes a difference if one knows the algorithm family
(e.g. AES) or the specific variant or instantiation (e.g. AES-128-GCM). This is because the
security level and the algorithm primitive (authenticated encryption) is only defined by the
definition of the algorithm variant. The presence of a weak cryptographic algorithm like SHA1
vs. HMAC-SHA1 also makes a difference.
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.
Specifies the details and attributes related to a software license.
It can either include a valid SPDX license identifier or a named license, along with additional
properties such as license acknowledgment, comprehensive commercial licensing information, and
the full text of the license.
A valid SPDX license identifier. If specified, this value must be one of the enumeration of valid SPDX license identifiers defined in the spdx.schema.json (or spdx.xml) subschema which is synchronized with the official SPDX license list.
The name of the license. This may include the name of a commercial or proprietary license or an open source license that may not be defined by SPDX.
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.
Declared licenses and concluded licenses represent two different stages in the
licensing process within software development. Declared licenses refer to the
initial intention of the software authors regarding the licensing terms under
which their code is released. On the other hand, concluded licenses are the
result of a comprehensive analysis of the project's codebase to identify and
confirm the actual licenses of the components used, which may differ from the
initially declared licenses. While declared licenses provide an upfront indication
of the licensing intentions, concluded licenses offer a more thorough understanding
of the actual licensing within a project, facilitating proper compliance and risk
management. Observed licenses are defined in `evidence.licenses`. Observed licenses
form the evidence necessary to substantiate a concluded license.
The attachment data. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.
Specifies the format and nature of the data being attached, helping systems correctly
interpret and process the content. Common content type examples include `application/json`
for JSON data and `text/plain` for plan text documents.
RFC 2045 section 5.1 outlines the structure and use of content types. For a comprehensive
list of registered content types, refer to the IANA media types registry at
https://www.iana.org/assignments/media-types/media-types.xhtml.
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 cryptographic asset including algorithms, protocols, certificates, keys, tokens, and secrets.
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
The location where the source code distributable can be obtained. This is often an archive format such as zip or tgz. The source-distribution type complements use of the version control (vcs) type.
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.
Example: https://www.apache.org/licenses/LICENSE-2.0.txt
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 (POA&M) complement an "attestation" external reference. POA&M 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".
An e-signature is commonly a scanned representation of a written signature or a stylized script of the persons name.
A signature that leverages cryptography, typically public/private key pairs, which provides strong authenticity verification.
Document that complies with RFC-9116 (A File Format to Aid in Security Vulnerability Disclosure)
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
A collection of URL's for reference. Multiple URLs are allowed.
Example: "https://example.com"
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 complementary 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.
The component or service that is a dependency of this dependency object.
The component or service that define a given specification or standard, which is provided or implemented by this dependency object.
For example, a cryptographic library which implements a cryptographic algorithm. A component which implements another component does not imply that the implementation is in use.
References a component or service by its bom-ref attribute
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.
The endpoint URIs of the service. Multiple endpoints are allowed.
Example: "https://example.com/api/v1/ticker"
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.
Specifies information about the data including the directional flow of data and the data classification.
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.
Data that enters a service.
Data that exits a service.
Data flows in and out of the service.
The directional flow of data is not known.
A valid SPDX license expression.
Refer to https://spdx.org/specifications for syntax requirements
Example values:
- Apache-2.0 AND (MIT OR GPL-2.0-only)
- GPL-3.0-only WITH Classpath-exception-2.0
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.
Declared licenses and concluded licenses represent two different stages in the
licensing process within software development. Declared licenses refer to the
initial intention of the software authors regarding the licensing terms under
which their code is released. On the other hand, concluded licenses are the
result of a comprehensive analysis of the project's codebase to identify and
confirm the actual licenses of the components used, which may differ from the
initially declared licenses. While declared licenses provide an upfront indication
of the licensing intentions, concluded licenses offer a more thorough understanding
of the actual licensing within a project, facilitating proper compliance and risk
management. Observed licenses are defined in `evidence.licenses`. Observed licenses
form the evidence necessary to substantiate a concluded license.
Declared licenses represent the initial intentions of authors regarding
the licensing terms of their code.
Concluded licenses are verified and confirmed.
Examines the source code without executing it.
Examines a compiled binary through reverse engineering, typically via disassembly or bytecode reversal.
Examines a package management system such as those used for building software or installing software.
Examines the Abstract Syntax Tree (AST) of source code or a compiled binary.
Evaluates the cryptographic hash of a component against a set of pre-computed hashes of identified software.
Examines the call stack of running applications by intercepting and monitoring application logic without the need to modify the application.
Evaluates a running application.
Evaluates file name of a component against a set of known file names of identified software.
A testimony to the accuracy of the identify of a component made by an individual or entity.
Any other technique.
Evidence that substantiates the identity of a component. The identify may be an
object or an array of identity objects. Support for specifying identity as a single object was
introduced in CycloneDX v1.5. "unbounded" was introduced in v1.6. It is recommended that all
implementations are aware of "unbounded".
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 value of the field (cpe, purl, etc) that has been concluded based on the aggregate of all methods (if available).
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.
The line number where the component was found.
The offset where the component was found.
The symbol name that was found associated with the component.
Any additional context of the detected component (e.g. a code snippet).
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.
Within a call stack, a frame is a discrete unit that encapsulates an execution context, including local variables, parameters, and the return address. As function calls are made, frames are pushed onto the stack, forming an array-like structure that orchestrates the flow of program execution and manages the sequence of function invocations.
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.
opyright evidence captures intellectual property assertions, providing evidence of possible ownership and legal protection.
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).
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
Inline Data Information
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 risks involved in the application of this model?
The name of the risk
Strategy used to address this risk
What are the various environmental impacts the corresponding machine learning model has exhibited across its lifecycle?
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.
Describes various environmental impact metrics.
Describes energy consumption information incurred for one or more component lifecycle activities.
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.
Describes energy consumption information incurred for the specified lifecycle activity.
The type of activity that is part of a machine learning model development or operational lifecycle.
model design including problem framing, goal definition and algorithm selection.
model data acquisition including search, selection and transfer.
model data preparation including data cleaning, labeling and conversion.
model building, training and generalized tuning.
refining a trained model to produce desired outputs for a given problem space.
model validation including model output evaluation and testing.
explicit model deployment to a target hosting infrastructure.
generating an output response from a hosted model from a set of inputs.
a lifecycle activity type whose description does not match currently defined values.
The provider(s) of the energy consumed by the associated model development lifecycle activity.
The total energy cost associated with the model lifecycle activity.
The CO2 cost (debit) equivalent to the total energy cost.
The CO2 offset (credit) for the CO2 equivalent cost.
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 measure of energy.
Quantity of energy.
Unit of energy.
kilowatt-hour (kWh) is the energy delivered by one kilowatt (kW) of power for one hour (h).
A measure of carbon dioxide (CO2).
Quantity of carbon dioxide (CO2).
Unit of carbon dioxide (CO2).
Tonnes (t) of carbon dioxide (CO2) equivalent (eq).
Describes the physical provider of energy used for model development or operations.
A description of the energy provider.
The organization of the energy provider.
The energy source for the energy provider.
Energy produced by types of coal.
Petroleum products (primarily crude oil and its derivative fuel oils).
Hydrocarbon gas liquids (HGL) that occur as gases at atmospheric pressure and as liquids under higher pressures including Natural gas (C5H12 and heavier), Ethane (C2H6), Propane (C3H8), etc.
Energy produced from the cores of atoms (i.e., through nuclear fission or fusion).
Energy produced from moving air.
Energy produced from the sun (i.e., solar radiation).
Energy produced from heat within the earth.
Energy produced from flowing water.
Liquid fuels produced from biomass feedstocks (i.e., organic materials such as plants or animals).
The energy source is unknown.
An energy source that is not listed.
The energy provided by the energy source for an associated activity.
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.
An optional identifier which can be used to reference the energy provider elsewhere in the BOM.
Uniqueness is enforced within all elements and children of the root-level bom element.
An address used to identify a contactable location.
The country name or the two-letter ISO 3166-1 country code.
The region or state in the country. For example, Texas.
The locality or city within the country. For example, Austin.
The post office box number. For example, 901.
The postal code. For example, 78758.
The street address. For example, 100 Main Street.
An optional identifier which can be used to reference the address elsewhere in the BOM.
Uniqueness is enforced within all elements and children of the root-level bom element.
Supervised machine learning involves training an algorithm on labeled
data to predict or classify new data based on the patterns learned from
the labeled examples.
Unsupervised machine learning involves training algorithms on unlabeled
data to discover patterns, structures, or relationships without explicit
guidance, allowing the model to identify inherent structures or clusters
within the data.
Reinforcement learning is a type of machine learning where an agent learns
to make decisions by interacting with an environment to maximize cumulative
rewards, through trial and error.
Semi-supervised machine learning utilizes a combination of labeled and
unlabeled data during training to improve model performance, leveraging
the benefits of both supervised and unsupervised learning techniques.
Self-supervised machine learning involves training models to predict parts
of the input data from other parts of the same data, without requiring
external labels, enabling learning from large amounts of unlabeled data.
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.
Critical severity
High severity
Medium severity
Low severity
Informational warning.
None
The severity is not known
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.
Common Vulnerability Scoring System v2.0 standard as defined at https://www.first.org/cvss/v2/
Common Vulnerability Scoring System v3.0 standard as defined at https://www.first.org/cvss/v3-0/
Common Vulnerability Scoring System v3.1 standard as defined at https://www.first.org/cvss/v3-1/
Common Vulnerability Scoring System v4.0 standard as defined at https://www.first.org/cvss/v4-0/
OWASP Risk Rating as defined at https://owasp.org/www-community/OWASP_Risk_Rating_Methodology
Stakeholder Specific Vulnerability Categorization as defined at https://github.com/CERTCC/SSVC
Another severity or risk scoring methodology
The rationale of why the impact analysis state was asserted.
Can not fix
Will not fix
Update to a different revision or release
Revert to a previous revision or release
There is a workaround available
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.
The version is affected by the vulnerability.
The version is not affected by the vulnerability.
It is unknown (or unspecified) whether the given version is affected.
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.
A task that copies software or data used to accomplish other tasks in the workflow.
A task that clones a software repository into the workflow in order to retrieve its source code or data for use in a build step.
A task that checks source code for programmatic and stylistic errors.
A task that performs a scan against source code, or built or deployed components and services. Scans are typically run to gather or test for security vulnerabilities or policy compliance.
A task that merges changes or fixes into source code prior to a build step in the workflow.
A task that builds the source code, dependencies and/or data into an artifact that can be deployed to and executed on target systems.
A task that verifies the functionality of a component or service.
A task that delivers a built artifact to one or more target repositories or storage systems.
A task that deploys a built artifact for execution on one or more target systems.
A task that releases a built, versioned artifact to a target repository or distribution system.
A task that cleans unnecessary tools, build artifacts and/or data from workflow storage.
A workflow task that does not match current task type definitions.
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 list of conditions used to determine if a trigger should be activated.
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.
Cryptographic assets have properties that uniquely define them and that make them actionable for
further reasoning. As an example, it makes a difference if one knows the algorithm family (e.g. AES)
or the specific variant or instantiation (e.g. AES-128-GCM). This is because the security level and the
algorithm primitive (authenticated encryption) is only defined by the definition of the algorithm variant.
The presence of a weak cryptographic algorithm like SHA1 vs. HMAC-SHA1 also makes a difference.
Cryptographic assets occur in several forms. Algorithms and protocols are most commonly
implemented in specialized cryptographic libraries. They may however also be 'hardcoded'
in software components. Certificates and related cryptographic material like keys, tokens,
secrets or passwords are other cryptographic assets to be modelled.
Mathematical function commonly used for data encryption, authentication, and
digital signatures.
An electronic document that is used to provide the identity or validate a public key.
A set of rules and guidelines that govern the behavior and communication with each other.
Other cryptographic assets that are related to algorithms, certificate, and protocols
such as keys and tokens.
Additional properties specific to a cryptographic algorithm.
Cryptographic building blocks used in higher-level cryptographic systems and
protocols. Primitives represent different cryptographic routines: deterministic
random bit generators (drbg, e.g. CTR_DRBG from NIST SP800-90A-r1), message
authentication codes (mac, e.g. HMAC-SHA-256), blockciphers (e.g. AES),
streamciphers (e.g. Salsa20), signatures (e.g. ECDSA), hash functions (e.g. SHA-256),
public-key encryption schemes (pke, e.g. RSA), extended output functions
(xof, e.g. SHAKE256), key derivation functions (e.g. pbkdf2), key agreement
algorithms (e.g. ECDH), key encapsulation mechanisms (e.g. ML-KEM), authenticated
encryption (ae, e.g. AES-GCM) and the combination of multiple algorithms
(combiner, e.g. SP800-56Cr2).
Deterministic Random Bit Generator (DRBG) is a type of pseudorandom
number generator designed to produce a sequence of bits from an initial
seed value. DRBGs are commonly used in cryptographic applications where
reproducibility of random values is important.
In cryptography, a Message Authentication Code (MAC) is information
used for authenticating and integrity-checking a message.
A block cipher is a symmetric key algorithm that operates on fixed-size
blocks of data. It encrypts or decrypts the data in block units,
providing confidentiality. Block ciphers are widely used in various
cryptographic modes and protocols for secure data transmission.
A stream cipher is a symmetric key cipher where plaintext digits are
combined with a pseudorandom cipher digit stream (keystream).
In cryptography, a signature is a digital representation of a message
or data that proves its origin, identity, and integrity. Digital
signatures are generated using cryptographic algorithms and are widely
used for authentication and verification in secure communication.
A hash function is a mathematical algorithm that takes an input
(or 'message') and produces a fixed-size string of characters, which is
typically a hash value. Hash functions are commonly used in various
cryptographic applications, including data integrity verification and
password hashing.
Public Key Encryption (PKE) is a type of encryption that uses a pair of
public and private keys for secure communication. The public key is used
for encryption, while the private key is used for decryption. PKE is a
fundamental component of public-key cryptography.
An XOF is an extendable output function that can take arbitrary input
and creates a stream of output, up to a limit determined by the size of
the internal state of the hash function that underlies the XOF.
A Key Derivation Function (KDF) derives key material from another source
of entropy while preserving the entropy of the input.
In cryptography, a key-agreement is a protocol whereby two or more
parties agree on a cryptographic key in such a way that both influence
the outcome.
A Key Encapsulation Mechanism (KEM) algorithm is a mechanism for
transporting random keying material to a recipient using the recipient's
public key.
Authenticated Encryption (AE) is a cryptographic process that provides
both confidentiality and data integrity. It ensures that the encrypted
data has not been tampered with and comes from a legitimate source.
AE is commonly used in secure communication protocols.
A combiner aggregates many candidates for a cryptographic primitive and
generates a new candidate for the same primitive.
Another primitive type.
The primitive is not known.
An identifier for the parameter set of the cryptographic algorithm. Examples: in
AES128, '128' identifies the key length in bits, in SHA256, '256' identifies the
digest length, '128' in SHAKE128 identifies its maximum security level in bits, and
'SHA2-128s' identifies a parameter set used in SLH-DSA (FIPS205).
The specific underlying Elliptic Curve (EC) definition employed which is an indicator
of the level of security strength, performance and complexity. Absent an
authoritative source of curve names, CycloneDX recommends use of curve names as
defined at https://neuromancer.sk/std/, the source from which can be found at
https://github.com/J08nY/std-curves.
The target and execution environment in which the algorithm is implemented in.
A software implementation running in plain unencrypted RAM.
A software implementation running in encrypted RAM.
A software implementation running in a trusted execution environment.
A hardware implementation.
Another implementation environment.
The execution environment is not known.
The target platform for which the algorithm is implemented. The implementation can
be 'generic', running on any platform or for a specific platform.
The certification that the implementation of the cryptographic algorithm has
received, if any. Certifications include revisions and levels of FIPS 140 or
Common Criteria of different Extended Assurance Levels (CC-EAL).
No certification obtained
FIPS 140-1 Level 1
FIPS 140-1 Level 2
FIPS 140-1 Level 3
FIPS 140-1 Level 4
FIPS 140-2 Level 1
FIPS 140-2 Level 2
FIPS 140-2 Level 3
FIPS 140-2 Level 4
FIPS 140-3 Level 1
FIPS 140-3 Level 2
FIPS 140-3 Level 3
FIPS 140-3 Level 4
Common Criteria - Evaluation Assurance Level 1
Common Criteria - Evaluation Assurance Level 1 (Augmented)
Common Criteria - Evaluation Assurance Level 2
Common Criteria - Evaluation Assurance Level 2 (Augmented)
Common Criteria - Evaluation Assurance Level 3
Common Criteria - Evaluation Assurance Level 3 (Augmented)
Common Criteria - Evaluation Assurance Level 4
Common Criteria - Evaluation Assurance Level 4 (Augmented)
Common Criteria - Evaluation Assurance Level 5
Common Criteria - Evaluation Assurance Level 5 (Augmented)
Common Criteria - Evaluation Assurance Level 6
Common Criteria - Evaluation Assurance Level 6 (Augmented)
Common Criteria - Evaluation Assurance Level 7
Common Criteria - Evaluation Assurance Level 7 (Augmented)
Another certification
The certification level is not known
The mode of operation in which the cryptographic algorithm (block cipher) is used.
Cipher block chaining
Electronic codebook
Counter with cipher block chaining message authentication code
Galois/counter
Cipher feedback
Output feedback
Counter
Another mode of operation
The mode of operation is not known
The padding scheme that is used for the cryptographic algorithm.
Password-Based Cryptography Specification #5
Public Key Cryptography Standard: Cryptographic Message Syntax
Public Key Cryptography Standard: RSA Cryptography v1.5
Optimal asymmetric encryption padding
Raw
Another padding scheme
The padding scheme is not known
The cryptographic functions implemented by the cryptographic algorithm.
The classical security level that a cryptographic algorithm provides (in bits).
The NIST security strength category as defined in
https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/evaluation-criteria/security-(evaluation-criteria).
A value of 0 indicates that none of the categories are met.
Properties for cryptographic assets of asset type 'certificate'
The subject name for the certificate
The issuer name for the certificate
The date and time according to ISO-8601 standard from which the certificate is valid
The date and time according to ISO-8601 standard from which the certificate is not valid anymore
The bom-ref to signature algorithm used by the certificate
The bom-ref to the public key of the subject
The format of the certificate. Examples include X.509, PEM, DER, and CVC
The file extension of the certificate. Examples include crt, pem, cer, der, and p12.
Properties for cryptographic assets of asset type 'relatedCryptoMaterial'
The type for the related cryptographic material
The optional unique identifier for the related cryptographic material.
The key state as defined by NIST SP 800-57.
The bom-ref to the algorithm used to generate the related cryptographic material.
The date and time (timestamp) when the related cryptographic material was created.
The date and time (timestamp) when the related cryptographic material was activated.
The date and time (timestamp) when the related cryptographic material was updated.
The date and time (timestamp) when the related cryptographic material expires.
The associated value of the cryptographic material.
The size of the cryptographic asset (in bits).
The format of the related cryptographic material (e.g. P8, PEM, DER).
The mechanism by which the cryptographic asset is secured by.
Specifies the mechanism by which the cryptographic asset is secured by.
Examples include HSM, TPM, XGX, Software, and None.
The bom-ref to the algorithm.
Properties specific to cryptographic assets of type: 'protocol'.
The concrete protocol type.
Transport Layer Security
Secure Shell
Internet Protocol Security
Internet Key Exchange
Secure Socket Tunneling Protocol
Wi-Fi Protected Access
Another protocol type
The protocol type is not known
The version of the protocol. Examples include 1.0, 1.2, and 1.99.
A list of cipher suites related to the protocol.
A common name for the cipher suite. For example: TLS_DHE_RSA_WITH_AES_128_CCM
A list of algorithms related to the cipher suite.
The bom-ref to algorithm cryptographic asset.
A list of common identifiers for the cipher suite.
Cipher suite identifier. Examples include 0xC0 and 0x9E.
The IKEv2 transform types supported (types 1-4), defined in RFC7296 section 3.3.2,
and additional properties.
Transform Type 1: encryption algorithms
Transform Type 2: pseudorandom functions
Transform Type 3: integrity algorithms
Transform Type 4: Key Exchange Method (KE) per RFC9370, formerly called Diffie-Hellman Group (D-H)
Specifies if an Extended Sequence Number (ESN) is used.
IKEv2 Authentication method
A protocol-related cryptographic assets
The object identifier (OID) of the cryptographic asset.
The list of assessors evaluating claims and determining conformance to requirements and confidence in that assessment.
The assessor who evaluates claims and determines conformance to requirements and confidence in that assessment.
The boolean indicating if the assessor is outside the organization generating claims. A value of false indicates a self assessor.
The entity issuing the assessment.
An optional identifier which can be used to reference the object elsewhere in the BOM.
Every bom-ref must be unique within the BOM.
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 list of attestations asserted by an assessor that maps requirements to claims.
An attestation asserted by an assessor that maps requirements to claims.
The short description explaining the main points of the attestation.
The `bom-ref` to the assessor asserting the attestation.
The grouping of requirements to claims and the attestors declared conformance and confidence thereof.
The `bom-ref` to the requirement being attested to.
The list of `bom-ref` to the claims being attested to.
The `bom-ref` to the claim being attested to.
The list of `bom-ref` to the counter claims being attested to.
The `bom-ref` to the counter claim being attested to.
The conformance of the claim meeting a requirement.
The conformance of the claim between and inclusive of 0 and 1, where 1 is 100% conformance.
The rationale for the score of conformance.
The list of `bom-ref` to the evidence provided describing the
mitigation strategies. Each mitigation strategy should include an
explanation of how any weaknesses in the evidence will be mitigated.
The confidence of the claim meeting the requirement.
The confidence of the claim between and inclusive of 0 and 1, where 1 is 100% confidence.
The rationale for the confidence score.
Allows any undeclared elements as long as the elements are placed in a different namespace.
The list of claims.
The `bom-ref` to a target representing a specific system, application,
API, module, team, person, process, business unit, company, etc...
that this claim is being applied to.
The specific statement or assertion about the target.
The list of `bom-ref` to the evidence provided describing the
mitigation strategies. Each mitigation strategy should include an
explanation of how any weaknesses in the evidence will be mitigated.
The written explanation of why the evidence provided substantiates the claim.
The list of `bom-ref` to evidence that supports this claim.
The list of `bom-ref` to counterEvidence that supports this claim.
Provides the ability to document external references related to the claim the BOM describes.
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. Every bom-ref must be unique within the BOM.
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 list of evidence
The list of evidence
The reference to the property name as defined in the [CycloneDX Property Taxonomy](https://github.com/CycloneDX/cyclonedx-property-taxonomy/).
The written description of what this evidence is and how it was created.
The output or analysis that supports claims.
The name of the data.
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.
Data classification tags data according to its type, sensitivity, and value if altered, stolen, or destroyed.
A description of any sensitive data.
The date and time (timestamp) when the evidence was created.
The optional date and time (timestamp) when the evidence is no longer valid.
The author of the evidence.
The reviewer of the evidence.
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. Every bom-ref must be unique within the BOM.
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 list of targets which claims are made against.
The list of organizations which claims are made against.
The list of components which claims are made against.
The list of services which claims are made against.
A concise statement affirmed by an individual regarding all declarations, often used for third-party auditor acceptance or recipient acknowledgment.
It includes a list of authorized signatories who assert the validity of the document on behalf of the organization.
The brief statement affirmed by an individual regarding all declarations.
This could be an affirmation of acceptance by a third-party auditor or receiving
individual of a file. For example: "I certify, to the best of my knowledge, that all information is correct."
The list of signatories authorized on behalf of an organization to assert validity of this document.
The signatory's name.
The signatory's role within an organization.
The signatory's organization.
An External reference 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.
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.
Allows any undeclared elements as long as the elements are placed in a different namespace.
A collection of reusable objects that are defined and may be used elsewhere in the BOM.
The list of standards which may consist of regulations, industry or organizational-specific standards, maturity models, best practices, or any other requirements which can be evaluated against or attested to.
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 standard may consist of regulations, industry or organizational-specific standards, maturity models, best practices, or any other requirements which can be evaluated against or attested to.
The name of the standard. This will often be a shortened, single name of the standard.
The version of the standard.
The description of the standard.
The owner of the standard, often the entity responsible for its release.
The list of requirements comprising the standard.
The unique identifier used in the standard to identify a specific requirement. This should match what is in the standard and should not be the requirements bom-ref.
The title of the requirement.
The textual content of the requirement.
The supplemental text that provides additional guidance or context to the requirement, but is not directly part of the requirement.
The Common Requirements Enumeration (CRE) identifier(s). CRE is a structured and standardized framework for uniting security standards and guidelines. CRE links each section of a resource to a shared topic identifier (a Common Requirement). Through this shared topic link, all resources map to each other. Use of CRE promotes clear and unambiguous communication among stakeholders.
The optional `bom-ref` to a parent requirement. This establishes a hierarchy of requirements. Top-level requirements must not define a parent. Only child requirements should define parents.
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 external references related to the BOM or
to the project the BOM describes.
An optional identifier which can be used to reference the object elsewhere
in the BOM. Every bom-ref must be unique within the BOM.
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 list of levels associated with the standard. Some standards have different levels of compliance.
The identifier used in the standard to identify a specific level.
The title of the level.
The description of the level.
The list of requirement `bom-ref`s that comprise the level.
An optional identifier which can be used to reference the object elsewhere
in the BOM. Every bom-ref must be unique within the BOM.
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 BOM or
to the project the BOM describes.
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. Every bom-ref must be unique within the BOM.
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 strings that aid in discovery, search, and retrieval of the associated
object. Tags often serve as a way to group or categorize similar or related objects by various
attributes.
Examples include:
"json-parser", "object-persistence", "text-to-image", "translation", and "object-detection"
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.
The list of declarations which describe the conformance to standards. Each declaration may
include attestations, claims, and evidence.
A collection of reusable objects that are defined and may be used elsewhere in the BOM.
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.
© 2015 - 2025 Weber Informatics LLC | Privacy Policy