The Manifest Object Model

At Manifest, we model software using a three-tier object structure that reflects how software is built, packaged, and deployed. Our model consists of Products, Assets, and Components, each representing a different layer of the software supply chain.

Object Hierarchy

📦 Products → 📦 Sub-Products 📁 → Assets → 🔗 Components

Products

A Product represents the top-level software system your organization ships to customers or deploys internally. It is the thing an external stakeholder — a customer, regulator, or auditor — would recognize as a discrete offering. Each Product is made up of Sub-Products and Assets that contribute to its functionality. Products can be:

A medical device running embedded software
A vehicle model with multiple software-defined systems
An enterprise software suite
A physical device (e.g., a point-of-sale system, an industrial robot)

Sub-Products

A Sub-Product is a software component that lives within a parent Product or another Sub-Product. It groups related Assets together and represents a meaningful, independently manageable unit of software — such as a firmware package, a platform module, or a third-party software stack. Sub-Products can be shared across multiple parent Products, meaning a single patch is tracked once and surfaces everywhere it's used. Sub-Products can be:

Device firmware (e.g., Cardiac Monitor Firmware v3.2)
A software suite within a larger system (e.g., an ADAS Suite inside a vehicle product)
A shared platform component (e.g., an OS or runtime used across multiple products)
A Line Replaceable Unit (LRU) software package in an avionics system

Assets

An Asset represents an intermediary collection of software—the building blocks that organizations maintain and deploy. These can include:

Source code repositories
Container images
Packaged distributions (e.g., Debian packages, RPMs)
Assets are built from multiple Components, which contain the underlying dependencies.

Components

A Component is a specific software dependency within an asset. These include:

Open-source libraries (e.g., a JavaScript package, a Python library)
Proprietary libraries (internally developed dependencies)
A single Component can exist in multiple Assets and, by extension, in multiple Products.

Why This Model?

This hierarchy allows Manifest to track vulnerabilities at every level, ensuring that risks are identified:

At the component level, where vulnerabilities originate
At the asset level, where development teams package software
At the product level, where vulnerabilities can have real-world impact on customers

By structuring data this way, Manifest enables organizations to assess risk holistically—prioritizing fixes where they matter most.

Note: Sub-Products and Assets are collectively referred to as items. When adding or removing components from a Product or Sub-Product, you are managing items within that level of the hierarchy.