Closing the Gap Legacy Tools Left Open
Most vulnerability management workflows were designed around a unit of work that made sense a decade ago, the repository. Scan the repo. Triage the findings. Close the ticket. Repeat.
That model made sense when software was simpler, teams were smaller, and "the product" was close enough to "the codebase" that you could treat them as the same thing.
That is no longer the case, and the gap between the two is where a lot of risk is quietly accumulating.
Where SCA Leaves Something to be Desired
A connected vehicle does not have one repository. It has an infotainment system with thousands of components, a telematics control unit with hundreds more, an ADAS domain controller, a battery management system, and a half-dozen other electronic control units (ECUs), each with its own software stack. The same is true for a medical device, an industrial control system, or a defense platform.
When a critical vulnerability surfaces in a library like libwebp, the question your team needs to answer is not "which of our repos contain this?" It is "which of our products is exposed, how deeply is it embedded, and which system is the highest priority to patch?"
Legacy tools cannot answer that question. They were built to surface findings at the component or repository level. They have no concept of the product hierarchy sitting above those assets, no way to roll risk up from a library to a subsystem to a platform, and no mechanism to tell you whether the exposure in one ECU is more dangerous than the same exposure in another because of where it sits in the system.
The result is a security team that can tell you everything about individual findings and almost nothing about aggregate product risk.
What "Product-Level Visibility" Actually Means
There is a difference between knowing your software is exposed and understanding your product's risk posture.
Knowing your software is exposed means you have a list of vulnerable components. It might be a long list. It might be accurate. But without context about what those components belong to, how they relate to each other, and what would happen if one of them was exploited, you are staring at a signal without a system to interpret it.
Understanding your product's risk posture means you can navigate from the top of a product hierarchy down to the specific library driving an issue. You can see that a vulnerability in an Android Automotive OS stack is nested inside an infotainment system that is part of a connected vehicle platform with 2,640 components and 38 ECUs. You can assess the blast radius, compare it to risk in other subsystems, make a triage decision, and know that decision is recorded and attributable.
That is not just better tooling. It is a different category of question.
The Handoff Problem Makes This Worse
The visibility gap compounds when you try to share your product's risk posture outside your team.
Today, the standard mechanism for external sharing is a software bill of materials (SBOM) export. But most SBOM exports are flat: a list of components, without the hierarchy that gives those components meaning. When you hand a flat SBOM to a customer, an auditor, or a regulatory body, you are giving them a parts list without a blueprint. They can see what components are present. They cannot see how those components relate to the system, what triage decisions have been made, or what the aggregate risk picture looks like.
The recipient is left to reconstruct the context that your team already built and then stripped out during export. If they re-import the file, they lose the structure. If they just read it, they are missing the full picture. Either way, the work your team put into understanding your product's risk does not travel.
This is not a minor inconvenience. For defense contractors subject to Foreign Ownership, Control, or Influence (FOCI) reviews, for medical device manufacturers submitting to the FDA, for automotive OEMs proving compliance with the BIS connected vehicles rule: the quality of what you can share directly affects whether you can close a deal, pass an audit, or ship a product.
What We Built
Manifest Product Hierarchy gives security teams the ability to model their products the way those products actually exist, as systems made up of subsystems, made up of components.
Teams organize their products in Manifest once. Risk rolls up the tree automatically. When a new vulnerability surfaces, teams see immediately which products are affected, where in the hierarchy the exposure sits, and what needs to move first.
And now, that full picture is portable. This release adds the ability to export complete product hierarchies with sub-products, assets, and vulnerability triage decisions intact. The structure travels. The context travels. Recipients do not get a parts list. They get a source of truth.
When you import a hierarchy someone has shared with you, you get the same thing back: relationships, identifiers, and disposition data preserved. No reconstruction required.
Why This Matters Now
The regulatory environment is moving toward product-level accountability, not component-level compliance.
The FDA does not want a list of libraries. It wants evidence that a device manufacturer understands the risk profile of a device. DoD does not want an SBOM per repo. It wants assurance that a contractor can identify and respond to risk across the platforms they build and deliver. The BIS connected vehicles rule does not assess codebases. It assesses products.
The tools teams have been using to satisfy those requirements were built for a different question. Product Hierarchy is built for the question regulators are actually asking.
The Bottom Line
Your security tools were built around the repository because that is where vulnerabilities live. But your customers do not buy repositories. Your regulators do not certify repositories. Your incident response teams do not patch repositories in isolation.
They work with products. The sooner your security tooling reflects that, the sooner you can close the gap between what you know about your software and what you can actually do about it.
See how the Manifest Platform can help your team mitigate risk across your products and systems.
