Topic starter
11/11/2026 5:56 pm
TL;DR: Risk becomes reusable when Block Harbor ties findings to an asset spine instead of leaving them in separate documents. Vehicle security teams can then carry forward component-level results across programs instead of rebuilding the same analysis each time.
Editorial analysis by NHI Mgmt Group, based on content published by Block Harbor: “We Built It Backwards: From a Services Shop to a Product-Portfolio Risk Register”.
Key questions
Q: Why does a risk register fail without an asset tree?
A: A risk register fails without an asset tree because risks are left detached from the systems, components and owners they affect.
Q: What is the best way to reuse security findings across product lines?
A: The best way to reuse security findings across product lines is to normalise them against shared components, common attack patterns and a stable asset model, then store them once with clear applicability rules.
Q: How do hierarchical asset models improve vehicle security governance?
A: Hierarchical asset models improve vehicle security governance by organising the vehicle, ECU, software, interfaces and suppliers into parent-child relationships, so controls, ownership and risk can be traced to the right component.
Practitioner guidance
- Map the real asset hierarchy first Build the vehicle, component, and feature hierarchy before layering risk tracking on top, so the register reflects how the programme is actually assembled.
- Attach every finding to a specific component Store TARA results, CVEs, pen-test findings, and firmware scan output against the asset they affect, not in separate documents or team folders.
- Propagate closure across reused modules When a module-level risk is closed, carry that status to every program and instance that inherits the same module instead of reopening the same work.
Bottom line: The central governance problem is not a lack of findings, but a lack of structure that lets those findings follow the real asset.
Glossary terms: Risk Register, TARA, Country-Of-Origin Detection, Software Bill of Materials
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:07 pm
Asset structure is the governance control, not just the database. The practical failure in product security is usually not that teams lack findings, but that findings sit outside the structure that defines what the organisation actually ships. When the inventory model mirrors the engineering model, risk becomes reusable across programmes instead of being re-created by hand. That shifts governance from document management to asset-linked decision-making.
A question worth separating out:
Q: How should teams govern supplier scan results in connected systems?
A: Teams should govern supplier scan results by tying each finding to the affected asset, contract scope and remediation owner, then validating whether the issue is inherited, duplicated or newly introduced. A central intake process, severity normalisation and evidence retention help prevent scan noise, missed follow-up and inconsistent treatment across connected systems.
👉 Read our full editorial: Vehicle security governance needs asset hierarchies before risk registers