应用加固采购前如何准备技术需求书
如果我准备采购应用加固方案，是否需要先把业务场景梳理清楚？哪些使用环境、终端类型和数据敏感度信息，能帮助我把需求写得更准确？
先梳理业务场景，再匹配加固能力
需要先明确应用的核心使用场景，包括面向内部员工、外部用户还是合作伙伴，运行在安卓、iOS还是双端环境，以及是否涉及登录、支付、隐私数据、接口调用等关键功能。还要说明应用发布方式，是应用商店分发、企业签名分发还是专属渠道安装。若能补充业务中对兼容性、性能、升级频率和合规要求的关注点，供应商就更容易判断需要哪些加固能力，例如代码混淆、反调试、反篡改、完整性校验和数据保护等。
我想让供应商根据技术需求书给出更贴近实际的方案，应该把哪些安全能力写进去？是否需要区分基础防护、进阶防护和高强度防护的范围？
把防护目标和能力边界写具体
技术需求书中应明确需要保护的对象，例如源码、接口参数、本地存储、证书、密钥、业务逻辑或关键页面。也要写清希望具备的能力范围，比如代码混淆、字符串加密、资源加密、反调试、反抓包、反注入、反二次打包、运行环境检测、Root或越狱检测、完整性校验等。若对某些功能有强制要求，例如不影响启动速度、必须支持特定系统版本、需要兼容某些第三方 SDK，都建议直接列出。这样供应商才能区分标准方案与定制方案，报价也会更准确。
我担心应用加固后会出现闪退、耗电增加或启动变慢，技术需求书里应该怎么写，才能把兼容性和性能风险控制住？
把兼容指标和验收条件写进需求
可以在技术需求书里明确兼容的操作系统版本、设备型号范围、CPU 架构、第三方组件版本，以及对主流机型和低配机型的适配要求。性能方面，建议写出启动时间、页面切换、包体增量和内存占用的控制目标，例如要求加固后启动耗时增加不超过某个比例，包体增长控制在可接受范围内。还可以补充验收方式，如提供测试包、灰度验证、回归测试支持和问题修复响应时间。把这些内容写清楚，有助于供应商提前评估实施难度，也能减少后期反复修改。
我在采购应用加固服务时，除了安全能力本身，还应该要求供应商交付哪些材料？后续如果应用版本更新，供应商需要提供什么支持？
交付物和服务边界要一并明确
建议把交付物和售后支持写入技术需求书。交付物通常包括加固后的安装包、加固配置说明、测试报告、验收报告、问题清单以及必要的接入文档。若项目涉及持续迭代，还应约定新版本适配、紧急故障处理、漏洞修复、加固策略调整和服务响应时限。对于源代码是否需要提供、密钥如何管理、日志和报告如何交接，也要提前说明。这样能避免采购完成后出现责任不清或版本更新无法衔接的问题。