CycloneDX v1.6 Protobuf Reference

An optional name of the advisory.

Location where the advisory can be obtained.

An optional 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

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 optional 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 optional, custom, properties

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.

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.

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.

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

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.

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.

EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one SPDX License Expression)

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

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

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

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 optional sub-components. This is not a dependency tree. It provides a way to specify a hierarchical representation of component assemblies, similar to system -> subsystem -> parts assembly in physical supply chains.

Specifies optional, custom, properties

Specifies optional license and copyright evidence.

Specifies optional 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

An optional 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

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.

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.

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

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/](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 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.

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.

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.

The IKEv2 transform types supported (types 1-4), defined in RFC7296 section 3.3.2, and additional properties.

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

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

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

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.

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

The bom-ref to the algorithm.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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

Specifies optional, 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 optional 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.

EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one 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.

An optional 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

An optional comment describing the external reference

Optional integrity hashes for the external resource content

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

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.

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

Specifies optional, 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

This field must only be used when "expression" is chosen as the License object has its own acknowledgement.

This field must only be used when "expression" is chosen as the License object has its own bom_ref.

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. EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one SPDX License Expression)

Specifies optional, 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.

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.

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 optional, custom properties for environment considerations

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

Specifies optional, 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.

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.

The name of the organization

The URL of the organization. Multiple URLs are allowed.

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

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.

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

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.

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

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.

Optional 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 optional, custom, properties

References an object by its bom-ref attribute

Reference to an externally accessible resource

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.

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.

EITHER (list of SPDX licenses and/or named licenses) OR (tuple of one SPDX License Expression)

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

Specifies optional 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 optional, custom, properties

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

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 - The vendor of the tool used to create the BOM.

Deprecated. DEPRECATED - DO NOT USE - The name of the tool used to create the BOM.

Deprecated. DEPRECATED - DO NOT USE - The version of the tool used to create the BOM.

Deprecated. DEPRECATED - DO NOT USE

Deprecated. DEPRECATED - DO NOT USE - 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.

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 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 optional, 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/purl-spec/VERSION-RANGE-SPEC.rst

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.

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