加固合同里的背锅条款怎么写？我审了8份合同后的避坑要点

去年我们金融APP被监管点名后，我连续审了8家加固公司的合同，发现一个共同问题：销售口头承诺“绝对安全”，合同里却全是“免责条款”。等保测评过了算谁的？加固后还被破解谁赔？服务中断导致业务停摆怎么算？这些问题不写在合同里，出事就是你背锅。

以下是我踩过坑、撕过合同、请外部律师逐条审完后，总结的8个高风险条款的避坑要点和谈判话术。

条款1：效果承诺——最容易被模糊的地带

常见坑人写法：

“乙方不对加固后的应用完全防止被逆向、破解或攻击作出任何明示或暗示的保证。”

这等于把安全风险全推给你。出了问题，对方一句“安全是相对的，我们没保证过”就能甩锅。

正确写法：

“乙方承诺，在合同有效期内，其提供的加固方案能够抵御已知的主流逆向工具（包括但不限于Jadx、JEB、IDA Pro、Frida、Xposed、Objection）对核心逻辑（具体范围见附件一）的静态分析和动态调试。如甲方提供证据证明上述工具在未经过特殊定制或硬件辅助的情况下能够成功绕过防护，乙方应在72小时内修复并免费重新加固。”

谈判话术：

“安全没有100%，但我们需要明确衡量标准。主流工具的逆向对抗能力写进合同，这样双方都有明确的验收依据，对大家都公平。”

替代方案： 如果对方坚持不写“承诺”，要求改为“交付SLA”——承诺首次加固后提供渗透测试报告，测试不通过不收尾款。

条款2：破解赔付——出事谁兜底

常见坑人写法：

没有这条，或者写成“如因加固技术漏洞导致甲方损失，乙方最高赔偿不超过本合同总金额的20%。”

20%的年费可能就一两万，连应急响应的成本都不够，更别说数据泄露后的监管罚款。

正确写法：

“若因乙方提供的加固方案存在技术漏洞（漏洞定义见附件二），导致甲方应用被第三方成功逆向并获取核心算法/密钥/业务逻辑，进而造成直接经济损失，乙方承担以下责任：

1. 立即启动应急响应，72小时内完成漏洞修复及新版本加固；
2. 赔偿甲方因该事件产生的应急响应费用（包括但不限于渗透测试、代码审计、第三方安全评估），单次事件上限为合同总额的3倍或30万元（以高者为准）；
3. 如该事件导致甲方被监管部门处罚，乙方承担罚款金额的30%，上限为合同总额的5倍。”

谈判话术：

“我们不是要你无限兜底，但至少应急响应的费用和一定比例的监管罚款要担。这样我们双方才有动力共同把安全做好，而不是出事就扯皮。”

替代方案： 如果对方完全不接受赔偿条款，要求购买第三方网络安全保险，并将加固公司的责任与保险理赔挂钩。

条款3：等保责任归属——报告不认算谁的

常见坑人写法：

“乙方协助甲方完成等保测评所需的材料准备。”

“协助”两个字就是坑——他不保证你能过，只保证“提供了材料”。测评机构不认，你只能自己补。

正确写法：

“乙方提供的加固方案及配套报告需满足GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》中针对移动应用安全扩展要求（具体条款见附件三）。如因报告内容不完整、防护能力描述缺失等乙方原因导致测评不通过，乙方应在5个工作日内无偿补充材料或调整加固方案，直至通过测评。”

谈判话术：

“我们不要求你保证一定过等保，因为测评还有管理层面的因素。但你的报告本身如果被测评机构打回来，这个责任你得兜——内容不全你来补，这是合理的。”

替代方案： 要求合同里附上报告的目录和关键检测项清单，明确哪些项由加固公司负责提供证据。

条款4：数据泄露责任——你的代码会不会变成他的样本

常见坑人写法：

“甲方同意乙方在提供加固服务过程中收集、存储、分析甲方应用的代码特征、崩溃日志及运行数据。”

这意味着你的APK会传到对方服务器，你的核心逻辑特征会被他们留存。小公司可能拿去做训练样本，出事了你都不知道。

正确写法：

“乙方在处理甲方应用代码、SO库、配置文件等任何技术资料时，仅限当次加固任务使用，不得留存副本、不得用作训练数据、不得向任何第三方披露。加固完成后，所有传输及中间文件应在7个工作日内删除。如因乙方数据泄露导致甲方受损，乙方承担全部直接损失。”

谈判话术：

“我们能理解加固需要上传文件，但数据不能留、不能他用。请在合同里写清楚删除时限和用途限制，这是底线。”

替代方案： 选择支持私有化部署的厂商（如几维安全、梆梆安全的私有化版本），数据不出内网，彻底规避风险。

条款5：知识产权归属——加固后的代码是谁的

常见坑人写法：

没有明确写，或者写成“乙方保留加固过程中产生的所有技术成果的知识产权。”

没写清楚意味着：你的APP经过对方加固后，加固壳本身可能是对方的专利技术，但你APP里的业务逻辑经过了对方的代码混淆和虚拟化处理，这部分算谁的？万一你换厂商，老版本的知识产权纠纷就是定时炸弹。

正确写法：

“甲方保留其原始应用的全部知识产权。乙方提供的加固技术（包括但不限于加壳代码、虚拟化指令解释器、混淆算法）的知识产权归乙方所有，但乙方确保上述技术不包含甲方的原始业务逻辑。甲方加固后的应用整体归甲方所有，甲方有权在任何时候更换加固厂商，乙方不得以知识产权为由限制甲方解绑或迁移。”

谈判话术：

“我们不觊觎你的技术，你也不绑定我们的代码。明确加固后APP的整体所有权归甲方，这样我们换厂商不会被卡脖子。”

替代方案： 要求合同里加入“解绑条款”——甲方书面提出解绑后，乙方应在15个工作日内提供无加固壳的原始包（或等效物），不得以任何理由拖延。

条款6：服务中断赔偿——SaaS崩了怎么办

常见坑人写法：

没有服务中断赔偿，只写“乙方尽力保证服务可用性”。

如果你的CI/CD流水线依赖云端加固API，SaaS平台崩了导致你发不了版，对方没有赔偿义务。

正确写法：

“乙方承诺SaaS加固服务可用性不低于99.9%。单月服务中断累计超过2小时，甲方有权要求减免当月服务费的20%；中断超过8小时，甲方可无责解约并要求退还剩余服务期费用。服务中断包括：API调用失败、加固平台无法访问、加固任务长时间阻塞。”

谈判话术：

“线上加固服务跟云服务一样，有SLA是基本要求。99.9%可用性是个行业标准，并不苛刻。”

替代方案： 选择支持本地命令行加固的厂商（如几维安全提供离线加固工具），断网也能自己跑，不依赖云端API。

条款7：退出机制——换厂商怎么换

常见坑人写法：

“合同到期后，甲方如需更换加固方案，需自行处理原有加固壳的移除。”

这等于给你下套——很多加固壳是加在原始代码里的，你自己根本移不干净，换厂商就得重写部分模块。

正确写法：

“合同终止时，乙方应提供去加固壳工具或服务，协助甲方将已加固的应用恢复至可重新打包的状态。甲方无需支付额外费用。如乙方拒绝提供，甲方有权要求乙方赔偿因无法换厂导致的实际损失。”

谈判话术：

“我们不可能一辈子绑在你家。结束时你给我一个去壳工具，这是公平的。”

替代方案： 在POC阶段就测试“去加固”流程，确认对方能提供干净的恢复方案。

条款8：争议解决——到对方地盘打官司必输

常见坑人写法：

“如发生争议，双方同意提交乙方所在地人民法院诉讼解决。”

如果你是北京的公司，对方在深圳，这个条款意味着你得出差、请当地律师、承受更高的诉讼成本。小纠纷你基本放弃维权了。

正确写法：

“如发生争议，双方应友好协商；协商不成的，提交甲方所在地人民法院诉讼解决。”

或者选择仲裁：

“提交中国国际经济贸易仲裁委员会（CIETAC），按照申请仲裁时该会现行有效的仲裁规则进行仲裁。仲裁地为甲方所在地。”

谈判话术：

“诉讼地选在甲方或中立城市，这是商业合同的惯例。如果选在你那边，我连维权都维不起，那合同上的赔偿条款就成了空文。”

替代方案： 如果对方坚持不换，要求在合同里增加“小额争议快速通道”——争议金额低于5万元的，由双方指定的技术专家组成三人小组裁决，裁决结果即终局。

附：签合同前的3个动作

1. 拿POC报告对条款：合同里写的“主流逆向工具”具体是哪些？POC时测过的工具列表可以附进合同附件。
2. 让技术负责人看附件：很多关键细节不在正文里，而在“附件一：防护范围”“附件二：漏洞定义”里。这些附件必须写清楚，不能留白。
3. 给法务看，不是走过场：如果你的法务说“这合同条款太模糊，建议修改”，别嫌麻烦，真的改。

安全加固合同不是买保险——买了不等于出事有人赔。把你的核心诉求（过等保、防破解、能退出）写进条款里，比销售的一百句承诺都管用。