Parts

Definition

A Part represents a reference to another Product's Version that is embedded or exists alongside the current Version. Parts enable hierarchical SBOM composition — modeling scenarios where a software artifact is assembled from multiple independently-managed components.

Usage Scenarios

Scenario	Description
Multi-module builds	A Java application with multiple Maven modules, each with its own SBOM, composed into a single Product Version.
Container layers	A container image composed of a base OS layer, middleware, and application, each managed as separate Products.
Microservice bundles	A deployment unit consisting of multiple microservices, each independently versioned, assembled into a single release SBOM.
Hardware + firmware	An appliance Product composed of a hardware BOM and firmware SBOM from separate Product tracks.
Embedded third-party software	A Product that bundles an open-source component (e.g., OpenSSL, SQLite) managed as a separate Product.

How Parts Work

Product A - Version 1.0 (Parent SBOM)
  ├── Component: app-core v2.1
  ├── Component: app-utils v1.3
  └── Part: Product B - Version 3.0 (Child SBOM)
      ├── Component: lib-crypto v1.0
      └── Component: lib-network v2.2

When a Part is added to a Version:

1. The child SBOM's Components are included in the parent Version's component list.

2. Vulnerabilities from the child's Components are reflected in the parent Version.

3. Policy evaluation considers Components from both the parent and child SBOMs.

4. The parent can set its own VEX status for vulnerabilities inherited from Parts — allowing the parent Product's team to record their own assessment of a child Part's vulnerabilities independently from the child's own triage.

Operational Considerations

• Vulnerability rollups: Vulnerabilities from Parts are aggregated into the parent Version. A critical vulnerability in a Part's component affects the parent Version's risk profile.

• Health scoring: The parent Version's health score incorporates data from all Parts. A poorly-scored Part will impact the parent's overall health.

• Policy evaluation: Policies can be configured to include or exclude Parts using the exclude_parts option on policy definitions.

• "Always Use Latest Parts" setting: When enabled, the parent Version automatically references the latest Version of each Part's source Product, keeping composition up to date without manual re-linking.

Best Practices

• Manage Parts as separate Products when they have independent release cycles, teams, or compliance requirements.

• Use the "Always Use Latest Parts" setting in Environments where you want the composition to track the latest state of dependencies.

• Set VEX status at the parent level when a Part's vulnerability does not apply in the context of the parent Product — record your justification independently from the child Part's own triage.

• Exclude Parts from policies when the Part's source Product already has its own policy coverage and you want to avoid duplicate violations.