CycloneDX
Allow nesting Products
In certain use-cases it would be beneficial to have Products nested as Components of other Products.
In example, for Medical Devices, it may be helpful to treat hardware piece and firmware piece as 2 distinct Products which are then combined into a single Product - that is Medical Device as a whole.
In an old slide I have a product pointing to a TEI for another product. Maybe that's still a valid solution for this.
In an old slide I have a product pointing to a TEI for another product. Maybe that's still a valid solution for this.
I like that approach. In a large manufacturer, you may use the same component in multiple other components as well as offering it individually.
In the current model, a medical device is represented as two distinct TEA Components—hardware and software—which are both listed as parts of a single TEA Product. The hardware component has a fixed version, while the software component is upgradeable.
From my understanding, a TEA Product is essentially a bundle defined by a company's marketing or product management teams. For example, if a company produces two TEA Components, "Server A" and "Server B", it could define the following TEA Products:
- A "Server A" product that includes only the "Server A" component.
- A "Server B" product that includes only the "Server B" component.
- An "All Products" bundle that includes both "Server A" and "Server B" components.
A TEA Component, on the other hand, represents an independent piece of hardware or software with a specific version number. It is the unit for which the company publishes security information, tracks updates, and provides upgrades.
In my view, the Product API is primarily intended for human users rather than automation. Its main purpose is to allow customers to match a product—identified by its TEI or name as listed on an invoice—to a collection of TEA Components they need to monitor. From there, a DevOps or IT operations team can refine that list to include only the components that are actually deployed in their environment.
In contrast, the Component and Release APIs are more suitable for automated workflows. By querying these APIs directly—bypassing the Product API—an asset management or vulnerability scanning system can:
- Identify which TEA Components have available upgrades.
- Determine which TEA Components require upgrades due to critical issues.
- Retrieve a list of known vulnerabilities affecting deployed components, as well as a filtered list of exploitable vulnerabilities based on runtime or configuration context.
Allowing nesting between TEA Products could only be seen as a help for the DevOps team to identify which TEA Components they deployed, but I am pretty much sure they already know that.
@ppkarwasz This model can work, but I feel it leads to some undesired duplication.
In your scenario, I would have separate entry for Server A as a Product and Server A as a Component, which is essentially the same thing. Same for Server B. While possible, I don't think it's an ideal solution.
I think many products have one "product" and a single "component". We knew that and it's the way to provide for the flexibility of having bundles.
The key point here is that in Piotr's example Server A itself may consist of multiple components - thus being a Product. However, treating it as a Component in All Servers context requires us to create a separate and independent Component object for that same Server A. Currently, there is no way to map such Server A Component to the Server A Product, even though it's essentially the same thing.
I believe we should allow some sort of Product nesting to solve this properly.
For product to product relations we had TEI before. Maybe we need to add it again, so a product can consist of a set of (products and components)
Using a TEI makes it possible to include a product from another TEA service, maybe another vendor
The key point here is that in Piotr's example Server A itself may consist of multiple components - thus being a Product. However, treating it as a Component in All Servers context requires us to create a separate and independent Component object for that same Server A. Currently, there is no way to map such Server A Component to the Server A Product, even though it's essentially the same thing.
In my example, the "Server A" Product consists of a single Component, also named "Server A". If "Server A" were composed of multiple distinct TEA Components, those components would appear both in the "Server A" Product and in all broader products like "All Products".
Software products are effectively large graphs—or DAGs—of software components, linked by "is contained in" relationships. TEA needs to manage this complexity:
- Most nodes in the graph are only present in SBOMs and fall outside TEA's scope.
- Some nodes are TEA Components; they must publish SBOMs and propagate security events generated by their descendants.
- These TEA Components, along with their parent nodes, can be associated with TEA Products. We can model this in two ways:
- Represent Products as a flat set of top-level TEA Components.
- Or allow nesting of TEA Products, forming a hierarchy.
If we adopt the nested model, my example becomes:
- Server A: A Product containing only the Server A Component.
- Server B: A Product containing only the Server B Component.
- All Products: A bundle Product that contains both Server A and Server B as Products, not as Components.
This nested approach makes it clear to users that "Server A" and "Server B" can be bought separately, but it also increases complexity. TEA clients must now resolve Products recursively through both Component and Product relationships.
Using a TEI makes it possible to include a product from another TEA service, maybe another vendor
That's an interesting feature—can a TEI reference a TEA Component instead of a TEA Product?
Consider a business that repackages WiFi routers by replacing the proprietary firmware with OpenWRT. How should they publish their products in TEA? The original router (hardware + firmware) has a TEI, but the hardware alone does not. This raises the question of how to represent partial reuse or transformation of existing products.
This discussion also makes me question whether we should even differentiate between TEA Products and TEA Components. After all, they share the same data model fields. Right now, we expose them through different endpoints, but perhaps we should unify them into a single polymorphic entity—a TEA Product/Component—that can either:
- Have releases and collections (acting as a leaf node), or
- Be composed of other TEA Product/Components (acting as a container or bundle).
This would automatically allow product hierarchies of arbitrary depths.
This discussion also makes me question whether we should even differentiate between TEA Products and TEA Components. After all, they share the same data model fields.
Great point! On the implementation side, we actually already treat Products and Components almost the same way (they live in the same table).
However, I feel that for users it is easier to keep the distinction and it's easier for us to explain the whole thing if we keep them logically separate. The way I define the difference is Product is something that is used by the organization in its Marketing efforts, while Component is something that exists only on the Development level.
That's an interesting feature—can a TEI reference a TEA Component instead of a TEA Product? Not directly, but just create a separate TEA product with just one component and it's practically the same.
That's an interesting feature—can a TEI reference a TEA Component instead of a TEA Product?
Not directly, but just create a separate TEA product with just one component and it's practically the same.
While this approach is technically possible, it would result in significant clutter in the /products endpoint. Consider projects like Open Liberty, which consist of thousands of JARs. Following your suggestion in https://github.com/CycloneDX/specification/pull/634#issuecomment-2850724133 —using TEIs in SBOMs—we would need to create a TEI, and therefore a TEA Product, for each of these JARs. These products would provide little to no value outside of vulnerability management systems.
Allowing a TEI to directly reference a TEA Component would be a more scalable and practical solution in such cases.