The empty attestation: why a supplier letter isn't proof

Every connected vehicle sold in the US after model year 2026 needs a Declaration of Conformity — a CEO-signed attestation, filed annually to BIS, that no Chinese- or Russian-origin software runs the vehicle's connectivity or driving systems. The penalty for signing a false one runs to $1M in civil fines and twenty years of criminal exposure. We covered what the rule actually bans, who it targets, and the model-year timeline in our Rule 791D explainer; this isn't that. This is about what happens after you've read the rule and have to actually sign something.

Here's the uncomfortable part nobody puts in the compliance deck: the rule lets you file an attestation that means almost nothing. You can email your suppliers, collect their letters back, staple them together, and sign. That clears the paperwork bar. It also bets that Commerce never checks, and that every supplier in your chain actually knows what's inside the components they sold you. One of those bets is bad. The other is worse.

We help OEMs catch the supplier who's wrong — usually not the one lying, but the one who genuinely doesn't know what's inside the components they sold you.

‍

The attestation tells you what someone believes. It doesn't tell you what's true.

A supplier attestation is a statement of belief. It says: to the best of our knowledge, this component contains no restricted-region software. The problem is that "the best of our knowledge" is doing enormous load-bearing work in that sentence, and most suppliers can't actually back it.

This is the same blindness that produced the rule in the first place. An OEM struggles to answer "is there adversarial-nation code in my vehicle?" not because the question is exotic, but because it never built a structured inventory of what's in the vehicle to begin with. You can pass UN R155 type approval and still not be able to enumerate the software running on a given ECU down to the package. The China-software ban didn't create that gap. It just asked a question basic enough to expose it.

Your suppliers have the exact same gap. A Tier 1 can attest in good faith that it doesn't believe China is in its software — and be wrong, because it never mapped its own subcomponents past a certain depth either. The failure is almost never malice. It's that the supplier's belief was never grounded in a real inventory, so the letter you're stapling to your federal declaration is an uninformed guess wearing a signature.

A pile of those letters is an empty attestation. It satisfies the form and proves nothing about the vehicle.

‍

Secondary verification: the independent check on the supplier's belief

The fix isn't to distrust suppliers. It's to add a second, independent data point that doesn't depend on what anyone believes — and then look at whether the two agree.

That second point comes from the firmware itself. We integrate with a firmware-scanning pipeline — a specialized SBOM scanner that reverse-engineers a binary image into a software bill of materials, even when the supplier never handed one over. Each package in that SBOM gets correlated to the organization that maintains it, including where that organization actually operates, and when a package traces back to a restricted nation, it surfaces. VSEC ingests that result and stores it against the asset alongside everything else we know about it.

Now you have two sources sitting against the same component: the supplier's attestation, and what the firmware actually contains. Most of the time they agree, and that agreement is worth something — it's a verified attestation instead of a hopeful one. The value shows up when they don't.

We worked with a top-tier multi-brand OEM where a supplier attested, in good faith, that it didn't believe Chinese software was in its product. The scan of that firmware came back with substantial Chinese-origin software in it. A flat contradiction. The read wasn't that the supplier lied — it was that the supplier was never confident in its own statement to begin with, because it had the same asset-mapping blindness everyone has. The attestation was uninformed, not dishonest.

The OEM running the empty-attestation playbook never sees that contradiction. They collected the letter, filed it, and moved on, carrying restricted-region software into a CEO-signed federal declaration without knowing it. The OEM running secondary verification sees the disagreement and gets to do something about it before it becomes a falsified-declaration problem. Seeing the conflict is the entire product.

‍

How the synthesis actually works — and why it flags rather than decides

It's worth being precise about what the tooling does, because the honest version is more useful than the marketing version.

The firmware scan is one signal. It's a strong one, but it's a signal, not a verdict. Attribution — the call that a component carries China-linked software — is a synthesis. It combines the scan's country-of-origin result, the supplier's confirmation letters and attestations, any SBOMs the supplier did provide, and other context, all stored against the asset. The system reasons across those sources and highlights the potential for restricted-region software. Then it flags it for a human to review.

It does not adjudicate. We deliberately retreated from "detected" to "potential" in how this works, because "detected" implies a certainty that a single scan can't honestly carry. A human owner — supply-chain or product cyber — makes the call. The tool's job is to make sure the call gets made with every available data point in front of the person making it, not to make the call for them.

This is the asset spine doing the work, not a clever detector. Country-of-origin determination is a byproduct of having a structured inventory to hang findings on, not a standalone feature you bolt onto a chaotic supply chain. We covered why the inventory is the foundation in VSEC Core; this is the inventory paying off. Each vehicle line has its components mapped as assets. The firmware-scan results, the supplier letters, the SBOMs, the TARA outputs, the pen-test findings — they all attach to the asset they belong to and live in one place. A determination made about a module once carries to every vehicle that ships that module. That's what makes this auditable at the scale a DoC actually demands.

‍

The continuous trigger: a new build is the event

A Declaration of Conformity is annual and gets updated on any material change — a software update, a supplier swap, a discovery that a prior declaration was wrong. The supply chain doesn't run on an annual cycle. Firmware ships continuously.

So the check has to be continuous too, and it can't depend on someone remembering to upload an image. We hook into the OEM's firmware pipeline. A new build is the trigger. As firmware images flow through, the scanner evaluates them and the risk manager notifies the asset owner — in their inbox — when a new restricted-region signal comes off a scan. Continuous as long as firmware rides the pipeline, not continuous when someone gets around to it. The annual signature is backed by a process that's actually running between signatures.

‍

The null result: absence of evidence, not evidence of absence

There's a limit, and pretending there isn't would be exactly the kind of empty attestation we're arguing against.

Some firmware can't be meaningfully reverse-engineered. Heavily custom, proprietary images come back with nothing actionable — the scanner runs and finds nothing it can attribute. The wrong move is to render that as a green check. A null result is not a clean bill of health. It's an unresolved gap: absence of evidence, not evidence of absence.

So we represent it that way. The firmware image stays loaded in the continuous scan path and gets re-evaluated as scanning capability improves — the null is pending, not permanent. And the null does real work even before it resolves: it tells the OEM exactly where to spend scarce attention. The portfolio splits into two piles — components you can verify independently, and components where you're dependent on the supplier and need to escalate. For the first pile, verify it yourself. For the second, lean on the supplier and demand their source SBOM, because that's the only check you've got…although recent advancements in AI models (which we are also integrating into our system) potentially changes this dynamic as well, narrowing the gap between what the supplier 'must' provide and what a strong AI model can simply crawl through and grab in minutes.

‍

This was never really just a China story; it's an integrity story.

Step back from the rule and look at what the government actually said by writing it. Of the three properties security people care about — confidentiality, integrity, availability — integrity is the one that matters most for systems that move and decide in the physical world. The rule exists because prior regulation didn't deliver it. The proof is that a question this basic — does an adversarial nation have software or hardware in your vehicle? — turned out to be brutally hard to answer. That's an integrity failure, dressed up as a supply-chain rule.

Connected vehicles are the first physical AI deployed at scale — millions of machines making real-world decisions next to human beings. The country-of-origin question is the first time anyone has been forced to prove something about the integrity of what's inside them. It won't be the last. A humanoid robot working next to a person will need to be trusted, and trust comes from integrity — from being able to prove what's actually in the system, not from a letter saying someone believes it's fine.

That's the choice in front of every product-cyber owner right now. You can collect the letters and sign. Or you can make the attestation mean something — your suppliers' word, plus your own independent check, synthesized into a determination you can defend. We're building the second one. It's in beta with one OEM today, and we're looking for the next.

If you want to see what an attestation looks like when it's backed by what's actually in the firmware instead of what someone wrote in a survey, start with VSEC — or read our firmware-visibility writing for the mechanics.

‍