更换软件加固供应商前，怎样设计可退出和迁移方案

把可退出能力做成接入条件，而不是临时补救

供应商退出并不只发生在服务到期。价格、服务质量、地域合规、产品路线、企业并购、构建平台变化或关键人员调整，都可能触发迁移。真正的可退出能力，是企业在没有旧供应商继续配合的情况下，仍能从受控源码构建合法发布候选、维持应用身份、执行回归并安全更新用户，而不是合同里只有一句“支持迁移”。

退出计划应在首次接入时确定 owner、触发条件、通知期、交付物、数据处理、过渡支持和验收标准。技术 owner 管理基线与配置目标，安全 owner 管理证据与残余风险，密钥 owner 管理签名，发布 owner 管理渠道和更新身份，法务或采购 owner 管理数据删除与合同义务。没有责任人的清单在真正退出时很难执行。

企业还要定义不可接受的锁定。例如只能由供应商云端读取的配置、无法导出的保护映射、供应商代持且企业无法恢复的发布身份、只在对方环境可运行的测试，以及没有源码基线的二进制交付。并非所有专有实现都必须开放，但企业要知道哪些能力不能迁移，并为这些差异准备重建和重验预算。

区分可迁移资产与供应商专有实现

退出盘点应把资产分为企业原始资产、通用安全目标、供应商生成资产和供应商运营数据。源码、资源、签名前产物、业务测试、威胁模型和签名身份属于企业必须控制的基线；“保护离线授权决策”“检测关键资源异常”属于可重新映射的控制目标；虚拟化指令、运行时协议、专用映射和内部规则通常属于专有实现。

配置迁移不应试图把旧供应商的每个开关翻译成新供应商同名开关。名称相同也可能改变作用域、兼容限制和运行时行为，名称不同也可能服务同一控制目标。更稳妥的中间格式是 asset_id、threat_id、control_objective、protected_scope、compatibility_boundary 和 verification_case，新方案根据这些目标设计配置，再用候选回执验证。

供应商运营数据包括上传的 APK、AAB、IPA、符号、映射、诊断日志、设备回执、配置快照、账号信息和支持工单附件。退出清单要写明每类数据的所有者、存储位置、处理依据、保留期、子处理方和删除方式。不能因为门户里看不到文件就认为副本已删除，备份和支持系统中的残余范围也应由回执说明。

• 企业源码、资源、依赖和签名前基线位置明确
• 控制目标使用资产与威胁语言而非专有开关名
• 供应商生成包、映射、日志和配置分别登记
• 专有实现无法迁移的范围与替代成本已知
• 所有供应商数据标注存储、保留和删除责任
• 子处理方与备份副本进入退出数据清单

Android 与 Apple 签名身份必须分别保全

Android 使用应用签名建立安装和更新身份，不同签名方案覆盖的文件区域与平台版本有所不同。企业需要保存应用签名或商店托管责任、上传密钥、证书摘要、轮换与恢复流程，并明确供应商是否曾接触签名材料。旧供应商生成的 APK 若使用临时证书，不能作为生产更新基线；签名有效也只证明完整性和签名者身份。

Apple 平台通过代码签名、证书与运行验证建立 App 身份，相关流程与 Android APK 签名不能合并成一个 certificate 字段。退出计划应分别记录 Apple 团队责任、证书和配置文件管理、构建与签名阶段、App 标识以及发布渠道。供应商若代执行签名，企业仍需能在自有授权链中重建并验证最终候选。

迁移中最危险的动作是为了适配新工具而重签现有生产包、重新包装旧保护包或替换内部文件。任何字节变化都会产生新候选，并可能影响签名与测试关系。正确流程是从企业控制的原始源码和可发布基线重新构建，再由当前签名链签发；旧保护包仅用于历史对照，不能逆向恢复成可信基线。

保留可独立重建的原始发布基线

可退出基线不是旧供应商处理后的最终包，而是企业能独立重建的原始发布输入：源码提交、依赖锁、构建工具、变体、资源、平台 SDK、签名前产物生成步骤和预期摘要。若只有保护包，没有可构建源码和依赖，迁移只能从不完整二进制猜测，既不可靠，也难以证明业务语义与发布身份。

SLSA Provenance v1.1 可以记录产物 subject、builder、buildType、externalParameters 与 resolvedDependencies，适合说明基线和新候选如何产生。加固供应商、配置摘要与工具版本可以作为构建参数或材料进入证明。provenance 只能证明记录的构建关系，不证明运行时安全，也不能弥补缺失的源码、密钥或兼容回执。

in-toto Attestation Statement v1 可把产物摘要与有类型的声明负载绑定。退出时可以用它索引基线、供应商输入输出、测试和删除回执，避免把一份报告贴到另一个候选。声明格式本身不保证内容真实，企业仍需验证签发者、签名、subject 和 predicate，并确保停止合作后仍能读取必要证据。

• 源码提交、依赖锁、工具链和变体能够独立复现
• 签名前基线与最终候选分别计算摘要
• 供应商输入、输出和配置摘要进入 provenance
• 测试、签名和发布声明绑定同一 subject
• 退出后证据索引仍可由企业读取和验证
• 旧保护包不会被当成原始源码或可发布基线

用验证用例迁移安全目标，不迁移旧结论

供应商迁移真正可复用的是验证问题。例如高价值授权路径是否仍由服务端最终决定，目标结构在静态检查中暴露到什么程度，完整性异常如何处置，关键 Native 路径在目标 ABI 是否保持业务语义。这些用例与业务资产绑定，可以交给新方案重跑；旧供应商“已通过”的结论则只属于旧候选。

新候选至少需要保护验证与兼容验证两组回执。保护验证检查新方案是否覆盖目标资产和威胁，兼容验证检查安装、启动、登录、支付、数据、后台任务、异常路径和设备矩阵。即使新供应商声称功能等价，配置作用域、代码变换和运行时依赖仍会变化，不能承诺无损替换或复用旧设备结果。

迁移还要保留原始对照与旧供应商最终稳定候选。原始对照帮助区分应用本身问题，旧稳定候选帮助观察行为差异，新供应商候选用于验收目标控制。三者都要绑定来源、签名和摘要，不能重命名文件后比较。若旧候选无法在当前渠道重新发布，也要明确它仅是诊断对照而非可回滚包。

分阶段切换构建、发布与数据责任

执行迁移可以分为冻结、复现、映射、PoC、生产接入、受控发布和关闭七个状态。冻结旧稳定候选与证据；复现企业原始基线；把控制目标映射到新方案；对新候选做 PoC；接入生产签名与 CI；在批准范围内发布；最后完成数据删除与权限撤销。每个状态都应有 owner、输入、退出条件和不可变回执。

更新系统还要防止回滚、冻结和混搭风险。The Update Framework specification 通过签名角色、版本、过期时间和一致快照处理更新元数据风险，可以作为企业自管更新服务的参考，但它不直接规定 APK、IPA 或业务授权。应用商店和企业分发各有身份与版本规则，迁移方案必须按实际渠道验证，不能简单套用 TUF 名称。

受控发布前要定义停止推进、恢复业务开关和发布修复候选的条件。旧候选能否回滚取决于签名、版本、渠道和已安装用户状态，不能默认随时降级。更可靠的做法是准备经过验证的前向修复路径，并保留旧供应商配置与新配置的差异记录。任何紧急包也要进入合法签名链和最小门禁。

• 冻结、复现、映射、PoC、生产、发布和关闭状态明确
• 每个状态具有 owner、输入、门禁和回执
• 更新元数据验证与移动应用发布规则分别处理
• 停止推进、业务降级和前向修复条件预先定义
• 旧候选是否可回滚经过签名与渠道核对
• 紧急候选仍使用合法身份和最低验证门禁

用只读脚本检查退出清单是否具备闭环

下面的 Python 脚本读取脱敏退出清单，逐个平台检查责任人、签名控制、原始基线、provenance subject、验证用例、供应商数据清单、删除回执、访问撤销和回滚说明。它不接触密钥、不删除数据、不撤销账号，只把缺失字段列入 BLOCK，适合在退出评审前做结构门禁。

签名记录只保存证书摘要、custodian 和 recovery_process，不应包含私钥。baseline 要同时保存 artifact_sha256、source_sha256、dependency_lock_sha256 和 provenance_subject_sha256，脚本要求证明 subject 与基线产物一致。删除回执需要 receipt_id、scope、issuer 和 owner，访问撤销需要 receipt_id 与 owner，避免用口头确认关闭。

清单完整不证明供应商真的删除了所有副本，也不证明新候选可发布。法务、采购、安全、密钥 owner 和发布 owner 仍需核对合同、子处理方、备份残余、签名权限和真实渠道回执。脚本的目的只是阻止明显遗漏，让每个退出结论有责任人和可追踪证据引用。

import json
import sys
from pathlib import Path

REQUIRED_PLATFORM = {
    "platform",
    "owner",
    "signing_control",
    "baseline",
    "verification_cases",
    "vendor_data_inventory",
    "deletion_receipt",
    "access_revocation",
    "rollback_plan",
}
HASH_FIELDS = {"artifact_sha256", "source_sha256", "dependency_lock_sha256", "provenance_subject_sha256"}

def stop(message):
    raise SystemExit(f"invalid exit plan: {message}")

def nonempty(value):
    return isinstance(value, str) and bool(value.strip())

def require_receipt(value, name):
    if not isinstance(value, dict):
        stop(f"{name} must be an object")
    for field in ("receipt_id", "owner", "scope"):
        if not nonempty(value.get(field)):
            stop(f"{name}.{field} is required")

if len(sys.argv) != 2:
    raise SystemExit("usage: python exit_plan_gate.py PLAN_JSON")
plan_path = Path(sys.argv[1]).resolve()
if not plan_path.is_file():
    stop(f"file not found: {plan_path}")
payload = json.loads(plan_path.read_text(encoding="utf-8"))
platforms = payload.get("platforms")
if not isinstance(platforms, list) or not platforms:
    stop("platforms must be a non-empty list")
review = []
seen = set()
for index, item in enumerate(platforms):
    if not isinstance(item, dict):
        stop(f"platform {index} must be an object")
    missing = sorted(REQUIRED_PLATFORM.difference(item))
    if missing:
        stop(f"platform {index} missing {missing}")
    platform = item["platform"]
    if not nonempty(platform) or platform in seen or not nonempty(item["owner"]):
        stop(f"platform {index} has invalid identity or owner")
    seen.add(platform)
    signing = item["signing_control"]
    if not isinstance(signing, dict) or not nonempty(signing.get("certificate_sha256")) or not nonempty(signing.get("custodian")) or not nonempty(signing.get("recovery_process")):
        stop(f"platform {platform} lacks signing control")
    baseline = item["baseline"]
    if not isinstance(baseline, dict):
        stop(f"platform {platform} lacks baseline")
    for field in HASH_FIELDS:
        value = baseline.get(field)
        if not isinstance(value, str) or len(value) != 64:
            stop(f"platform {platform} has invalid {field}")
    if baseline["artifact_sha256"] != baseline["provenance_subject_sha256"]:
        stop(f"platform {platform} provenance subject mismatch")
    cases = item["verification_cases"]
    inventory = item["vendor_data_inventory"]
    if not isinstance(cases, list) or not cases or not all(nonempty(case) for case in cases):
        review.append({"platform": platform, "gap": "verification_cases"})
    if not isinstance(inventory, list) or not inventory or not all(nonempty(entry) for entry in inventory):
        review.append({"platform": platform, "gap": "vendor_data_inventory"})
    require_receipt(item["deletion_receipt"], f"{platform}.deletion_receipt")
    require_receipt(item["access_revocation"], f"{platform}.access_revocation")
    if not isinstance(item["rollback_plan"], dict) or not nonempty(item["rollback_plan"].get("owner")) or not nonempty(item["rollback_plan"].get("scope")):
        review.append({"platform": platform, "gap": "rollback_plan"})
output = {
    "plan_id": payload.get("plan_id"),
    "platform_count": len(platforms),
    "review": review,
    "gate": "BLOCK" if review else "READY_FOR_EXIT_REVIEW",
}
print(json.dumps(output, ensure_ascii=False, indent=2, sort_keys=True))

退出验收要同时关闭技术、数据和合同责任

退出完成的技术证据包括企业可独立构建的基线、新供应商最终候选、正确签名身份、保护与兼容回执、更新渠道验证、差异清单和前向修复方案。旧供应商稳定候选与报告可以保留为历史证据，但要明确其可用期限、读取方式和是否仍依赖供应商服务。

数据与访问关闭包括所有账号、API 凭据、CI 访问、仓库权限、上传入口、支持门户和远程诊断通道的撤销回执，以及 APK、IPA、AAB、符号、映射、日志和工单附件的删除或合法保留说明。删除回执只能证明声明的范围，备份、法规保留和子处理方残余应单独写明。

NIST SP 800-218 SSDF 强调持续维护、变更和供应链风险管理，退出方案也应进入日常演练，而不是只在争议时打开。需要评估实际迁移时，可通过御盾中央平台提交脱敏基线摘要、签名责任、控制目标、验证矩阵、供应商数据清单和渠道约束，先识别不可迁移项，再安排新候选和退出门禁。

• 企业在退出后仍可独立构建、签名、测试和发布
• 新候选取得保护、兼容、更新与渠道回执
• 旧供应商数据删除范围和残余副本已说明
• 所有账号、令牌、仓库与 CI 访问均有撤销回执
• 专有资产、历史证据和支持期限进入合同关闭
• 退出方案定期演练并随平台与供应链变化更新