We Built It Backwards: From a Services Shop to a Product-Portfolio Risk Register

Most product-security tools start as a slide.

Someone imagines a workflow — what a risk-tracking process should look like, for example — builds the software to match the picture, and then goes looking for engineers willing to bend their actual work to fit it. The product comes first. The practice gets retrofitted around it, usually badly, and the engineers who have to live in the thing can feel exactly where the imagined workflow and the real one don't line up.

We went the other way. VSEC Core — the risk register at the center of our platform — is the tooling we built to do our own work, codified after years of doing that work by hand inside customer teams. Not a roadmap someone dreamed up in a planning meeting. The practice first; the product second.

This is the honest version of where it stands and why we think the order matters.

Years as a services shop, doing the unglamorous part

For most of our history, Block Harbor was a services shop. We sat inside customer teams and solved problems that didn't have a named solution yet: tracking which components lived on which vehicle line, attaching the risks we found to the specific things that carried them, running test cases against real hardware, and keeping all of it straight as programs changed underneath us.

That last part is the part nobody puts on a slide. The scaffolding — the asset lists, the per-component findings, the test cases you can run again next quarter without rebuilding them — is what makes security work repeatable instead of a one-time heroics exercise. It's unglamorous. It's also where almost all the leverage hides, because the alternative is redoing the same analysis on the next program as if you'd never done it before.

We did that by hand, across enough programs and enough years, to feel exactly where it breaks. The tooling came out of those breakages, one at a time. That's the difference between building from practice and building from a picture: every piece of VSEC Core exists because doing the work without it hurt in a specific, locatable way.

What VSEC Core actually is: the asset spine and the risk register

Strip away the names and the lifecycle diagram, and the heart of the platform is two things that depend on each other.

The first is an asset spine: a structured inventory of the real components in a vehicle line, modeled the way the vehicle is actually built. Assets relate hierarchically, vehicle to component to feature (or whichever hierarchy you configure), in a many-to-one and one-to-many relationship, so a single module (or feature/chip/etc.) can be tied to every program that carries it. This isn't a spreadsheet of part numbers. It's the structure that lets you say this exact thing exists in these exact places, and then reason about it. The best part about this is that assets don't even need to be created manually as our tool can help generate them from publicly available information to get started!

The second is a risk register that hangs off that spine. Every piece of per-component security work (a TARA result, a pen-test finding, a CVE, a firmware-scan result) gets stored against the asset it belongs to, instead of living in a document somewhere that the next engineer will never find. The register is built to correlate those sources into atomic risk units against the asset tree. The intended payoff: a risk closed once at the module level propagates to every vehicle and instance that carries that module, rather than being re-litigated program by program.

That reuse is the whole point. The value of an asset spine plus a register isn't the database — it's that the second program inherits the first program's work. TARA results and findings stop being one-shot deliverables and start being a portfolio you build on.

This capability — risk and asset management — is built and in production use today. It is the part of VSEC we are most confident standing behind, because it's the part that came most directly out of work we actually did.

How the rest of the platform hangs off the spine

Once the asset spine exists, a surprising amount of work stops being a separate tool and starts being a query against the structure you already have.

The clearest example is country-of-origin detection. Rule 791D bars connected-vehicle hardware and software tied to entities owned by, controlled by, or subject to the jurisdiction of certain foreign adversaries — an ownership-and-control test, not a question of where code happened to be typed. OEMs have to prove the absence of that content continuously, not once, because the supply chain keeps moving under an annual signature. The hard part isn't malice. Suppliers genuinely don't always know what's buried inside their own components past a certain depth, so an honest "we don't know" is the normal state, not the exception.

Here's the part that matters for this story: country-of-origin detection isn't a separate product we bolted on. It's a byproduct of having an asset spine. A partner firmware scanner reverse-engineers a binary into a software bill of materials and tags country of origin; VSEC ingests that result by logging the firmware as an asset and storing the findings as risks against it. The scan resolves from a high-level vehicle all the way down to individual software and hardware elements, and it lives in one place against the rest of the portfolio's risk. The asset spine is what made the determination possible at all. The same is true of the other monitoring and design work: when the structure is right, the features fall out of it instead of being invented next to it.

That's what "built backwards" buys you. Build the spine from real work, and the workflows you'd otherwise have to imagine turn out to already be sitting there.

Where it actually is right now

We are not going to oversell this. Here is the honest maturity picture as of mid-2026:

• Risk and asset management — the asset spine and register — is built and in production use. This is the center of gravity and the part we stand behind hardest.
• Country-of-origin detection is built and in beta use with a customer. It works; it has already surfaced restricted-region content that supplier surveys missed. It is beta, and we'll call it beta.

The reason we can be this precise about maturity is the same reason the tool exists: it came out of real engagements, so we know which parts have been load-tested by actual work and which parts are still earning that. A tool built from a slide can't tell you that. A tool built backwards can.

If you're the one already doing this by hand

This is written for the product-cyber director or practitioner who is currently keeping the asset spine in a spreadsheet (or in your head), re-running the same analysis every program, and feeling exactly where that breaks. You're the person we built this for, because you're the person we were.

If that's you, the most useful thing you can do is tell us where your current process hurts — which part of the asset-and-risk grind eats your team's time, where the reuse should happen and doesn't. We're building VSEC Core from real practice, and that conversation is what keeps it honest.

If you'd rather poke at something concrete first, the free tier of VSEC is the low-friction way in: sign up for free, model a piece of your asset tree, and see whether the spine holds the shape of your real work. That's the only test that matters.

‍