CycloneDX

Identifier for referable and therefore interlink-able elements.

The name of the organization

The URL of the organization. Multiple URLs are allowed.

A contact at the organization. Multiple contacts are allowed.

Maps to the tagId of a SoftwareIdentity.

Maps to the name of a SoftwareIdentity.

Maps to the version of a SoftwareIdentity.

Maps to the tagVersion of a SoftwareIdentity.

Maps to the patch of a SoftwareIdentity.

Specifies the metadata and content for an attachment.

The URL to the SWID file.

Describes zero or more components in which a component is derived from. This is commonly used to describe forks from existing projects where the forked version contains a ancestor node containing the original component it was forked from. For example, Component A is the original component. Component B is the component being used and documented in the BOM. However, Component B contains a pedigree node with a single ancestor documenting Component A - the original component from which Component B is derived from.

Descendants are the exact opposite of ancestors. This provides a way to document all forks (and their forks) of an original or root component.

Variants describe relations where the relationship between the components are not known. For example, if Component A contains nearly identical code to Component B. They are both related, but it is unclear if one is derived from the other, or if they share a common ancestor.

A list of zero or more commits which provide a trail describing how the component deviates from an ancestor, descendant, or variant.

A list of zero or more patches describing how the component deviates from an ancestor, descendant, or variant. Patches may be complimentary to commits or may be used in place of commits.

Notes, observations, and other non-structured commentary describing the components pedigree.

Evidence that substantiates the identity of a component.

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

Evidence of the components use through the callstack.

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

The software versioning type. It is RECOMMENDED that the release type use one of 'major', 'minor', 'patch', 'pre-release', or 'internal'. Representing all possible software release types is not practical, so standardizing on the recommended values, whenever possible, is strongly encouraged.

• major = A major release may contain significant changes or may introduce breaking changes.
• minor = A minor release, also known as an update, may contain a smaller number of changes than major releases.
• patch = Patch releases are typically unplanned and may resolve defects or important security issues.
• pre-release = A pre-release may include alpha, beta, or release candidates and typically have limited support. They provide the ability to preview a release prior to its general availability.
• internal = Internal releases are not for public consumption and are intended to be used exclusively by the project or manufacturer that produced it.

The title of the release.

The URL to an image that may be prominently displayed with the release note.

The URL to an image that may be used in messaging on social media platforms.

A short description of the release.

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

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

One or more tags that may aid in search or retrieval of the release note.

A collection of issues that have been resolved.

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

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is OPTIONAL.

Identifier for referable and therefore interlink-able elements.

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?

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is OPTIONAL.

The attachment data. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.

Specifies the content type of the text. Defaults to text/plain if not specified.

Specifies the optional encoding the text is represented in.

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

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.

Who are the intended users of the model?

What are the intended use cases of the model?

What are the known technical limitations of the model? E.g. What kind(s) of data should the model be expected not to perform well on? What are the factors that might degrade model performance?

What are the known tradeoffs in accuracy/performance of the model?

What are the ethical (or environmental) risks involved in the application of this model?

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

The attachment data. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.

Specifies the content type of the text. Defaults to text/plain if not specified.

Specifies the optional encoding the text is represented in.

Identifier for referable and therefore interlink-able elements.

The name of the organization

The URL of the organization. Multiple URLs are allowed.

A contact at the organization. Multiple contacts are allowed.

Identifier for referable and therefore interlink-able elements.

The name of a contact

The email address of the contact.

The phone number of the contact.

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

• application = A software application. Refer to [https://en.wikipedia.org/wiki/Application_software](https://en.wikipedia.org/wiki/Application_software) for information about applications.
• framework = A software framework. Refer to [https://en.wikipedia.org/wiki/Software_framework](https://en.wikipedia.org/wiki/Software_framework) for information on how frameworks vary slightly from libraries.
• library = A software library. Refer to [https://en.wikipedia.org/wiki/Library_(computing)](https://en.wikipedia.org/wiki/Library_(computing)) for information about libraries. All third-party and open source reusable components will likely be a library. If the library also has key features of a framework, then it should be classified as a framework. If not, or is unknown, then specifying library is RECOMMENDED.
• container = A packaging and/or runtime format, not specific to any particular technology, which isolates software inside the container from software outside of a container through virtualization technology. Refer to [https://en.wikipedia.org/wiki/OS-level_virtualization](https://en.wikipedia.org/wiki/OS-level_virtualization)
• platform = A runtime environment which interprets or executes software. This may include runtimes such as those that execute bytecode or low-code/no-code application platforms.
• operating-system = A software operating system without regard to deployment model (i.e. installed on physical hardware, virtual machine, image, etc) Refer to [https://en.wikipedia.org/wiki/Operating_system](https://en.wikipedia.org/wiki/Operating_system)
• device = A hardware device such as a processor, or chip-set. A hardware device containing firmware SHOULD include a component for the physical hardware itself, and another component of type 'firmware' or 'operating-system' (whichever is relevant), describing information about the software running on the device. See also the list of known device properties.
• device-driver = A special type of software that operates or controls a particular type of device. Refer to [https://en.wikipedia.org/wiki/Device_driver](https://en.wikipedia.org/wiki/Device_driver)
• firmware = A special type of software that provides low-level control over a devices hardware. Refer to [https://en.wikipedia.org/wiki/Firmware](https://en.wikipedia.org/wiki/Firmware)
• file = A computer file. Refer to [https://en.wikipedia.org/wiki/Computer_file](https://en.wikipedia.org/wiki/Computer_file) for information about files.
• machine-learning-model = A model based on training data that can make predictions or decisions without being explicitly programmed to do so.
• data = A collection of discrete values that convey information.

The name of the component. This will often be a shortened, single name of the component. Examples: commons-lang3 and jquery

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.

Identifier for referable and therefore interlink-able elements.

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 component version. The version should ideally comply with semantic versioning but is not enforced.

Specifies a description for the component

Specifies the scope of the component. If scope is not specified, 'required' scope SHOULD be assumed by the consumer of the BOM.

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

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

Specifies a well-formed CPE name that conforms to the CPE 2.2 or 2.3 specification. See [https://nvd.nist.gov/products/cpe](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](https://github.com/package-url/purl-spec)

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

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

Component pedigree is a way to document complex supply chain scenarios where components are created, distributed, modified, redistributed, combined with other components, etc. Pedigree supports viewing this complex chain from the beginning, the end, or anywhere in the middle. It also provides a way to document variants where the exact relation may not be known.

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 list of software and hardware components included in the parent component. This is not a dependency tree. It provides a way to specify a hierarchical representation of component assemblies, similar to system → subsystem → parts assembly in physical supply chains.

Provides the ability to document evidence collected through various forms of extraction or analysis.

A model card describes the intended uses of a machine learning model and potential limitations, including biases and ethical considerations. Model cards typically contain the training parameters, which datasets were used to train the model, performance metrics, and other relevant data useful for ML transparency. This object SHOULD be specified for any component of type machine-learning-model and MUST NOT be specified for other component types.

This object SHOULD be specified for any component of type data and MUST NOT be specified for other component types.

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is OPTIONAL.

Enveloped signature in JSON Signature Format (JSF).

The name of the service. This will often be a shortened, single name of the service.

Identifier for referable and therefore interlink-able elements.

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

Specifies a description for the service

The endpoint URIs of the service. Multiple endpoints are allowed.

A boolean value indicating if the service requires authentication. A value of true indicates the service requires authentication prior to use. A value of false indicates the service does not require authentication.

A boolean value indicating if use of the service crosses a trust zone or boundary. A value of true indicates that by using the service, a trust boundary is crossed. A value of false indicates that by using the service, a trust boundary is not crossed.

The name of the trust zone the service resides in.

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

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

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 list of services included or deployed behind the parent service. This is not a dependency tree. It provides a way to specify a hierarchical representation of service assemblies.

Provides the ability to document properties in a name-value store. This provides flexibility to include data not officially supported in the standard without having to use additional namespaces or create extensions. Unlike key-value stores, properties support duplicate names, each potentially having different values. Property names of interest to the general public are encouraged to be registered in the CycloneDX Property Taxonomy. Formal registration is OPTIONAL.

Enveloped signature in JSON Signature Format (JSF).

Learning types describing the learning problem or hybrid learning problem.

A description of this collection of graphics.

A collection of graphics.

The attachment data. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.

Specifies the content type of the text. Defaults to text/plain if not specified.

Specifies the optional encoding the text is represented in.

The unique identifier of the event.

A description of the event.

The date and time (timestamp) when the event was received.

Specifies the metadata and content for an attachment.

A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.

A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.

The unique identifier of the event.

A description of the event.

The date and time (timestamp) when the event was received.

Specifies the metadata and content for an attachment.

A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.

A reference to a locally defined resource (e.g., a bom-ref) or an externally accessible resource.

The attachment data. Proactive controls such as input validation and sanitization should be employed to prevent misuse of attachment text.

Specifies the content type of the text. Defaults to text/plain if not specified.

Specifies the optional encoding the text is represented in.

References an object by its bom-ref attribute

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 an object by its bom-ref attribute

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.

The URI (URL or URN) to the external reference. External references are URIs and therefore can accept any URL scheme including https (RFC-7230), mailto (RFC-2368), tel (RFC-3966), and dns (RFC-4501). External references may also include formally registered URNs such as CycloneDX BOM-Link to reference CycloneDX BOMs or any object within a BOM. BOM-Link transforms applicable external references into relationships that can be expressed in a BOM or across BOMs.

Specifies the type of external reference.

• vcs = Version Control System
• issue-tracker = Issue or defect tracking system, or an Application Lifecycle Management (ALM) system
• website = Website
• advisories = Security advisories
• bom = Bill of Materials (SBOM, OBOM, HBOM, SaaSBOM, etc)
• mailing-list = Mailing list or discussion group
• social = Social media account
• chat = Real-time chat platform
• documentation = Documentation, guides, or how-to instructions
• support = Community or commercial support
• distribution = Direct or repository download location
• distribution-intake = The location where a component was published to. This is often the same as "distribution" but may also include specialized publishing processes that act as an intermediary
• license = The URL to the license file. If a license URL has been defined in the license node, it should also be defined as an external reference for completeness
• build-meta = Build-system specific meta file (i.e. pom.xml, package.json, .nuspec, etc)
• build-system = URL to an automated build system
• release-notes = URL to release notes
• security-contact = Specifies a way to contact the maintainer, supplier, or provider in the event of a security incident. Common URIs include links to a disclosure procedure, a mailto (RFC-2368) that specifies an email address, a tel (RFC-3966) that specifies a phone number, or dns (RFC-4501) that specifies the records containing DNS Security TXT
• model-card = 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
• log = A record of events that occurred in a computer system or application, such as problems, errors, or information on current operations
• configuration = Parameters or settings that may be used by other components or services
• evidence = Information used to substantiate a claim
• formulation = Describes how a component or service was manufactured or deployed
• attestation = Human or machine-readable statements containing facts, evidence, or testimony
• threat-model = An enumeration of identified weaknesses, threats, and countermeasures, dataflow diagram (DFD), attack tree, and other supporting documentation in human-readable or machine-readable format
• adversary-model = The defined assumptions, goals, and capabilities of an adversary.
• risk-assessment = Identifies and analyzes the potential of future events that may negatively impact individuals, assets, and/or the environment. Risk assessments may also include judgments on the tolerability of each risk.
• vulnerability-assertion = A Vulnerability Disclosure Report (VDR) which asserts the known and previously unknown vulnerabilities that affect a component, service, or product including the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on a component, service, or product.
• exploitability-statement = A Vulnerability Exploitability eXchange (VEX) which asserts the known vulnerabilities that do not affect a product, product family, or organization, and optionally the ones that do. The VEX should include the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on the product, product family, or organization.
• pentest-report = Results from an authorized simulated cyberattack on a component or service, otherwise known as a penetration test
• static-analysis-report = SARIF or proprietary machine or human-readable report for which static analysis has identified code quality, security, and other potential issues with the source code
• dynamic-analysis-report = Dynamic analysis report that has identified issues such as vulnerabilities and misconfigurations
• runtime-analysis-report = Report generated by analyzing the call stack of a running application
• component-analysis-report = Report generated by Software Composition Analysis (SCA), container analysis, or other forms of component analysis
• maturity-report = Report containing a formal assessment of an organization, business unit, or team against a maturity model
• certification-report = Industry, regulatory, or other certification from an accredited (if applicable) certification body
• quality-metrics = Report or system in which quality metrics can be obtained
• codified-infrastructure = Code or configuration that defines and provisions virtualized infrastructure, commonly referred to as Infrastructure as Code (IaC)
• poam = Plans of Action and Milestones (POAM) compliment an "attestation" external reference. POAM is defined by NIST as a "document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks and scheduled completion dates for the milestones".
• other = Use this if no other types accurately describe the purpose of the external reference

An optional comment describing the external reference

The hashes of the external reference (if applicable).

The URI (URL or URN) to the external reference. External references are URIs and therefore can accept any URL scheme including https (RFC-7230), mailto (RFC-2368), tel (RFC-3966), and dns (RFC-4501). External references may also include formally registered URNs such as CycloneDX BOM-Link to reference CycloneDX BOMs or any object within a BOM. BOM-Link transforms applicable external references into relationships that can be expressed in a BOM or across BOMs.

Specifies the type of external reference.

• vcs = Version Control System
• issue-tracker = Issue or defect tracking system, or an Application Lifecycle Management (ALM) system
• website = Website
• advisories = Security advisories
• bom = Bill of Materials (SBOM, OBOM, HBOM, SaaSBOM, etc)
• mailing-list = Mailing list or discussion group
• social = Social media account
• chat = Real-time chat platform
• documentation = Documentation, guides, or how-to instructions
• support = Community or commercial support
• distribution = Direct or repository download location
• distribution-intake = The location where a component was published to. This is often the same as "distribution" but may also include specialized publishing processes that act as an intermediary
• license = The URL to the license file. If a license URL has been defined in the license node, it should also be defined as an external reference for completeness
• build-meta = Build-system specific meta file (i.e. pom.xml, package.json, .nuspec, etc)
• build-system = URL to an automated build system
• release-notes = URL to release notes
• security-contact = Specifies a way to contact the maintainer, supplier, or provider in the event of a security incident. Common URIs include links to a disclosure procedure, a mailto (RFC-2368) that specifies an email address, a tel (RFC-3966) that specifies a phone number, or dns (RFC-4501) that specifies the records containing DNS Security TXT
• model-card = 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
• log = A record of events that occurred in a computer system or application, such as problems, errors, or information on current operations
• configuration = Parameters or settings that may be used by other components or services
• evidence = Information used to substantiate a claim
• formulation = Describes how a component or service was manufactured or deployed
• attestation = Human or machine-readable statements containing facts, evidence, or testimony
• threat-model = An enumeration of identified weaknesses, threats, and countermeasures, dataflow diagram (DFD), attack tree, and other supporting documentation in human-readable or machine-readable format
• adversary-model = The defined assumptions, goals, and capabilities of an adversary.
• risk-assessment = Identifies and analyzes the potential of future events that may negatively impact individuals, assets, and/or the environment. Risk assessments may also include judgments on the tolerability of each risk.
• vulnerability-assertion = A Vulnerability Disclosure Report (VDR) which asserts the known and previously unknown vulnerabilities that affect a component, service, or product including the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on a component, service, or product.
• exploitability-statement = A Vulnerability Exploitability eXchange (VEX) which asserts the known vulnerabilities that do not affect a product, product family, or organization, and optionally the ones that do. The VEX should include the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on the product, product family, or organization.
• pentest-report = Results from an authorized simulated cyberattack on a component or service, otherwise known as a penetration test
• static-analysis-report = SARIF or proprietary machine or human-readable report for which static analysis has identified code quality, security, and other potential issues with the source code
• dynamic-analysis-report = Dynamic analysis report that has identified issues such as vulnerabilities and misconfigurations
• runtime-analysis-report = Report generated by analyzing the call stack of a running application
• component-analysis-report = Report generated by Software Composition Analysis (SCA), container analysis, or other forms of component analysis
• maturity-report = Report containing a formal assessment of an organization, business unit, or team against a maturity model
• certification-report = Industry, regulatory, or other certification from an accredited (if applicable) certification body
• quality-metrics = Report or system in which quality metrics can be obtained
• codified-infrastructure = Code or configuration that defines and provisions virtualized infrastructure, commonly referred to as Infrastructure as Code (IaC)
• poam = Plans of Action and Milestones (POAM) compliment an "attestation" external reference. POAM is defined by NIST as a "document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks and scheduled completion dates for the milestones".
• other = Use this if no other types accurately describe the purpose of the external reference

An optional comment describing the external reference

The hashes of the external reference (if applicable).

The URI (URL or URN) to the external reference. External references are URIs and therefore can accept any URL scheme including https (RFC-7230), mailto (RFC-2368), tel (RFC-3966), and dns (RFC-4501). External references may also include formally registered URNs such as CycloneDX BOM-Link to reference CycloneDX BOMs or any object within a BOM. BOM-Link transforms applicable external references into relationships that can be expressed in a BOM or across BOMs.

Specifies the type of external reference.

• vcs = Version Control System
• issue-tracker = Issue or defect tracking system, or an Application Lifecycle Management (ALM) system
• website = Website
• advisories = Security advisories
• bom = Bill of Materials (SBOM, OBOM, HBOM, SaaSBOM, etc)
• mailing-list = Mailing list or discussion group
• social = Social media account
• chat = Real-time chat platform
• documentation = Documentation, guides, or how-to instructions
• support = Community or commercial support
• distribution = Direct or repository download location
• distribution-intake = The location where a component was published to. This is often the same as "distribution" but may also include specialized publishing processes that act as an intermediary
• license = The URL to the license file. If a license URL has been defined in the license node, it should also be defined as an external reference for completeness
• build-meta = Build-system specific meta file (i.e. pom.xml, package.json, .nuspec, etc)
• build-system = URL to an automated build system
• release-notes = URL to release notes
• security-contact = Specifies a way to contact the maintainer, supplier, or provider in the event of a security incident. Common URIs include links to a disclosure procedure, a mailto (RFC-2368) that specifies an email address, a tel (RFC-3966) that specifies a phone number, or dns (RFC-4501) that specifies the records containing DNS Security TXT
• model-card = 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
• log = A record of events that occurred in a computer system or application, such as problems, errors, or information on current operations
• configuration = Parameters or settings that may be used by other components or services
• evidence = Information used to substantiate a claim
• formulation = Describes how a component or service was manufactured or deployed
• attestation = Human or machine-readable statements containing facts, evidence, or testimony
• threat-model = An enumeration of identified weaknesses, threats, and countermeasures, dataflow diagram (DFD), attack tree, and other supporting documentation in human-readable or machine-readable format
• adversary-model = The defined assumptions, goals, and capabilities of an adversary.
• risk-assessment = Identifies and analyzes the potential of future events that may negatively impact individuals, assets, and/or the environment. Risk assessments may also include judgments on the tolerability of each risk.
• vulnerability-assertion = A Vulnerability Disclosure Report (VDR) which asserts the known and previously unknown vulnerabilities that affect a component, service, or product including the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on a component, service, or product.
• exploitability-statement = A Vulnerability Exploitability eXchange (VEX) which asserts the known vulnerabilities that do not affect a product, product family, or organization, and optionally the ones that do. The VEX should include the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on the product, product family, or organization.
• pentest-report = Results from an authorized simulated cyberattack on a component or service, otherwise known as a penetration test
• static-analysis-report = SARIF or proprietary machine or human-readable report for which static analysis has identified code quality, security, and other potential issues with the source code
• dynamic-analysis-report = Dynamic analysis report that has identified issues such as vulnerabilities and misconfigurations
• runtime-analysis-report = Report generated by analyzing the call stack of a running application
• component-analysis-report = Report generated by Software Composition Analysis (SCA), container analysis, or other forms of component analysis
• maturity-report = Report containing a formal assessment of an organization, business unit, or team against a maturity model
• certification-report = Industry, regulatory, or other certification from an accredited (if applicable) certification body
• quality-metrics = Report or system in which quality metrics can be obtained
• codified-infrastructure = Code or configuration that defines and provisions virtualized infrastructure, commonly referred to as Infrastructure as Code (IaC)
• poam = Plans of Action and Milestones (POAM) compliment an "attestation" external reference. POAM is defined by NIST as a "document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks and scheduled completion dates for the milestones".
• other = Use this if no other types accurately describe the purpose of the external reference

An optional comment describing the external reference

The hashes of the external reference (if applicable).

The URI (URL or URN) to the external reference. External references are URIs and therefore can accept any URL scheme including https (RFC-7230), mailto (RFC-2368), tel (RFC-3966), and dns (RFC-4501). External references may also include formally registered URNs such as CycloneDX BOM-Link to reference CycloneDX BOMs or any object within a BOM. BOM-Link transforms applicable external references into relationships that can be expressed in a BOM or across BOMs.

Specifies the type of external reference.

• vcs = Version Control System
• issue-tracker = Issue or defect tracking system, or an Application Lifecycle Management (ALM) system
• website = Website
• advisories = Security advisories
• bom = Bill of Materials (SBOM, OBOM, HBOM, SaaSBOM, etc)
• mailing-list = Mailing list or discussion group
• social = Social media account
• chat = Real-time chat platform
• documentation = Documentation, guides, or how-to instructions
• support = Community or commercial support
• distribution = Direct or repository download location
• distribution-intake = The location where a component was published to. This is often the same as "distribution" but may also include specialized publishing processes that act as an intermediary
• license = The URL to the license file. If a license URL has been defined in the license node, it should also be defined as an external reference for completeness
• build-meta = Build-system specific meta file (i.e. pom.xml, package.json, .nuspec, etc)
• build-system = URL to an automated build system
• release-notes = URL to release notes
• security-contact = Specifies a way to contact the maintainer, supplier, or provider in the event of a security incident. Common URIs include links to a disclosure procedure, a mailto (RFC-2368) that specifies an email address, a tel (RFC-3966) that specifies a phone number, or dns (RFC-4501) that specifies the records containing DNS Security TXT
• model-card = 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
• log = A record of events that occurred in a computer system or application, such as problems, errors, or information on current operations
• configuration = Parameters or settings that may be used by other components or services
• evidence = Information used to substantiate a claim
• formulation = Describes how a component or service was manufactured or deployed
• attestation = Human or machine-readable statements containing facts, evidence, or testimony
• threat-model = An enumeration of identified weaknesses, threats, and countermeasures, dataflow diagram (DFD), attack tree, and other supporting documentation in human-readable or machine-readable format
• adversary-model = The defined assumptions, goals, and capabilities of an adversary.
• risk-assessment = Identifies and analyzes the potential of future events that may negatively impact individuals, assets, and/or the environment. Risk assessments may also include judgments on the tolerability of each risk.
• vulnerability-assertion = A Vulnerability Disclosure Report (VDR) which asserts the known and previously unknown vulnerabilities that affect a component, service, or product including the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on a component, service, or product.
• exploitability-statement = A Vulnerability Exploitability eXchange (VEX) which asserts the known vulnerabilities that do not affect a product, product family, or organization, and optionally the ones that do. The VEX should include the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on the product, product family, or organization.
• pentest-report = Results from an authorized simulated cyberattack on a component or service, otherwise known as a penetration test
• static-analysis-report = SARIF or proprietary machine or human-readable report for which static analysis has identified code quality, security, and other potential issues with the source code
• dynamic-analysis-report = Dynamic analysis report that has identified issues such as vulnerabilities and misconfigurations
• runtime-analysis-report = Report generated by analyzing the call stack of a running application
• component-analysis-report = Report generated by Software Composition Analysis (SCA), container analysis, or other forms of component analysis
• maturity-report = Report containing a formal assessment of an organization, business unit, or team against a maturity model
• certification-report = Industry, regulatory, or other certification from an accredited (if applicable) certification body
• quality-metrics = Report or system in which quality metrics can be obtained
• codified-infrastructure = Code or configuration that defines and provisions virtualized infrastructure, commonly referred to as Infrastructure as Code (IaC)
• poam = Plans of Action and Milestones (POAM) compliment an "attestation" external reference. POAM is defined by NIST as a "document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks and scheduled completion dates for the milestones".
• other = Use this if no other types accurately describe the purpose of the external reference

An optional comment describing the external reference

The hashes of the external reference (if applicable).

The URI (URL or URN) to the external reference. External references are URIs and therefore can accept any URL scheme including https (RFC-7230), mailto (RFC-2368), tel (RFC-3966), and dns (RFC-4501). External references may also include formally registered URNs such as CycloneDX BOM-Link to reference CycloneDX BOMs or any object within a BOM. BOM-Link transforms applicable external references into relationships that can be expressed in a BOM or across BOMs.

Specifies the type of external reference.

• vcs = Version Control System
• issue-tracker = Issue or defect tracking system, or an Application Lifecycle Management (ALM) system
• website = Website
• advisories = Security advisories
• bom = Bill of Materials (SBOM, OBOM, HBOM, SaaSBOM, etc)
• mailing-list = Mailing list or discussion group
• social = Social media account
• chat = Real-time chat platform
• documentation = Documentation, guides, or how-to instructions
• support = Community or commercial support
• distribution = Direct or repository download location
• distribution-intake = The location where a component was published to. This is often the same as "distribution" but may also include specialized publishing processes that act as an intermediary
• license = The URL to the license file. If a license URL has been defined in the license node, it should also be defined as an external reference for completeness
• build-meta = Build-system specific meta file (i.e. pom.xml, package.json, .nuspec, etc)
• build-system = URL to an automated build system
• release-notes = URL to release notes
• security-contact = Specifies a way to contact the maintainer, supplier, or provider in the event of a security incident. Common URIs include links to a disclosure procedure, a mailto (RFC-2368) that specifies an email address, a tel (RFC-3966) that specifies a phone number, or dns (RFC-4501) that specifies the records containing DNS Security TXT
• model-card = 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
• log = A record of events that occurred in a computer system or application, such as problems, errors, or information on current operations
• configuration = Parameters or settings that may be used by other components or services
• evidence = Information used to substantiate a claim
• formulation = Describes how a component or service was manufactured or deployed
• attestation = Human or machine-readable statements containing facts, evidence, or testimony
• threat-model = An enumeration of identified weaknesses, threats, and countermeasures, dataflow diagram (DFD), attack tree, and other supporting documentation in human-readable or machine-readable format
• adversary-model = The defined assumptions, goals, and capabilities of an adversary.
• risk-assessment = Identifies and analyzes the potential of future events that may negatively impact individuals, assets, and/or the environment. Risk assessments may also include judgments on the tolerability of each risk.
• vulnerability-assertion = A Vulnerability Disclosure Report (VDR) which asserts the known and previously unknown vulnerabilities that affect a component, service, or product including the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on a component, service, or product.
• exploitability-statement = A Vulnerability Exploitability eXchange (VEX) which asserts the known vulnerabilities that do not affect a product, product family, or organization, and optionally the ones that do. The VEX should include the analysis and findings describing the impact (or lack of impact) that the reported vulnerability has on the product, product family, or organization.
• pentest-report = Results from an authorized simulated cyberattack on a component or service, otherwise known as a penetration test
• static-analysis-report = SARIF or proprietary machine or human-readable report for which static analysis has identified code quality, security, and other potential issues with the source code
• dynamic-analysis-report = Dynamic analysis report that has identified issues such as vulnerabilities and misconfigurations
• runtime-analysis-report = Report generated by analyzing the call stack of a running application
• component-analysis-report = Report generated by Software Composition Analysis (SCA), container analysis, or other forms of component analysis
• maturity-report = Report containing a formal assessment of an organization, business unit, or team against a maturity model
• certification-report = Industry, regulatory, or other certification from an accredited (if applicable) certification body
• quality-metrics = Report or system in which quality metrics can be obtained
• codified-infrastructure = Code or configuration that defines and provisions virtualized infrastructure, commonly referred to as Infrastructure as Code (IaC)
• poam = Plans of Action and Milestones (POAM) compliment an "attestation" external reference. POAM is defined by NIST as a "document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks and scheduled completion dates for the milestones".
• other = Use this if no other types accurately describe the purpose of the external reference

An optional comment describing the external reference

The hashes of the external reference (if applicable).