CycloneDX v1.7 Protobuf Reference

A name of the advisory.

Location where the advisory can be obtained.

A identifier which can be used to reference the annotation elsewhere in the BOM. Every `bom_ref` must be unique within the BOM.

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.

The organization, person, 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.

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

An organization

An individual

A reference to a previously defined `organizationalContact` or `organizationalEntity` object in the BOM. The value must be a valid `bom_ref` pointing to one of these objects.

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](https://www.ietf.org/rfc/rfc2045.html#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](https://www.iana.org/assignments/media-types/media-types.xhtml).

Specifies the encoding the text is represented in

SimpleContent value of element. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.

The version of the CycloneDX specification a BOM is written to (starting at version 1.3)

The version allows component publishers/authors to make changes to existing BOMs to update various aspects of the document such as description or licenses. When a system is presented with multiple BOMs for the same component, the system should use the most recent version of the BOM. The default version is '1' and should be incremented for each version of the BOM that is published. Each version of a component should have a unique BOM and if no changes are made to the BOMs, then each BOM will have a version of '1'.

Every BOM generated should have a unique serial number, even if the contents of the BOM being generated have not changed over time. The process or tool responsible for creating the BOM should create random UUID's for every BOM generated.

Provides additional information about a BOM.

Provides the ability to document a list of components.

Provides the ability to document a list of external services.

Provides the ability to document external references related to the BOM or to the project the BOM describes.

Provides the ability to document dependency relationships.

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.

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.

Specifies custom properties.

Describes the formulation of any referencable object within the BOM, including components, services, metadata, declarations, or the BOM itself. This may encompass how the object was created, assembled, deployed, tested, certified, or otherwise brought into its present form. Common examples include software build pipelines, deployment processes, AI/ML model training, cryptographic key generation or certification, and third-party audits. Processes are modeled using declared and observed formulas, composed of workflows, tasks, and individual steps.

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.

A collection of attributions indicating which entity supplied information for specific fields within the BOM.

Quantity of carbon dioxide (CO2).

Unit of carbon dioxide (CO2).

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.

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.

Unique identifier for the citation.

One or more JSON Pointers(https://datatracker.ietf.org/doc/html/rfc6901) identifying the BOM fields to which the attribution applies.

One or more path expressions used to locate values within a BOM.

Timestamp when the attribution was made or the information was supplied.

The `bom_ref` of an object, such as a component, service, tool, organisational entity, or person that supplied the cited information. At least one of the "attributed_to" or "process" elements must be present.

The `bom_ref` to a process (such as a formula, workflow, task, or step) defined in the `formulation` section that executed or generated the attributed data. At least one of the "attributed_to" or "process" elements must be present.

A description or comment about the context or quality of the data attribution.

Specifies a path expression used to locate a value within a BOM. The expression syntax shall conform to the format of the BOM's serialisation. Use [JSONPath](https://datatracker.ietf.org/doc/html/rfc9535) for JSON, [XPath](https://www.w3.org/TR/xpath/) for XML, and default to JSONPath for Protocol Buffers unless otherwise specified. Implementers shall ensure the expression is valid within the context of the applicable serialisation format. Use either "pointer" or "expression" but not both in this object. Must contain at least 1 item.

Users of other serialisation formats (e.g. XML) shall use the JSON Pointer format to ensure consistent field referencing across representations. Must contain at least 1 item.

A text representation of the executed command.

Domain-specific command properties.

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

Specifies the type of component. For software components, classify as an application if no more specific appropriate classification is available or cannot be determined for the component.

The 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.

A 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.

The organization that supplied the component. The supplier may often be the manufacturer but may also be a distributor or repackager.

Deprecated. 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. Version was made optional in v1.4 of the spec. For backward compatibility, it is recommended to use an empty string to represent components without version information. Must be used exclusively, either 'version' or 'versionRange', but not both.

For an external component, this specifies the accepted version range. The value must adhere to the Package URL Version Range syntax (vers), as defined at https://github.com/package-url/vers-spec. May only be used if `isExternal` is set to `true`. Must be used exclusively, either 'version' or 'versionRange', but not both.

Specifies a description for the component

Specifies the scope of the component. If a scope is not specified, SCOPE_REQUIRED scope should be assumed by the consumer of the BOM

The hashes of the component.

A list of SPDX licenses and/or named licenses and/or SPDX License Expression.

An copyright notice informing users of the underlying claims to copyright ownership in a published work.

DEPRECATED - DO NOT USE. This will be removed in a future version. Specifies a well-formed CPE name. See https://nvd.nist.gov/products/cpe

Specifies the package-url (PURL). The purl, if specified, must be valid and conform to the specification defined at: https://github.com/package-url/purl-spec

Specifies metadata and content for ISO-IEC 19770-2 Software Identification (SWID) Tags.

DEPRECATED - DO NOT USE. This will be removed in a future version. Use the pedigree element instead to supply information on exactly how the component was modified. A boolean value indicating is the component has been modified from the original. A value of true indicates the component is a derivative of the original. A value of false indicates the component has not been modified from the original.

Component pedigree is a way to document complex supply chain scenarios where components are created, distributed, modified, redistributed, combined with other components, etc.

Provides the ability to document external references related to the component or to the project the component describes.

Specifies sub-components. This is not a dependency tree. It provides a way to specify a hierarchical representation of component assemblies, similar to system -> subsystem -> parts assembly in physical supply chains.

Specifies custom properties.

Specifies license and copyright evidence.

Specifies release notes.

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.

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.

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.

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".

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

Determine whether this component is external. An external component is one that is not part of an assembly, but is expected to be provided by the environment, regardless of the component's `scope`. This setting can be useful for distinguishing which components are bundled with the product and which can be relied upon to be present in the deployment environment. This may be set to `true` for runtime components only. For `Bom.metadata.component`, it must be set to `false`. implicit defaults to `false`

A list of assertions made regarding patents associated with this component or service. Assertions distinguish between ownership, licensing, and other relevant interactions with patents.

A identifier which can be used to reference the dataset elsewhere in the BOM. Every `bom_ref` must be unique within the BOM.

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.

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.

Data Governance

A 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.

Indicates the aggregate completeness

The assemblies the aggregate completeness applies to

The dependencies the aggregate completeness applies to

The bom_ref identifiers of the vulnerabilities being described.

A identifier which can be used to reference the composition elsewhere in the BOM. Every `bom_ref` must be unique within the BOM.

Describes the set of conditions which cause the trigger to activate.

The logical expression that was evaluated that determined the trigger should be fired.

Domain-specific condition instance properties.

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.

Additional properties specific to a cryptographic algorithm.

Properties for cryptographic assets of asset type 'certificate'

Properties for cryptographic assets of asset type: `related-crypto-material`

Properties specific to cryptographic assets of type: `protocol`.

The object identifier (OID) of the cryptographic asset.

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).

A valid algorithm family identifier. If specified, this value must be one of the enumeration of valid algorithm Family identifiers defined in the `cryptography-defs.schema.json` subschema. A corresponding schema for ProtoBuf is not available.

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).

Deprecated. DEPRECATED - DO NOT USE - This will be removed in a future version - Use `.ellipticCurve` instead. 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/](https://neuromancer.sk/std/), the source from which can be found at [https://github.com/J08nY/std-curves](https://github.com/J08nY/std-curves).

The specific underlying Elliptic Curve (EC) definition employed which is an indicator of the level of security strength, performance and complexity. If specified, this value must be one of the enumeration of valid elliptic curves identifiers defined in the `cryptography-defs.schema.json` subschema. A corresponding schema for ProtoBuf is not available.

The target and execution environment in which the algorithm is implemented in.

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).

The mode of operation in which the cryptographic algorithm (block cipher) is used.

The padding scheme that is used for the cryptographic algorithm.

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.

List of certificate extensions

The name of the extension

The value of the certificate extension

The name for the custom certificate extension

The description of the custom certificate extension

Common extension with predefined name

Custom extension with user-defined name

The serial number is a unique identifier for the certificate issued by a CA.

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

Deprecated. DEPRECATED - DO NOT USE - This will be removed in a future version - Use `.relatedCryptographicAssets` instead. The bom-ref to signature algorithm used by the certificate

Deprecated. DEPRECATED - DO NOT USE - This will be removed in a future version - Use `.relatedCryptographicAssets` instead. The bom-ref to the public key of the subject

The format of the certificate. Examples include X.509, PEM, DER, and CVC.

Deprecated. DEPRECATED - DO NOT USE - This will be removed in a future version - Use `.certificateFileExtension` instead. The file extension of the certificate. Examples include crt, pem, cer, der, and p12.

The file extension of the certificate. Examples include crt, pem, cer, der, and p12.

The fingerprint is a cryptographic hash of the certificate excluding it's signature.

The certificate lifecycle is a comprehensive process that manages digital certificates from their initial creation to eventual expiration or revocation. It typically involves several stages.

The date and time (timestamp) when the certificate was created or pre-activated.

The date and time (timestamp) when the certificate was activated.

The date and time (timestamp) when the related certificate was deactivated.

The date and time (timestamp) when the certificate was revoked.

The date and time (timestamp) when the certificate was destroyed.

A certificate extension is a field that provides additional information about the certificate or its use. Extensions are used to convey additional information beyond the standard fields.

A list of cryptographic assets related to this component.

A reason for the certificate being in this state.

A pre-defined state in the certificate lifecycle.

The name of the certificate lifecycle state for custom states.

The description of the certificate lifecycle state (only used with custom states).

The concrete protocol type.

The version of the protocol. Examples include 1.0, 1.2, and 1.99.

A list of cipher suites related to the protocol.

Deprecated. DEPRECATED - DO NOT USE - This will be removed in a future version - Use `.ikev2TransformTypesDetailed` instead. The IKEv2 transform types supported (types 1-4), defined in RFC7296 section 3.3.2, and additional properties.

The IKEv2 transform types supported (types 1-4), defined in RFC7296 section 3.3.2, and additional properties. If this field is present, the deprecated field `.ikev2TransformTypes` MUST be ignored.

The bom-ref(s) to protocol-related cryptographic assets

A list of cryptographic assets related to this component.

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. Use the bom_ref to the algorithm cryptographic asset.

A list of common identifiers for the cipher suite. For example: 0xC0 and 0x9E

A list of TLS named groups (formerly known as curves) for this cipher suite. These groups define the parameters for key exchange algorithms like ECDHE.

A list of signature schemes supported for cipher suite. These schemes specify the algorithms used for digital signatures in TLS handshakes and certificate verification.

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

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 name for the authentication method

The bom-ref to algorithm cryptographic asset

A name for the encryption method

The key length of the encryption algorithm

The bom-ref to algorithm cryptographic asset

A name for the integrity algorithm

The bom-ref to algorithm cryptographic asset

A group identifier for the key exchange algorithm

The bom-ref to algorithm cryptographic asset

A name for the pseudorandom function

The bom-ref to algorithm cryptographic asset

The type for the related cryptographic material

The unique identifier for the related cryptographic material.

The key state as defined by NIST SP 800-57.

Deprecated. DEPRECATED - DO NOT USE - This will be removed in a future version - Use `.relatedCryptographicAssets` instead. 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.

The fingerprint is a cryptographic hash of the asset.

A list of cryptographic assets related to this component.

Specifies the mechanism by which the cryptographic asset is secured. Examples include HSM, TPM, SGX, Software, and None

The bom_ref to the algorithm.

List of related cryptographic assets

The type of the related cryptographic asset

The reference to the related cryptographic asset

Specifies the flow direction of the data.

Data classification tags data according to its type, sensitivity, and value if altered, stolen, or destroyed.

Name for the defined data

Short description of the data content and usage

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

Data Governance

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.

The organization that is responsible for specific data governance role(s).

The individual that is responsible for specific data governance role(s).

The list of assessors evaluating claims and determining conformance to requirements and confidence in that assessment.

The list of attestations asserted by an assessor that maps requirements to claims.

The list of claims.

The list of evidence

The list of targets 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. Notes: This could be an affirmation of acceptance by a third-party auditor or receiving individual of a file. 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 provides 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.

A 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.

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.

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 list of `bom_ref` to the counter claims being attested to.

The conformance of the claim meeting a requirement.

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.

The conformance of the claim between and inclusive of 0 and 1, where 1 is 100% conformance.

The rationale for the conformance score.

The list of `bom_ref` to the evidence provided describing the mitigation strategies.

A 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.

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.

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.

A 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.

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 date and time (timestamp) when the evidence was created.

The date and time (timestamp) when the evidence is no longer valid.

The author of the evidence.

The reviewer of the evidence.

The name of the data.

The contents or references to the contents of the data being described.

Data classification tags data according to its type, sensitivity, and value if altered, stolen, or destroyed.

A description of any sensitive data included.

Data Governance

A way to include textual or encoded data.

The URL to where the data can be retrieved.

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.

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.

The list of either individual patents or patent families.

A 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.

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 list of levels associated with the standard. Some standards have different levels of compliance.

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.

A 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.

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.

A 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.

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. The use of CRE promotes clear and unambiguous communication among stakeholders.

The `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.

Specifies custom properties.

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.

References a component or service by its bom_ref attribute

The bom_ref identifiers of the components or services that are dependencies of this dependency object.

The bom_ref identifiers of the components or services that define a given specification or standard, which are provided or implemented by this dependency object.

Specifies the text of the diff

Specifies the URL to the diff

Quantity of energy.

Unit of energy.

BOM unique reference to the energy provider.

A description of the energy provider.

The organization of the energy provider.

The energy source for the energy provider.

The energy provided by the energy source for an associated activity.

Provides the ability to document external references related to the BOM or to the project the BOM describes.

Name-value pair

Value

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

Additional properties of the event.

A list of SPDX licenses and/or named licenses and/or SPDX License Expression.

Copyright evidence captures intellectual property assertions, providing evidence of possible ownership and legal protection.

Evidence that substantiates the identity of a component. The identity may be an object or an array of identity objects. Support for specifying identity as a single object was introduced in CycloneDX v1.5. Arrays were introduced in v1.6. It is recommended that all implementations use arrays, even if only one identity object is specified.

Evidence of individual instances of a component spread across multiple locations.

Evidence of the components use through the callstack.

Copyright text

The identity field of the component which the evidence describes.

The overall confidence of the evidence from 0 - 1, where 1 is 100% confidence.

The methods used to extract and/or analyze the evidence.

The 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.

The value of the field (cpe, purl, etc) that has been concluded based on the aggregate of all methods (if available).

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.

A identifier which can be used to reference the occurrence elsewhere in the BOM. Every `bom_ref` must be unique within the BOM.

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).

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.

The URL to the external reference

A comment describing the external reference

Integrity hashes for the external resource content

Specifies custom properties.

BOM unique reference to the resource.

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.

Domain-specific formula properties.

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.

Specifies the algorithm used to create the hash

SimpleContent value of element

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

A references to the component or service that provided the input to the task (e.g., reference to a service with a 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)

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.

Additional properties of the input data.

Specifies the type of issue

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

A collection of URL's for reference. Multiple URLs are allowed. Example: "https://example.com"

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 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.

A 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.

Licensing details describing the licensor/licensee, license type, renewal and expiration dates, and other important metadata

Specifies custom properties.

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.

A license

A valid SPDX license expression. Refer to https://spdx.org/specifications for syntax requirements.

A SPDX license expression and its details

This field must only be used when `expression` is chosen as the other options have their own acknowledgement.

This field must only be used when `expression` is chosen as the other options have their own bom_ref.

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"

Licensing details describing the licensor/licensee, license type, renewal and expiration dates, and other important metadata Details for parts of the `expression`.

A 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.

Licensing details describing the licensor/licensee, license type, renewal and expiration dates, and other important metadata

Specifies custom properties.

A valid SPDX license identifier. Refer to https://spdx.org/specifications for syntax requirements. This field serves as the primary key, which uniquely identifies each record. Example values: - "Apache-2.0", - "GPL-3.0-only WITH Classpath-exception-2.0" - "LicenseRef-my-custom-license"

A 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.

A way to include the textual content of the license.

The URL to the license file. If specified, a 'license' externalReference should also be specified for completeness

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 individual or organization for which a license was granted to

The individual or 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).

A pre-defined phase in the product lifecycle.

The name of the lifecycle phase

The description of the lifecycle phase

The date and time (timestamp) when the document was created.

The tool(s) used in the creation of the BOM.

The person(s) who created the BOM. Authors are common in BOMs created through manual processes. BOMs created through automated means may have '.manufacturer' instead.

The component that the BOM describes.

Deprecated. 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 manufacture, 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. A list of SPDX licenses and/or named licenses and/or SPDX License Expression.

Specifies custom properties.

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.

The organization that created the BOM. Manufacturer is common in BOMs created through automated processes. BOMs created through manual means may have '.authors' instead.

Conditions and constraints governing the sharing and distribution of the data or components described by this BOM.

The Traffic Light Protocol (TLP) classification that controls the sharing and distribution of the data that the BOM describes.

A identifier which can be used to reference the model card elsewhere in the BOM. Every `bom_ref` must be unique within the BOM.

Hyper-parameters for construction of the model.

A quantitative analysis of the model

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?

How does the model affect groups at risk of being systematically disadvantaged? What are the harms and benefits to the various affected groups?

What are the various environmental impacts the corresponding machine learning model has exhibited across its lifecycle?

The type of activity that is part of a machine learning model development or operational lifecycle.

The providers of the energy consumed by the associated model development lifecycle activity.

The total energy cost associated with the model lifecycle activity.

The CO2 cost or debit equivalent to the total energy cost.

The CO2 offset or credit for the CO2 equivalent cost.

Specifies custom properties for environment considerations.

Describes energy consumption information incurred for one or more component lifecycle activities.

Specifies custom properties for environment considerations.

The name of the risk.

Strategy used to address this risk.

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.

The overall approach to learning used by the model for problem-solving.

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.

The input format(s) of the model

The output format(s) from the model

Learning types describing the learning problem or hybrid learning problem.

Inline Data Information

References a data component by the components bom_ref attribute

The data format for input/output to the model. Example formats include string, image, time-series

The model performance metrics being reported. Examples may include accuracy, F1 score, precision, top-3 error rates, MSC, etc.

A collection of graphics that represent various measurements.

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.

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.

The name of the contact

The email address of the contact.

The phone number of the contact.

A 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.

The name of the organization

The URL of the organization. Multiple URLs are allowed.

A contact person at the organization. Multiple contacts are allowed.

A 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.

The physical address (location) of the organization

Organization

Individual

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`)

A reference to an independent resource generated as output by the task.

Outputs that have the form of data.

Outputs that have the form of environment variables.

Additional properties of the output data.

The name of the parameter.

The value of the parameter.

The data type of the parameter.

Specifies the purpose for the patch, including the resolution of defects, security issues, or new behavior or functionality

The patch file (or diff) that show changes. Refer to https://en.wikipedia.org/wiki/Diff

A collection of issues the patch resolves

A 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.

The unique number assigned to the granted patent by the issuing authority. Aligned with `PatentNumber` in WIPO ST.96. Refer to [PatentNumber in ST.96](https://www.wipo.int/standards/XMLSchema/ST96/V8_0/Patent/PatentNumber.xsd).

The unique number assigned to a patent application when it is filed with a patent office. It is used to identify the specific application and track its progress through the examination process. Aligned with `ApplicationNumber` in ST.96. Refer to [ApplicationIdentificationType in ST.96](https://www.wipo.int/standards/XMLSchema/ST96/V8_0/Patent/ApplicationIdentificationType.xsd).

The jurisdiction or patent office where the priority application was filed, specified using WIPO ST.3 codes. Aligned with `IPOfficeCode` in ST.96. Refer to [IPOfficeCode in ST.96](https://www.wipo.int/standards/XMLSchema/ST96/V8_0/Common/IPOfficeCode.xsd).

The priorityApplication contains the essential data necessary to identify and reference an earlier patent filing for priority rights. In line with WIPO ST.96 guidelines, it includes the jurisdiction (office code), application number, and filing date-the three key elements that uniquely specify the priority application in a global patent context.

This is the number assigned to a patent application once it is published. Patent applications are generally published 18 months after filing (unless an applicant requests non-publication). This number is distinct from the application number.

The title of the patent, summarising the invention it protects. Aligned with `InventionTitle` in WIPO ST.96. Refer to [InventionTitle in ST.96](https://www.wipo.int/standards/XMLSchema/ST96/V8_0/Patent/InventionTitle.xsd).

A brief summary of the invention described in the patent. Aligned with `Abstract` and `P` in WIPO ST.96. Refer to [Abstract in ST.96](https://www.wipo.int/standards/XMLSchema/ST96/V8_0/Patent/Abstract.xsd).

The date the patent application was filed with the jurisdiction. Aligned with `FilingDate` in WIPO ST.96. Refer to [FilingDate in ST.96](https://www.wipo.int/standards/XMLSchema/ST96/V8_0/Patent/FilingDate.xsd).

The date the patent was granted by the jurisdiction. Aligned with `GrantDate` in WIPO ST.96. Refer to [GrantDate in ST.96](https://www.wipo.int/standards/XMLSchema/ST96/V8_0/Patent/GrantDate.xsd).

The date the patent expires. Derived from grant or filing date according to jurisdiction-specific rules.

Indicates the current legal status of the patent or patent application, based on the WIPO ST.27 standard. This status reflects administrative, procedural, or legal events. Values include both active and inactive states and are useful for determining enforceability, procedural history, and maintenance status.

A collection of organisations or individuals to whom the patent rights are assigned. This supports joint ownership and allows for flexible representation of both corporate entities and individual inventors.

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.

A 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.

The type of assertion being made about the patent or patent family. Examples include ownership, licensing, and standards inclusion.

A list of BOM references (`bom_ref`) linking to patents or patent families associated with this assertion.

A reference to a previously defined `organizationalContact` or `organizationalEntity` object in the BOM. The value must be a valid `bom_ref` pointing to one of these objects.

Additional notes or clarifications regarding the assertion, if necessary. For example, geographical restrictions, duration, or limitations of a license.

A 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.

The unique identifier for the patent family, aligned with the `id` attribute in WIPO ST.96 v8.0's `PatentFamilyType`. Refer to [PatentFamilyType in ST.96](https://www.wipo.int/standards/XMLSchema/ST96/V8_0/Patent/PatentFamilyType.xsd).

The priorityApplication contains the essential data necessary to identify and reference an earlier patent filing for priority rights. In line with WIPO ST.96 guidelines, it includes the jurisdiction (office code), application number, and filing date-the three key elements that uniquely specify the priority application in a global patent context.

A collection of patents or applications that belong to this family, each identified by a `bom_ref` pointing to a patent object defined elsewhere in the BOM. bom_ref strings

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 individual patent

A patent family

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 an 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 is 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 component's pedigree.

A identifier which can be used to reference the address elsewhere in the BOM. Every `bom_ref` must be unique within the BOM.

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.

The unique number assigned to a patent application when it is filed with a patent office. It is used to identify the specific application and track its progress through the examination process. Aligned with `ApplicationNumber` in ST.96. Refer to [ApplicationIdentificationType in ST.96](https://www.wipo.int/standards/XMLSchema/ST96/V8_0/Patent/ApplicationIdentificationType.xsd).

The jurisdiction or patent office where the priority application was filed, specified using WIPO ST.3 codes. Aligned with `IPOfficeCode` in ST.96. Refer to [IPOfficeCode in ST.96](https://www.wipo.int/standards/XMLSchema/ST96/V8_0/Common/IPOfficeCode.xsd).

The date the priority application was filed, aligned with `FilingDate` in ST.96. Refer to [FilingDate in ST.96](https://www.wipo.int/standards/XMLSchema/ST96/V8_0/Patent/FilingDate.xsd).

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.

Name (or key)

Value

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.

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.

Alternate names the release may be referred to. This may include unofficial terms used by development and marketing teams (e.g. code names).

Textual strings that aid in the 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".

A collection of issues that have been resolved.

Zero or more release notes containing the locale and content. Multiple note messages may be specified to support release notes in a wide variety of languages.

Specifies custom properties.

References an object by its bom_ref attribute

Reference to an externally accessible resource

A 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.

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 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 the use of the service crosses a trust zone or boundary. A value of true indicates that by using the service, a trust boundary is crossed. A value of false indicates that by using the service, a trust boundary is not crossed.

Specifies information about the data including the directional flow of data and the data classification.

A list of SPDX licenses and/or named licenses and/or SPDX License Expression.

Provides the ability to document external references related to the service.

Specifies sub-service. This is not a dependency tree. It provides a way to specify a hierarchical representation of service assemblies, similar to system -> subsystem -> parts assembly in physical supply chains.

Specifies custom properties.

Specifies release notes.

The name of the trust zone the service resides in.

Textual strings that aid in the 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".

A list of assertions made regarding patents associated with this component or service. Assertions distinguish between ownership, licensing, and other relevant interactions with patents.

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 name for the step.

A description of the step.

Ordered list of commands or directives for the step

Domain-specific step properties.

Maps to the tagId of a SoftwareIdentity.

Maps to the name of a SoftwareIdentity.

Maps to the version of a SoftwareIdentity. Defaults to '0.0' if not specified.

Maps to the tagVersion of a SoftwareIdentity. Defaults to '0' if not specified.

Maps to the patch of a SoftwareIdentity. Defaults to 'false' if not specified.

Specifies the full content of the SWID tag.

The URL to the SWID file.

BOM unique reference to the resource.

The unique identifier for the resource instance within its deployment context.

The name of the resource instance.

A description of the resource instance.

Domain-specific task instance properties.

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 an executor or task commands

Represents resources and data output from a task at runtime by an 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.

Deprecated. DEPRECATED - DO NOT USE - This will be removed in a future version. The vendor of the tool used to create the BOM.

Deprecated. DEPRECATED - DO NOT USE - This will be removed in a future version. The name of the tool used to create the BOM.

Deprecated. DEPRECATED - DO NOT USE - This will be removed in a future version. The version of the tool used to create the BOM.

Deprecated. DEPRECATED - DO NOT USE - This will be removed in a future version.

Deprecated. DEPRECATED - DO NOT USE - This will be removed in a future version. Provides the ability to document external references related to the tool.

A list of software and hardware components used as tools

A list of services used as tools. This may include microservices, function-as-a-service, and other types of network or intra-process services.

BOM unique reference to the resource.

The unique identifier for the resource instance within its deployment context.

The name of the resource instance.

A description of the resource instance.

Additional properties of the trigger.

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.

The date and time (timestamp) when the trigger was activated.

Represents resources and data brought into a task at runtime by an executor or task commands

Represents resources and data output from a task at runtime by an executor or task commands

The unique identifier for the volume instance within its deployment context.

The name of the volume instance

The volume 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 the 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.

Domain-specific volume instance properties.

A 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 identifier that uniquely identifies the vulnerability.

The source that published the vulnerability.

Zero or more pointers to vulnerabilities that are the equivalent of the vulnerability specified. Oftentimes, 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.

List of vulnerability ratings

List of Common Weaknesses Enumerations (CWEs) codes that describe 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 the root cause.

Recommendations of how the vulnerability can be remediated or mitigated.

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.

Individuals or organizations credited with the discovery of the vulnerability.

The tool(s) used to identify, confirm, or score the vulnerability.

An assessment of the impact and exploitability of the vulnerability.

affects

Specifies custom properties.

The date and time (timestamp) when the vulnerability record was rejected (if applicable).

Evidence used to reproduce the vulnerability.

A bypass, usually temporary, of the vulnerability that reduces its likelihood and/or impact. Workarounds often involve changes to configuration or deployments.

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/vers-spec

The vulnerability status for the version or range of versions. Defaults to VULNERABILITY_AFFECTED_STATUS_AFFECTED if not specified.

References a component or service by the objects bom_ref

Zero or more individual versions or range of versions.

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 the 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 organizations credited with vulnerability discovery.

The individuals not associated with organizations that are credited with vulnerability discovery.

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.

Specifies the severity or risk scoring methodology or standard used.

Textual representation of the metric values used to score the vulnerability.

A reason for rating the vulnerability as it was.

An identifier that uniquely identifies the vulnerability.

The source that published the vulnerability.

BOM unique reference to the resource.

The unique identifier for the resource instance within its deployment context.

The name of the resource instance.

A description of the resource instance.

Domain-specific resource instance properties.

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.

BOM unique reference to the resource.

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.

A description of the resource instance.

Domain-specific workspace instance properties.

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 for the associated task's steps.

The name of a domain-specific data type the workspace represents.

Identifies the reference to the request for a specific volume type and parameters.

Information about the actual volume instance allocated to the workspace.