More than one in eight mobile apps used by US military personnel ship code from companies based in China or Russia. 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 isn't about the military, isn't about China or Russia specifically, and isn't 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: 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.
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:
What procurement is actually buying:
- A publisher of record
- The SDKs that publisher chose to embed
- The open-source libraries those SDKs depend on
- The maintainer communities responsible for keeping those libraries current
- The package repositories those libraries are pulled from
- A chain of indirect, transitive dependencies that nobody upstream enumerated and nobody downstream requested
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 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.
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.
| Question | Starlink Device | Mobile App Dependency |
|---|---|---|
| Was origin identified? | Yes | Often no |
| Was risk reviewed? | Yes | Often no |
| Was approval explicit? | Yes | No |
| Was decision reversible? | Yes | Difficult |
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:
- Do we inventory third-party SDKs embedded in the software we run?
- Do we inventory the transitive dependencies those SDKs pull in?
- Do we know who maintains them?
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:
Diagnostic: "If this component were its own company, would it be reviewed?"
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.
Architect's Verdict
The problem wasn't that foreign code existed inside military-used applications. The problem was that nobody classified that code as a supplier relationship in the first place — which meant the vendor review process never had a reason to look at it.
Organizations maintain mature processes for reviewing vendors. Modern software increasingly depends on suppliers that never enter the review process at all — not because the process failed, but because the thing that needed reviewing was never named as a thing.
The Dependency Assurance Gap asks what happens when a trusted dependency outgrows the assumptions used to evaluate it. This is a different but related problem: dependencies that never entered evaluation to begin with.
Most organizations maintain inventories of vendors. Far fewer maintain inventories of suppliers.
Originally published at rack2cloud.com
Top comments (0)