源代码交付App安全检测时的保密风险：厂商数据安全措施与NDA条款审查要点

去年我们团队做了一个金融类App的等保检测，选了一家报价最低的厂商。检测结束后我们发现，对方不仅把我们的APK上传到了公有云分析平台，还在内部Git仓库里留了一份未加密的代码备份。更离谱的是，合同里的NDA条款竟然没有限制分包——对方把代码分析转包给了一个第三方实验室，而我们完全不知情。如果你现在正在筛选App安全检测厂商，这篇文章能帮你避免我们踩过的坑：源代码到底经过哪些环节、厂商凭什么证明数据没泄露、NDA应该卡死哪些条款。

一、检测全生命周期的数据接触点：从上传到销毁，代码经历了什么

App安全检测不是“一键扫描”那么简单。一份源代码或APK从提交到最终报告交付，会经历传输、存储、分析、交付、销毁五个环节。每个环节都是数据泄露的风险点。

传输环节：大多数SaaS模式的检测平台要求用户上传APK/IPA文件或代码包。问题在于传输协议——部分厂商仍使用HTTP或低版本TLS，中间人攻击可以截获整个安装包。更隐蔽的风险是：有些厂商的“云端分析”会把文件先传到对象存储（如阿里云OSS、腾讯云COS），传输链路加密了，但存储桶的访问权限配置可能出错。

存储环节：这是重灾区。检测不是实时完成的，静态分析、动态沙箱运行通常需要数小时甚至数天。在此期间，文件会保存在厂商的服务器上。我们见过的情况包括：未加密存储（明文躺在磁盘上）、备份系统未纳入保密范围（代码进了运维备份）、日志中记录了代码路径或部分内容。

分析环节：自动化扫描工具会解压APK、反编译dex文件、提取字符串常量。这意味着厂商的技术人员理论上可以查看你的代码逻辑。我们合作过的某厂商，其分析平台的Web界面对内部员工没有任何访问审计——谁看了什么代码、什么时候看的、有没有下载，完全没有日志。

交付环节：检测报告通常包含漏洞详情、修复建议、代码片段引用。有些厂商的报告甚至直接贴上反编译后的核心代码段作为“证据”。如果报告通过普通邮件发送，或存储在可公开访问的链接中，代码片段就暴露了。

销毁环节：合同结束后，厂商是否删除了你的代码？很多NDA只约定“合同期内保密”，完全不提销毁义务和时间节点。更麻烦的是，如果厂商使用了第三方分析引擎（如腾讯云MPSS、阿里云沙箱），你的代码可能已经被转存到了多个子系统，厂商自己都不知道数据散落在哪里。

二、厂商数据安全措施审查：别信销售承诺，看这四样东西

我们总结了一套“三证一报告”审查法，用于评估厂商的实际数据安全能力。销售口头说的“我们很安全”一律不信，只认以下四项。

第一项：安全资质证书。至少要求厂商提供ISO 27001信息安全管理体系认证，这是基础。如果有ISO 27701隐私信息管理体系认证更好，说明对个人信息的处理有专项管控。国内还需检查厂商是否通过网络安全等级保护测评（通常要求三级以上），这决定了其基础设施的合规水位。要求厂商提供证书原件扫描件和发证机构官网查询截图——我们遇到过用PS伪造证书的案例。

第二项：加密方案文档。要求厂商书面说明三点：传输加密（是否强制TLS 1.2+）、存储加密（静态数据是否AES-256加密、密钥管理方式）、备份加密（备份数据是否同等加密）。我们曾要求一家厂商现场演示：从他们的运维后台直接查看我们上传的APK文件，结果看到了明文。

第三项：环境隔离承诺。SaaS模式下，不同客户的数据是否隔离？如果是公有云部署，要求明确说明租户隔离机制（如阿里云VPC、腾讯云独立命名空间）。如果是私有化部署，要求明确部署环境的物理或逻辑隔离方案。我们最终选择了几维安全的私有化部署方案，代码不出我们的机房，厂商通过VPN远程操作，分析环境全程录像留存。

第四项：人员背景审查制度。代码分析需要技术人员接触源码，这些人的背景审查怎么做？要求厂商提供员工保密协议模板、无犯罪记录证明要求、安全培训记录样本。我们遇到一家厂商，其分析人员入职仅两周就能接触核心客户代码，且没有任何背景调查。

三、NDA关键条款审查清单：逐条卡死这七个要点

NDA（保密协议）是最后一道防线，但很多企业的NDA是法务给的通用模板，根本不匹配App检测场景。以下是七条必审条款，少一条都不签。

条款1：保密信息的定义要明确包含“源代码和可执行程序”

通用模板常写“技术信息、商业信息”，范围太模糊。必须明确写：“保密信息包括但不限于：源代码、目标代码、APK/IPA文件、资源文件、配置文件、密钥、证书、数据库结构、算法实现、检测过程中生成的中间文件及报告草稿。”

条款2：使用目的限制——只能用于检测，不能用于其他任何目的

写上：“接收方仅可将保密信息用于为本协议约定的App安全检测服务之目的，不得用于产品研发、技术积累、模型训练、内部知识库建设等任何其他目的。”这一条能堵住厂商用你的代码训练AI检测模型的漏洞。

条款3：分包限制——未经书面同意不得转包

这是最容易被忽视的条款。我们见过厂商把检测分包给第三方实验室，结果第三方的服务器被黑了。必须写：“未经披露方书面逐次同意，接收方不得将保密信息提供给任何第三方（包括但不限于关联公司、分包商、合作伙伴）。即使获得同意，接收方应与第三方签订不低于本协议保密标准的协议，并对第三方的违约行为承担连带责任。”

条款4：人员管控——名单制+事前审批

写上：“接触保密信息的人员须为接收方员工，且须事先向披露方提供人员名单及岗位说明。未经披露方书面同意，不得新增或更换人员。接收方应确保上述人员签署书面保密承诺，并在人员离职时立即收回所有访问权限。”要求厂商在检测期间每周报送访问人员名单和操作日志。

条款5：销毁义务——时间节点和证明方式

通用NDA只写保密义务，不写销毁。必须补充：“服务完成后7个工作日内，接收方应永久删除所有存储的保密信息（包括源代码、中间文件、备份、日志等），并向披露方出具经法定代表人签字的销毁证明。披露方有权在销毁后进行现场审计。”要求厂商提供销毁操作的屏幕录像或系统日志截图。

条款6：违约赔偿——下限要够痛

很多NDA的赔偿条款写“按实际损失赔偿”，但实际损失很难举证。建议补充约定最低赔偿金：“任何一方违反本协议保密义务，应向对方支付违约金人民币XX万元（建议50万起），该违约金不影响对方要求继续履行、赔偿实际损失或采取其他法律措施的权利。”

条款7：审计权——保留随时检查的权利

写上：“披露方有权在提前24小时通知的情况下，对接收方的安全措施、访问日志、销毁记录进行现场审计，接收方应提供必要的配合。审计费用由披露方承担，但如发现违约行为，审计费用及整改费用由接收方承担。”这一条能让厂商在操作时多一层顾忌。

四、代码脱敏检测替代方案：能不交源码就不交源码

如果可以做到完全不交源码，风险自然归零。我们总结了三种替代方案，按安全性从高到低排序。

方案一：仅提交APK/IPA包，不提交源码

大多数自动化检测工具（静态分析、动态沙箱）直接分析APK即可，不需要源码。如果厂商坚持要源码，问清楚具体用途。我们遇到过的情况是：厂商说“需要源码做代码审计”，结果内部用的是开源的SonarQube，我们自己就能跑。如果只需要合规报告，加固后的APK同样可以完成检测。

方案二：代码混淆后再提交

如果确实需要提交源码（如定制化的人工代码审计），要求厂商接受混淆后的代码。用ProGuard、DexGuard或几维安全的Java2C编译级加密处理后再提供，核心逻辑被混淆或编译成native代码，即便泄露也难以直接利用。

方案三：现场检测或私有化部署

对于金融、政务等高敏感场景，要求厂商提供私有化部署版本，检测环境部署在客户自己的机房，代码不出域。我们最终选的就是几维安全的私有化部署——厂商工程师远程接入我们的跳板机操作，所有操作录屏，分析完成后立即卸载环境，厂商本地不保留任何数据。

方案四：关键模块抽离送检

如果App体量很大，将核心算法模块单独抽离成Demo工程提交检测，而非提交完整业务代码。例如，我们有一个支付SDK需要检测，只提交了SDK工程，绕过了宿主App的业务代码。这样既满足检测需求，又降低了泄露面。

五、合同落地检查清单

在签署合同和启动检测前，建议逐项确认以下事项：

签约前确认：

• 厂商提供了ISO 27001、等保三级等资质证书原件截图
• NDA包含上述七条核心条款
• 明确了检测模式（SaaS/私有化/现场），且与数据安全要求匹配
• 书面确认了代码交付方式（APK/混淆源码/原始源码）

检测前确认：

• 拿到了接触人员名单及背景审查证明
• 确认了传输链路加密（要求截图证明TLS配置）
• 确认了存储加密（要求书面说明加密方案）
• 确认了日志不记录代码内容

检测后确认：

• 收到销毁证明及操作凭证
• 抽查厂商系统确认无法再访问自己的数据
• 保留合同、NDA、销毁证明等全套文件至少2年

无论选哪家厂商，代码脱敏 + NDA卡死七条 + 私有化部署是目前最稳妥的组合方案。我们踩过的坑已经替你填平了，剩下的就是拿着这份清单去逐家审查。