原始候选包
构建完成后先冻结参与本次发布的输入版本，记录包名或 Bundle ID、版本、构建编号、架构范围、摘要和生成时间。它是后续保护、签名和回滚判断的比较基线。
先回答：什么是 APP 加固发布门禁
发布门禁是一组在发布前必须回答清楚的问题：这次交付从哪个原始候选包生成？采用了什么保护策略？最终签名和渠道是否可解释？哪些关键路径、系统版本、架构和依赖已经验证？哪些项目尚未覆盖？如果发生兼容异常，应该回到哪个候选版本？这些问题不应由截图、口头确认或单一工具结果代替。
对接入 APP 加固的团队，门禁的价值尤其明显。加固会引入保护策略、候选产物、签名责任、运行时观察和兼容回归；如果这些记录与业务构建链路脱节，即使“生成了加固包”，也可能在覆盖升级、渠道投放、Native 加载、第三方 SDK 初始化或关键业务路径中暴露问题。发布门禁的作用是让问题在灰度之前被发现，而不是在用户侧出现后才追溯。
御盾不把门禁描述为一次自动化操作或绝对安全保证。它应被视为一套工程治理框架：自动化负责减少遗漏和保留关系，人负责确定业务边界、例外审批、风险承受度与最终上线责任。
候选包不是一个文件名，而是一条可追溯关系
加固候选包
记录保护策略摘要、处理时间、产物摘要和与原始候选包的对应关系。策略可以按模块分层，但不能让不同候选包共用一份无法辨别的报告。
最终发布包
确认签名责任、渠道或商店目标、版本关系、安装升级结果和最终测试范围。最终发布包才是被提交、灰度或交付的对象，不应以中间产物替代。
回滚对象
明确异常发生后可以回退到哪个经过验证的版本，以及触发条件、批准人和业务侧处置方式。回滚不是“保留旧文件”，而是保留可再次验证的发布对象。
八个阶段，把安全保护纳入持续交付
冻结输入和版本身份
确定本次发布的原始候选包，避免测试完成后又替换输入。包名、版本、构建编号、架构与摘要等字段应在受控记录中一致。
选择保护范围与策略版本
按核心算法、协议、授权、风控、资源和普通界面的业务价值选择策略。不是所有代码都应使用最高强度，也不应只因性能担忧而整体关闭保护。
生成并绑定加固候选
将加固产物与原始候选、策略版本和处理记录绑定。若产物发生重建、重签、渠道处理或资源变更，应重新说明其与前一阶段的关系。
确认签名、渠道与商店目标
对 Android 关注签名关系、版本升级和分发目标；对 iOS 关注签名身份、Bundle ID、entitlements 与分发路径。不要在报告、脚本或聊天记录中暴露私钥和签名材料。
完成安装、启动和升级对照
原始包与加固包应在约定范围内对照首次安装、覆盖升级、启动恢复和核心初始化。仅能打开首页不等于应用可发布。
回归关键业务路径
由业务方定义登录、支付、实名、消息、定位、WebView、热更新或动态模块等最小路径。安全团队不应凭通用样例替代业务可用性结论。
核验性能、兼容与运行时证据
记录启动、内存、CPU、包体、Crash、ANR、系统、ABI 和第三方依赖覆盖范围。运行时异常信号应与服务端策略或人工复核相配合，避免客户端单点误伤。
阻断、例外、灰度与回滚
未通过的关键项必须真正阻断发布；例外要有明确范围和责任人；灰度观察和回滚对象必须可用。门禁报告应同时标出已通过、未通过、待复核和未覆盖项。
哪些情况应当阻止发布
| 风险信号 | 为什么不能忽略 | 建议处置 |
|---|---|---|
| 原始包、加固包和发布包无法一一对应 | 测试结论可能不属于最终交付物，发生问题后无法定位策略或构建差异。 | 冻结候选关系，重新生成报告并复测受影响路径。 |
| 签名责任或升级关系不清 | 可能造成覆盖升级失败、渠道差异或商店提交问题。 | 由发布责任人确认平台规则与签名关系，避免共享敏感材料。 |
| 安装、启动或关键业务路径失败 | 产物存在可用性风险，单一安全工具通过不能抵消业务失败。 | 按原始包、策略、依赖和系统维度缩小问题范围，保留最小复现条件。 |
| 性能或稳定性超过已同意阈值 | 启动、内存、Crash 或 ANR 的异常会直接影响用户体验和上线质量。 | 与原始包对照，明确是否由策略、依赖、业务改动或环境差异导致。 |
| 保护策略或未覆盖项不可追溯 | 团队无法解释本次安全边界，也无法为下一次发布复用结论。 | 补齐策略摘要、测试范围和未覆盖项；无法补齐时不应把结果标为通过。 |
| 不存在可用回滚对象 | 出现生产异常时只能临时重建，扩大处理时间和业务风险。 | 保留已验证版本、触发条件和负责人，再进入灰度或正式发布。 |
CI/CD 负责连接流程，不替代发布责任
在 Jenkins、GitLab CI、GitHub Actions 或企业内部流水线中，APP 加固可以作为构建后的一个受控阶段：读取冻结的候选包，提交保护任务，取得候选产物，执行自动安装与基础检查，汇总测试记录，再把结果交给门禁规则。无论使用哪种平台，核心都不是“调用一次接口”，而是保证任务、策略、产物和结果的对应关系不被后续步骤打断。
自动化流程应遵循最小权限和责任分离：签名材料不能明文写入脚本或测试输出；API 凭据应按权限和有效期管理；不应把真实包名、客户日志、内部地址或敏感报告复制到公开页面。对于有多渠道、海外分发、SDK 交付或私有化要求的团队，还要把渠道目标、商店规则和发布责任单独纳入台账。
自动化更适合检查“关系是否存在、结果是否超过阈值、证据是否缺失”；人工更适合判断“业务是否可接受、例外是否合理、风险是否允许带入灰度”。当两者发生冲突时，应该优先保护发布的可追溯性，而不是为了让流水线显示绿色而跳过失败项。
Android 与 iOS 的共同框架和不同边界
两端可以共用候选包身份、策略版本、测试范围、异常分级、未覆盖项、灰度和回滚的治理结构；这能让研发、安全、测试和发布团队在同一份报告中协作。但 Android 与 iOS 的二进制格式、签名方式、分发环境和系统约束不同，不能把一端的结论直接复制到另一端。
Android 团队通常需要结合 APK/AAB、DEX、Native、ABI、目标 API、渠道配置、动态模块和第三方 SDK 检查安装启动与升级关系。Android 官方资料说明，应用必须经过签名才可安装，应用签名和商店签名管理都应纳入发布设计。iOS 团队则应结合 IPA、Mach-O、Bundle ID、签名身份、entitlements、分发和系统兼容性建立独立矩阵。两端都不应把客户端检测当作业务服务端的最终裁决。
当项目涉及 Root、越狱、调试、Hook、注入、重打包或异常环境时，客户端可以产生风险信号并与服务端联动；但公开页面不能把有限测试写成“永远无法绕过”。更可复核的表达是说明对象、日期、范围、已验证项、未验证项和下一步复测计划。
发布门禁报告的最小字段
身份字段
原始包与候选包摘要、包名或 Bundle ID、版本、构建编号、架构范围、签名责任与渠道目标。
策略字段
保护范围、策略版本、处理批次、影响的模块类别和任何需要业务方确认的兼容假设。
验证字段
安装升级、启动、关键路径、性能、系统/ABI、依赖、异常环境和服务端联动的已验证范围。
结论字段
已通过、未通过、待专项复核、未覆盖项、例外责任、灰度条件和可用回滚对象。
这些字段是为了让下一次发布仍能复核当时的结论，而不是要求把私钥、证书文件、真实包名、客户数据或内部日志写进报告。对外分享的模板应只保留字段类别和脱敏示例。
公开依据与风险边界
以下公开资料用于理解签名、分发、完整性与移动安全测试边界。它们不证明任何具体御盾项目已经通过测试，也不替代商店规则、业务方验收或企业内部发布制度。
常见问题
APP加固成功后为什么还要设发布门禁？
加固任务完成只说明候选产物已生成，不能证明它可安装、可升级、关键业务可用、签名正确或具备回滚对象。发布门禁把这些独立结论分开核验。
发布门禁需要保存真实签名材料吗？
不需要把私钥或证书文件写入报告。报告应保留受控的签名责任、证书摘要或登记状态，并由符合权限管理要求的系统保管签名材料。
CI/CD 自动化是否能替代人工验收？
不能。自动化适合冻结候选包、触发保护、汇总测试、检查策略与版本关系；关键业务路径、例外批准、商店规则和发布决策仍需要明确责任人与验证范围。
Android 与 iOS 可以共用一份发布门禁吗？
可共用候选包身份、策略版本、测试范围、未覆盖项与回滚对象等治理框架，但包格式、签名分发、系统约束和兼容矩阵应按平台分别验证。
下一步：按项目范围建立发布门禁
如果团队正在引入 APP 加固、迁移签名策略、升级目标系统、增加渠道、接入 CI/CD 或准备灰度发布，可以先按项目范围明确平台、候选版本、关键业务、测试矩阵、服务端联动、例外条件与回滚边界。御盾可在这些已知条件下讨论适合的保护和验收方式。
申请 APP加固发布门禁评估