Your Vendor Review Process Never Saw The Real Supplier

Every vendor review process assumes it’s evaluating a supplier — but a scan finding foreign-origin code embedded in more than one in eight mobile apps used by US military personnel makes the actual assumption visible: organizations review the company they bought from, not the code that arrived inside what they bought.

The Finding

The signal itself is narrow, and it’s worth stating plainly before drawing any lesson from it: a scan of mobile applications used by US military personnel found code of Chinese or Russian origin embedded in more than one in eight of them. Not malware. Not an intrusion. Code that arrived as a normal part of how those apps were built, sitting inside supply chains that were never classified as supply chains in the first place.

That’s the whole finding. Everything that follows is not about the military, not about China or Russia specifically, and not about mobile apps as a category. It’s about what the finding exposes: a governance blind spot that happens to have surfaced here first, and will surface somewhere in your own estate next.

The Vendor Wasn’t The Dependency

Walk through how that code got approved, because nothing about the process was negligent. Procurement reviewed the publisher — corporate entity, jurisdiction, app-store listing, terms of service. Security reviewed the application — permissions requested, network behavior, code-signing status. Every function in that chain did its job, on the scope it was handed.

Nobody reviewed embedded code ownership. Not because it was skipped — because it was never assigned to anyone as a thing to review. The publisher is not the dependency. The application is not the dependency. The dependency is what’s actually linked into the build, and that layer sits below every review gate procurement and security currently operate.

Where The Vendor Review Process Stops

The vendor review process, as most organizations run it, stops at the boundary of the thing they signed a contract for. It was never built to reach past that boundary into what the contracted thing is actually made of — and nobody redesigned it to, because nobody named the layer underneath as something that needed reviewing.

Modern Software Has More Suppliers Than Procurement Can See

This is the actual argument, and it’s bigger than any single finding.

Most organizations can name exactly who sold them their laptops, their firewalls, their SaaS platforms, their cloud capacity. Ask what procurement believes it’s buying when it approves a mobile app, a security product, or a cloud service, and you’ll get a clean answer: a publisher, a company, a single accountable vendor.

Ask what it’s actually buying, and the answer gets long fast:

None of that chain shows up on a vendor scorecard. None of it has a jurisdiction field, a security questionnaire, or a renewal date. None of it ever triggers the vendor review process, because none of it presents itself as a vendor. It arrives bundled, silently, inside something that already passed review under a completely different name. It’s the same gap Nobody Buys Capability Anymore. They Buy a Promise. describes from the opposite side — that piece is about how organizations evaluate a vendor once one is on the table. This is what happens when there was never a vendor on the table to evaluate in the first place.

The farther organizations move from infrastructure procurement toward software consumption, the less visibility they have into who actually supplies the code.

That’s the same underlying shape the Automation Validation Tax (Framework #172) names for automated systems generally, one layer up: dependency scope — SDKs, transitive libraries, build-time packages — kept expanding, and the review capacity meant to verify each layer never expanded with it. Procurement isn’t failing to review vendors. It’s staffed to review a dependency graph three layers shallower than the one that actually ships.

That’s the sentence to sit with. It’s not a mobile-app problem or a military problem. It’s what happens anywhere procurement’s mental model is still Vendor → Product, while the actual architecture underneath is Vendor → Application → SDKs → Libraries → Open Source Packages → Build Dependencies.

That build-dependency layer isn’t hypothetical. It’s where OpenAI’s own models found a previously unknown vulnerability in JFrog Artifactory this month — the artifact repository resolving Docker images, Maven artifacts, npm packages, and ML model artifacts for build pipelines everywhere, never reviewed as a supplier because nothing about it presents as one. AI Models Found and Exploited a Zero-Day Before the Patch Window Closed covers the incident directly; the failure mode is the same one this post names, one link further down the chain — a dependency operating below every review gate procurement and security currently run, at the infrastructure layer instead of the application layer. The same false-clearance shape shows up one layer up the stack, at the point of human sign-off rather than automated scan: GhostApproval found AI coding agents whose approval dialog described a harmless file write while the system executed a different one — a review gate that fired, was answered, and cleared an action nobody actually reviewed.

Reviewed Supply Chain vs. Unreviewed Supply Chain

The same week this scan surfaced, a separate and almost inverse event was unfolding: Starlink secured an FCC exemption allowing routers manufactured in Vietnam — foreign-origin hardware — into the US market. On the surface, that looks like the opposite finding: foreign origin, permitted rather than flagged.

It isn’t the opposite finding. It’s the same finding with one variable changed.

The difference was not foreign origin. The difference was visibility.

One foreign-origin component went through an identifiable regulatory body, got a named exemption, and remains a decision someone can point to and, if needed, reverse. The other arrived as an unlabeled line in a dependency tree that nobody was assigned to read. Same category of risk. Completely different governance posture — because one crossed a review gate and the other never encountered one.

The Dependency Classification Test

This is the part that turns observation into something you can actually run against your own estate.

Three inventory questions. Most organizations already know their honest answer is no to all three, and that’s not the point where the gap becomes actionable. This is:

If the answer is yes — this thing would clearly trigger the vendor review process if it showed up as a standalone supplier — but it never went through review because it arrived bundled inside another product, you’ve just located the exact governance gap this post describes. Not hypothetically. In your own stack.

The same blind spot has a consequence dimension worth naming before closing: an unreviewed dependency doesn’t just risk going unnoticed, it can leave an organization holding consequence for infrastructure it never had standing over in the first place. The Breach Wasn’t Stadler’s. The Consequence Was. covers the case where that dependency was shared infrastructure rather than an embedded SDK — Stadler bore the ransom demand and the press attribution for a breach on a platform it shared with a supplier, a boundary its own vendor-risk process never drew any more than procurement drew the SDK boundary here. Same missing question, different layer: if this component — or this platform — were reviewed as its own accountable party, would anyone have priced what happens if it’s the one that gets breached?

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →