The SBOM Problem Isn’t Inventory. It’s Your Right to Prove Innocence.

There is a particular kind of panic that hits a connected-product business when a journalist, a regulator, or a customer asks a simple question: “What is that software doing in your product?”

Not “what do you believe it does,” or “what did your supplier tell you.” What does it do.

The moment suspicion shows up, your intent stops mattering. Evidence matters. That is why the most dangerous phrase in a connected hardware company is: “We think it’s fine.”

The recent story about a piece of software associated with spyware appearing on a license list for a Chinese EV maker is a perfect trigger to revisit the uncomfortable truth: you can wake up inside a national-security narrative even if you shipped no malicious code. If you cannot disprove the story quickly, you have already lost the first round.

An SBOM is necessary, but it is not sufficient. A spreadsheet of components will not save you when the pressure is on. What saves you is governance that connects three things into one defensible system: license hygiene, telemetry boundaries, and audit rights.

This is the playbook I wish every connected-product company adopted before the first scandal, not after.

1) Treat SBOM as a proof system, not a compliance artifact

Most teams approach SBOM as inventory. They want a list. They want a tool that outputs a list. They want to tick the box.

That mindset fails because the real question under scrutiny is not “what libraries exist,” it is “what can this product do, and who can change it.” An SBOM that cannot answer those questions under time pressure is theater.

So define your SBOM outcome like this:

• I can map every shipped binary to a source, a license, an owner, and a build pipeline.
• I can map every data flow to an explicit purpose and retention policy.
• I can show who has update authority, how updates are signed, and how I would stop an update stream if needed.

If you cannot do those three things, you do not have an SBOM program. You have a file.

2) License governance: make “unknown component” impossible to ship

License lists become public in messy ways: procurement questionnaires, customer security reviews, partner audits, sometimes leaks. The fastest way to create suspicion is to publish a list where items look unfamiliar, generic, or mismatched to the product’s function.

The fix is not a better PR line. It is a better intake and approval system.

Set three gates, and keep them boring

1. Intake gate (before code lands). No third-party component enters the repo without a minimal record: name, version, origin, license type, purpose in the product, and the internal owner.
2. Build gate (before artifacts exist). CI fails if the component is missing from the manifest, has an unapproved license class, or is outside the allowed source registries.
3. Release gate (before customers see it). The release candidate must have a signed SBOM snapshot stored with the build outputs. Not “generated later.” Attached to that build.

Two practical rules keep this from dying:

• Make ownership explicit. Every dependency has a person accountable for it. Not a team name. A person.
• Ban “clipboard governance.” If approvals live in email and meetings, you will fail during an incident. Put approvals in the same system as code changes.

This is also where you stop the slow creep of “temporary” tooling. The tool that entered for a quick test stays forever, then ends up on a license list, then becomes a headline.

3) Telemetry boundaries: decide what you will never collect

Telemetry is the silent accelerant in every trust crisis. Many connected products could be defensible if the data path were narrow. They become indefensible when “diagnostics” turns into broad collection because it was convenient.

You need a telemetry constitution. Not a privacy policy written by committee, but hard boundaries engineers can implement.

Four decisions to lock this quarter

• Purpose. For each telemetry event, write the one sentence reason it exists. If it cannot be stated simply, kill it.
• Minimization. Collect the least granular data that still solves the problem. Aggregated counts beat raw streams. On-device processing beats cloud copies.
• Retention. Decide how long you keep it, and make deletion automatic. If deletion is manual, it will not happen.
• Separation. Keep product analytics, diagnostics, and security logs in distinct buckets with distinct access rules. Blending them is how “helpful data” becomes a liability.

The most important boundary is this: separate what the product needs to function from what the business wants to know. When those get mixed, you end up defending marketing curiosity as “essential operation.” Nobody buys it.

And yes, this is also about geopolitics. If you sell across borders, your telemetry design must anticipate the harshest interpretation. If a regulator assumes the worst, can you still show a narrow data path that makes the worst implausible?

4) Audit rights: your supplier contracts must survive suspicion

Most hardware companies are ecosystems. Modules, firmware, connectivity stacks, mobile SDKs, cloud services. When suspicion lands, your weak link is rarely your own code. It is the thing you integrated because it “worked” and “came from a reputable vendor.”

In a crisis, reputation is not evidence. Contractual rights are.

Put these clauses in place before the deal is signed

• Right to inspect. Not vague “security cooperation.” A defined right to inspect relevant parts of the software supply chain, including build provenance and dependency lists.
• Right to independent testing. You can run third-party security testing on delivered artifacts and integrations without breaching terms.
• Update control and notification. You are notified of changes, you can defer or block updates, and you can require signing and attestation for updates.
• Incident cooperation with timelines. Response times, named escalation paths, and access to technical staff during an investigation.
• Geography and data processing boundaries. Where data is processed and who can access it must be contractually explicit, not assumed.

If you do not have these rights, you cannot run an investigation at the speed of headlines. You will be waiting for approvals while the story writes itself.

5) The lived lesson: suspicion moves faster than your release process

I have watched connected-product teams build excellent engineering discipline, then lose weeks because a single component could not be explained cleanly across firmware, cloud, and mobile. Not because it was malicious, but because nobody had end-to-end accountability for “what exactly is in this release” and “what exactly leaves the device.”

In those moments, the technical work is not the hardest part. The hard part is making a coherent, falsifiable statement under pressure, then backing it with artifacts that outsiders can trust.

That is why SBOM cannot be delegated to a security person with a tool. It is a cross-functional agreement between product, engineering, legal, and the people running commercial relationships. You are building a system that can answer hostile questions with calm precision.

When your product is accused of spying, your advantage is not outrage. Your advantage is a clean chain of custody for software and data.

This intersects directly with how you think about sovereignty and control. If you treat sovereignty as a purchase, you end up swapping vendors while keeping the same blind spots. The real shift is procedural and contractual. I wrote about that idea separately in Sovereign Compute Isn’t a Purchase. It’s an Operating Model.

What to do next: a 30-day SBOM readiness sprint

If you want this to be real within a month, not “a program,” run a sprint with one goal: pick one shipped product and make it provable.

1. Pick the product and define scope. Device firmware, mobile app, cloud services, CI pipeline, and the top five suppliers. Keep it tight.
2. Generate a baseline SBOM snapshot. For each shipped artifact. Store it with the build outputs. Make it retrievable in minutes.
3. Red-team your own narrative. Ask: if a journalist claimed this component is spyware, what would we show in 24 hours to refute it?
4. Lock telemetry boundaries. Write the event catalog. Delete anything without a purpose line. Add retention defaults.
5. Patch contracts where it matters most. Start with the supplier whose code you least understand and depend on most.
6. Run an incident drill. Simulate a “suspicious component discovered” scenario. Time-box the response. Measure how long it takes to produce evidence, not opinions.

If the drill reveals you cannot answer quickly, that is a gift. It means you found the fracture before the public did.

My view: trust is a product feature, and it has to compile

National-security narratives do not wait for internal alignment. They fill the vacuum you leave when you cannot prove what is in your product and what your product does.

So build proof early. Make unknown components unshippable. Decide what you will never collect. Put audit rights into contracts before you need them. Then rehearse the ugly day, because the ugly day is coming for someone in your category.

If you do this well, the SBOM is not a bureaucratic output. It is a competitive advantage: you ship faster with less fear, you answer enterprise security reviews with clarity, and you do not get trapped in a story you cannot disprove.