Creating a Product Hierarchy

A product hierarchy lets you organize your software inventory by grouping assets and sub-products under a parent product. This structure reflects how the technology you develop or procure is actually composed, making it easier to track vulnerabilities and risk across complex software systems.

Before you begin

You need existing products or assets in your organization to build a hierarchy.
Manifest supports hierarchies up to 15 levels deep.

Why your hierarchy structure matters

How you organize your product hierarchy directly affects how vulnerabilities surface, how risk is reported, and how quickly your team can respond to a security event.

A well-structured hierarchy means:

Accurate rollup visibility. Vulnerabilities found in a low-level component automatically surface on every parent product that contains it. If your hierarchy does not reflect real software composition, you may miss impact.
Faster triage. When a critical CVE drops, you can immediately see every product line affected rather than manually hunting through individual assets.
Audit-ready reporting. Regulators and customers increasingly ask for evidence of what is inside your products. A hierarchy that maps to how your software is actually shipped makes generating SBOMs and compliance artifacts straightforward.
Cleaner remediation tracking. Fixing a vulnerability in a shared library should be visible across all products that depend on it. A proper hierarchy ensures nothing is missed.

Industry examples

Medical device manufacturers

Medical device companies typically ship a physical device that runs embedded software, which itself depends on third-party libraries and operating system components. Regulatory frameworks like the FDA's guidance on cybersecurity in medical devices and IEC 62443 require manufacturers to maintain a complete Software Bill of Materials (SBOM) for each device.

A recommended hierarchy might look like:

Cardiac Monitor (Device Product)
  └── Cardiac Monitor Firmware v3.2 (Sub-product)
        ├── Firmware Image (Asset)
        │     ├── Linux Kernel 5.15 (Component)
        │     ├── OpenSSL 1.1.1 (Component)
        │     ├── libcurl 7.88 (Component)
        │     └── SQLite 3.40 (Component)
        │
        └── Patient Data Interface Module (Asset)
              ├── libcurl 7.88 (Component)
              └── SQLite 3.40 (Component)

The device-level product is what your customers purchase and what regulators evaluate. Building the firmware and its dependencies as sub-products beneath the device means a single vulnerability in OpenSSL immediately flags the Cardiac Monitor as affected, which is exactly what a 510(k) submission or post-market surveillance program needs to demonstrate.

If you manage a portfolio of devices that share a common firmware base (e.g., the same Linux kernel across an infusion pump, a ventilator, and a patient monitor), you can link that shared firmware sub-product to multiple parent device products. One patch, tracked once, visible everywhere.

Aviation and aerospace

Aviation software is subject to DO-178C certification levels (DAL A through E) and increasingly to DO-326A for airworthiness security. Avionics systems are composed of multiple Line Replaceable Units (LRUs), each running software with its own certification history.

A recommended hierarchy might look like:

Flight Management System (Top-level Product)
  ├── Navigation LRU Software v12.4 (Sub-product)
  │     ├── ARINC 653 RTOS (Asset)
  │     └── Navigation Algorithm Library (Asset)
  ├── Display Management Software v8.1 (Sub-product)
  │     ├── Graphics Rendering Engine (Asset)
  │     └── Font & Symbol Library (Asset)
  └── Communication Interface Module (Sub-product)
        ├── VHF Radio Driver (Asset)
        └── ACARS Protocol Stack (Asset)

Each LRU is independently certified, but the airworthiness of the entire Flight Management System depends on all of them. Structuring LRU software as sub-products under the system-level product lets you report vulnerability posture at both the system level (for the airline customer or regulator) and the component level (for the engineering team responsible for that LRU).

When a vulnerability is found in a shared library like a communication stack used across multiple LRUs, it surfaces on every affected sub-product and rolls up to the top-level system, giving you the blast radius immediately.

Automotive and manufacturing

Modern vehicles and industrial control systems are deeply software-defined. Automotive manufacturers must manage ECU (Electronic Control Unit) software across model years and trim levels, and increasingly must comply with UN R155 (vehicle cybersecurity) and ISO/SAE 21434.

A recommended hierarchy for an automotive OEM might look like:

2025 Model X Sedan (Vehicle Product)
  ├── Powertrain Control Module (Sub-product)
  │     ├── AUTOSAR Adaptive Platform (Asset)
  │     └── OBD Diagnostics Stack (Asset)
  ├── ADAS Software Suite v4.0 (Sub-product)
  │     ├── Camera Perception Library (Asset)
  │     ├── Radar Fusion Module (Asset)
  │     		└── OpenCV 4.7 (Component)
  └── Infotainment System (Sub-product)
        ├── Android Automotive OS (Asset)
        ├── Bluetooth Stack (Asset)
        └── Navigation SDK (Asset)

For manufacturing and industrial equipment:

Industrial Robotic Arm - Series 7 (Product)
  ├── Motion Control Firmware (Sub-product)
  │     ├── FreeRTOS (Asset)
  │     └── Motor Control SDK (Asset)
  └── HMI Interface Software (Sub-product)
        ├── Qt Framework (Asset)
        └── Modbus/TCP Driver (Asset)

Automotive and manufacturing teams often share software components across many product variants. A vulnerability in the Bluetooth stack may affect 12 different model configurations. Building the hierarchy to reflect this shared composition means your security team can trace impact across the entire product portfolio in one view, rather than maintaining separate inventories per model year or configuration.

Best practices

Build from the bottom up. Add inventory (assets or sub-products) to a product before adding that product to another product in the hierarchy. This ensures each level of your structure contains meaningful data as you build upward.
Start with what you ship to customers or regulators. Your top-level products should represent what an external stakeholder would recognize: a device, a system, a vehicle model, or a software product. Work inward from there.
Avoid creating empty products. Empty hierarchies make it harder to validate your structure and can lead to confusion about what each product actually contains.
Repeat for each product you onboard. Once you have built a hierarchy for one product, apply the same bottom-up approach to organize others in your organization.

Not sure where to start?

If your software composition is complex or you are new to building product hierarchies, Manifest's team can help. We work with customers to:

Map from the top down. If you know what products you ship but are not sure how to break them into sub-products and assets, we can help you define the right levels for your industry and compliance requirements.
Identify shared components. Many organizations have firmware, libraries, or modules that appear across multiple products. We can help you structure these so they are tracked once and linked everywhere they are used.
Validate your structure before you scale. Starting with one product and getting the hierarchy right before onboarding your full portfolio saves significant rework later.

Reach out to your Manifest account team or contact support to schedule a hierarchy planning session.

Adding items to a product (UI)

Navigate to the Product Details page for the product you want to modify.
Go to the Inventory tab to view the current sub-product hierarchy.
Click Add Item.
In the modal, choose either the Assets or Products tab.
Select one or more items to add. Items are sorted alphabetically, then by version (9 to 0). You can see each item's name, version, supplier, and whether it is already part of the current product. For products, you can also see the number of items they contain.
Click any item's link to open it in a new tab.
Confirm your selection.

The new sub-products or assets appear in the Inventory tab. A notification confirms whether the items were added successfully.

Removing items from a product (UI)

On the Product Details page, go to the Inventory tab.
Select a top-level sub-product or asset from the hierarchy.
Remove the selected items by clicking the chain-break icon.

The Inventory tab updates to reflect the change. A notification confirms whether the items were removed successfully.

Note: You can only remove direct children of the current product, not items deeper in the hierarchy.

Adding items to a product (API)

Use the add inventory API to add one or more asset IDs or product IDs to an existing product programmatically. This is useful for build systems or automated workflows where you need to create and manage products without manual UI interaction.

Removing items from a product (API)

Use the remove inventory API to remove one or more asset IDs or product IDs from an existing product.

Viewing the product hierarchy

On the Product Details page, the Inventory tab displays a tree view of all sub-products and assets. The tree is collapsed by default. You can expand or collapse individual sub-products to explore the hierarchy.

For each sub-product or asset, you can see:

Name
Version
Supplier
Number of vulnerabilities
Labels

Use the view sub-products API to retrieve the full sub-product hierarchy for a given product ID programmatically.

What to expect

When you add items to a product, they appear immediately in the Inventory tab tree view. You can expand the tree to verify the structure matches your software composition.

Top-level products that contain sub-products affected by a vulnerability will show those vulnerabilities on the Vulnerability Details page, making it easier to understand impact across your product portfolio.