摘要：普渡大学等机构针对面向军人群体推广的移动应用研究发现，64%的样本包含第三方SDK，7.4%包含按美国国防部口径归为“对手国家”的第三方代码。事件关键不在于证明这些SDK已经窃取数据，而在于开发者可能并不掌握传递依赖和后续更新能力。
2026年7月，普渡大学、美国西点军校、佛罗里达国际大学等机构发表了一项针对“面向军人群体推广的移动应用”的研究。
研究团队从Google Play和军事社区论坛中整理出242款应用，其中223款完成了静态分析、动态分析和网络流量测试。这些应用包括军衔与制服查询、晋升考试辅导、军事基地评价、银行服务、健康管理和军人社交等工具。
研究发现，64%的应用包含至少一个第三方SDK；15.3%的应用包含来自美国以外地区的第三方代码，其中7.4%包含研究人员依据美国国防部口径归为“对手国家”来源的第三方代码。研究人员还在12款应用中发现华为HMS Core，在两款俄罗斯公司开发的应用中发现Yandex广告服务。
这些数字需要准确理解。
64%指的是使用了第三方SDK，包括Google Firebase、Crashlytics、AdMob和Facebook Analytics等常见组件，并不代表64%的应用都包含中国或俄罗斯代码。论文中“对手国家来源第三方代码”的比例为7.4%。
研究也没有发现相关应用将数据主动发送至华为或俄罗斯服务器。论文讨论的是代码来源、后续更新能力和潜在的数据访问风险，不能据此认定这些SDK已经从事间谍活动。
这项研究揭示的核心问题，是现代软件很难只由开发者自己编写。一个看起来简单的手机应用，内部可能包含几十个SDK、开源库和间接依赖。应用开发者有时甚至不知道最终安装包里进入了哪些代码。
手机应用为什么离不开SDK
SDK是软件开发工具包。
应用需要推送通知、统计活跃用户、显示地图、处理支付、上传图片或者分析崩溃日志时，开发者通常不会从头编写全部功能，而会接入已经完成的SDK。
例如，一款军营住宿评价应用可能需要：
用户登录；
地图定位；
图片上传；
消息推送；
崩溃分析；
访问统计；
云端存储。
每增加一项功能，就可能增加一个外部组件。
这种开发方式大幅缩短了产品周期。团队只需调用现成接口，即可获得较成熟的功能。与此同时，SDK代码会进入应用进程，取得相应权限，并可能与外部服务器通信。
研究分析的应用中，59%使用Google Firebase Analytics，50%使用Crashlytics，20%使用AdMob，16%使用Facebook Analytics。41%的应用包含1至3个第三方库，23%的应用包含4个以上，少数应用包含超过10个。
开发者发布的是一个应用，用户手机运行的却是一组来自不同公司的代码。
开发者没有主动选择华为SDK
论文记录了一款名为Hots&Cots的应用。
这款应用类似军事基地内部的点评平台，军人可以报告住宿和餐饮条件。研究人员发现，它的安装包中包含华为HMS Core。
应用开发者得知情况后表示担忧，并联系了消息推送服务商OneSignal。调查显示，华为代码通过第三方通知组件的依赖关系进入应用，并非Hots&Cots开发者主动接入。
没有得到服务商回应后，开发者重新搭建了消息通知系统，更换供应商并移除了相关代码，还向用户说明了处理结果。
这个案例展示了软件供应链中常见的三级结构：
应用依赖通知SDK；
通知SDK继续依赖其他组件；
下级组件又可能包含新的库和服务。
开发者通常熟悉第一层依赖，却未必完整掌握第二层、第三层。
在Java、JavaScript、Python、Android和云原生软件中，这种传递依赖十分普遍。一个看似普通的功能包，可能自动拉入多个辅助组件。应用代码中找不到某个厂商名称，并不代表最终产品没有使用该厂商的代码。
这也解释了为什么仅向开发人员询问“是否接入过某个SDK”并不可靠。
需要直接检查构建产物和安装包。
代码来源和数据流向是两个问题
应用包含某个国家或企业开发的代码，不等于用户数据必然发送给该企业。
SDK可能只在本地运行，也可能处于未启用状态。部分代码虽然存在于安装包中，却没有被调用。
研究人员通过网络流量测试，没有观察到数据发送至华为服务器，也没有发现俄罗斯SDK将数据主动传往俄罗斯服务器。
代码来源仍然具有安全意义。
一段进入应用的SDK可能拥有以下能力：
读取设备标识；
访问定位信息；
收集应用使用记录；
读取图片和文件；
连接外部服务器；
下载配置；
接收远程更新；
改变数据采集行为。
研究人员担心的是后续变化。
应用商店审核时表现正常的SDK，可以在新版本中增加数据收集功能。开发者升级依赖后，新代码会进入应用；部分SDK还可以通过远程配置改变行为。一次检查无法覆盖未来所有版本。
因此，代码来源、权限范围、数据流向和更新机制需要分别检查。
把某个国家列入黑名单，只能处理其中一部分风险。
俄罗斯代码也通过多种路径进入应用
论文识别出两款由俄罗斯公司开发、面向美国军人用户的应用，它们使用Yandex广告服务。
附录还列出了其他包含俄罗斯第三方组件的应用，包括使用Pushwoosh推送服务的美国空军相关应用。论文将这些组件列入代码来源统计，但没有观察到相关应用向俄罗斯服务器泄露数据。
这里存在几种不同情况：
应用本身由外国公司开发；
美国开发的应用主动接入外国SDK；
SDK通过上级组件间接进入；
组件最初来自某国，后续公司注册地或控制权发生变化；
服务商在全球多个地区部署服务器。
这些情况的风险不能只依据一个“所属国家”标签判断。
安全审查还要回答：
谁维护代码；
谁可以发布更新；
数据最终传到哪里；
服务器受哪一地区法律管辖；
SDK能够调用哪些系统权限；
应用能否在没有通知用户的情况下更换组件。
国籍提供风险线索，技术能力和控制链条决定具体影响。
隐私标签没有覆盖完整行为
研究团队还比较了应用商店中的隐私声明与实际测试结果。
40%的应用至少存在一项差异：应用实际收集或共享的数据，比Google Play“数据安全”栏目或苹果隐私标签中声明的更多。未披露的数据包括姓名、电子邮件、电话、地址和其他个人信息。
这不一定意味着开发者故意隐瞒。
隐私标签通常由开发者自行填写。出现差异可能有几种原因：
开发者不了解SDK收集了哪些数据；
应用升级后没有同步修改声明；
同一SDK在不同配置下行为不同；
第三方库增加了新功能；
开发者只记录了业务代码的行为；
后端服务器继续共享数据，手机端无法观察。
研究方法本身也存在边界。论文只能观察设备到服务器的通信，数据到达应用后端后是否继续转发，研究人员无法完整追踪。代码来源判断也部分依赖应用商店中的开发者地址，这些信息可能不准确。
因此，40%代表测试发现的可观察差异，不应简单理解为40%的开发者实施了欺骗。
它说明依赖人工填写的隐私标签，很难完整反映复杂的软件供应链。
军事品牌反而会降低用户警惕
研究团队还调查了103名军方相关人员，包括现役军人、退役军人、预备役和国民警卫队成员、国防部文职人员及军人家属。
在能够进行应用行为交叉比对的受访者中，83.5%至少使用过一款会收集或请求其本人认为不合适数据的应用。相关受访者平均使用3.31款令其感到不安的军事类应用。
调查还发现，当应用明确以军事服务、军人社区或部队工具的形象出现时，用户对数据收集的容忍度会提高。
同样是收集基地、军种和定位信息，用户面对普通商业应用时更加警惕，面对带有军事标签的应用时更容易信任。研究人员认为，这种信任与应用内部复杂的SDK结构并不匹配。
“军人专用”“国民警卫队服务”“部队生活工具”等名称，可能让用户误认为应用已经接受官方安全审核。
实际上，一些应用由个人、小型公司或普通商业服务商开发。面向军人推广，不等于获得军方批准。
品牌传递了可信感，代码供应链却可能与普通消费应用完全相同。
普通消费数据到了军人手中，风险会发生变化
广告和分析SDK收集的信息，单独看可能很普通：
设备型号；
广告标识符；
大致位置；
应用打开时间；
使用频率；
兴趣标签；
网络地址。
当这些数据长期汇总，并与军种、基地、工作岗位和社交关系结合后，可以形成个人活动规律。
研究中的受访者认为，这些信息可能用于分析生活轨迹、识别人际网络、实施社会工程攻击、寻找部署规律或判断设施活动周期。
同一项定位数据，对普通用户可能意味着广告推荐；对特定岗位人员，可能涉及基地位置、值班规律和家庭住址。
风险来自数据的组合。
软件审查因此不能只问“是否收集敏感数据”。还要查看多个普通字段组合后，能否推断出敏感身份和活动规律。
软件物料清单要记录间接依赖
解决这类问题，需要让软件成分更加透明。
软件物料清单，也就是SBOM，用于记录一个软件产品包含的组件、版本及供应链关系。美国网络安全和基础设施安全局将其视为软件供应链风险管理的重要基础，NIST也认为SBOM有助于提高组件来源透明度，并加快漏洞定位和修复。
一份可用的移动应用SBOM至少应记录：
直接接入的SDK；
SDK继续引入的传递依赖；
每个组件的版本；
组件维护者和发布地址；
组件签名和哈希值；
许可证；
可访问的权限；
可能连接的网络域名；
更新方式；
已知漏洞。
只列出一级依赖，无法发现Hots&Cots案例中的问题。
SBOM还需要和每次构建绑定。应用版本更新后重新生成清单，比较新增、删除和升级的组件。某个通知库突然增加地图、广告或存储模块时，审核系统应当发出提示。
一次上架审核不够
应用商店通常在产品上架和版本更新时开展审核。
SDK风险具有持续变化特点。
开发者可以更换依赖；
SDK厂商可以发布新版；
远程配置可以调整功能；
公司可能被收购；
域名和服务器可能迁移；
代码签名和控制权可能变化。
研究参与者最支持的措施，是手机在检测到外国或来源不明的第三方代码时发出提示。限制数据经纪商交易军方人员数据、对隐私声明进行独立审计、加强外国SDK限制，也获得了较高支持。
对高敏感行业来说，应用安全需要持续监测：
安装前分析软件成分；
安装后观察网络行为；
升级时比较组件变化；
定期核验服务器和域名；
高风险权限发生变化时重新审批；
组件维护者或所有权变化时重新评估。
这套机制同样适用于政务、能源、金融和工业软件。
只禁外国代码会遇到现实困难
按照来源国家禁止SDK，执行起来并不简单。
一个组件可能由外国团队开发，却托管在美国云平台；
一家美国公司可能包含多个海外研发团队；
开源项目没有单一公司控制；
公司注册地与数据处理地可能不同；
代码经过收购后控制权发生变化；
美国SDK也可能过度收集数据或出现漏洞。
研究样本中最常见的第三方组件来自Google和Facebook。即使排除全部外国SDK，应用仍然可能把大量行为数据发送给美国广告和分析平台。
因此，安全规则需要同时评估四个方面：
来源：代码由谁开发和维护。
能力：代码可以访问哪些数据和系统资源。
流向：数据发送到哪些服务器和服务商。
控制：谁可以更新代码、修改配置和改变行为。
国家来源可以作为加权因素，不能代替这四项检查。
企业也会遇到同样的问题
这项研究针对军事类移动应用，问题并不限于军方。
制造企业的设备管理App可能接入统计SDK；
医院移动系统可能包含第三方推送组件；
政务小程序可能依赖地图和身份认证服务；
工业软件可能嵌入国外开源库和商业模块；
企业数字员工可能调用多家云端API。
采购方看到的是一个供应商名称，实际软件内部可能连接几十家公司。
企业在招标和验收时，应要求供应商提交：
完整软件物料清单；
第三方组件用途说明；
数据采集和传输清单；
境外服务器和跨境数据说明；
组件升级与漏洞响应机制；
供应链变更通知制度；
关键SDK替换方案。
供应商更换一个消息推送、地图或统计组件，可能改变数据流向。此类变化需要进入合同和运维管理，不能完全交给开发团队自行处理。
软件供应链安全要看“谁能碰到数据”
这项研究没有证明华为或俄罗斯SDK已经窃取美军数据。
它证明了另一件事：面向敏感人群的应用，也可能在开发者和用户不知情的情况下，带入来源复杂的第三方代码。
应用商店标签没有完全覆盖实际数据行为；
开发者未必掌握传递依赖；
用户会因为军事品牌降低警惕；
一次审核无法覆盖组件后续更新。
软件供应链的管理对象，也就不能停留在应用开发商名单上。
还要继续向下追踪：
这个软件包含什么；
这些组件来自哪里；
它们拥有何种权限；
数据会流向谁；
未来由谁更新。
当企业能够回答这些问题，才有条件判断一个SDK是否适合进入关键系统。
参考资料
Joshua Shinkle等：《No Privacy for Privates: How Military Communities Experience and Perceive the Privacy Risks of Military-Marketed Mobile Apps》，Proceedings on Privacy Enhancing Technologies 2026年第4期。
美国网络安全和基础设施安全局：Software Bill of Materials。
美国国家标准与技术研究院：Software Bill of Materials。