采购经理视角：AIR应用检测招标RFP模板与评分权重设计

一、为什么需要专门的AIR检测招标规格书？

采购过安全检测服务的同行都懂：用通用模板招AIR项目，来的供应商八成是在“陪标”。Adobe AIR技术栈的特殊性在于，它既不是纯Web应用（有SWF字节码），也不是纯移动应用（有ANE原生扩展），更不是传统PC软件（嵌入AIR运行时）。等保2.0和密评的双重要求下，通用检测方案根本覆盖不全。

本文提供一套可直接套用的RFP技术规格书模板，核心检测项权重经过真实项目验证（ANE分析30%、SWF审计25%、运行时安全20%等），附评分表示例，帮你在招标阶段筛掉“不懂装懂”的供应商。

二、AIR应用安全检测RFP技术规格书模板

2.1 项目背景

本次采购旨在对[XXX]系统（基于Adobe AIR技术栈开发的客户端应用）进行全面的安全性检测，检测结果需满足以下合规要求：

• 《网络安全等级保护基本要求》（GB/T 22239-2019）第三级/第四级
• 《信息安全技术 信息系统密码应用基本要求》（GB/T 39786-2021）
• 商用密码应用安全性评估（密评）相关要求

2.2 检测范围

2.3 技术检测要求

2.3.1 SWF/AS3代码安全审计（权重25%）

强制要求：

1. 具备SWF反编译能力，可还原ActionScript 3代码流，不能停留在“识别到Flash文件”层面
2. 审计以下高风险代码模式：
   • Loader.loadBytes() 动态加载字节码
   • eval() / setTimeout() 字符串执行（AIR应用安全沙箱限制）
   • FileStream 任意文件读写操作
   • URLRequest 未校验的网络请求
3. 识别硬编码密钥、证书、Token等敏感信息
4. 输出每个漏洞的代码位置（文件名+行号）

加分项：

• 支持SWF字节码虚拟化保护方案的有效性验证
• 提供混淆代码的反混淆还原能力证明

2.3.2 ANE原生扩展安全审计（权重30%）

强制要求：

1. 对ANE包中的原生代码（Android的.so、iOS的.a）进行逆向分析
2. 审计以下原生层风险：
   • JNI调用链中的参数校验缺失
   • 本地文件权限设置（world-readable风险）
   • so文件的代码混淆/加固状态评估
   • 第三方原生库的已知CVE漏洞扫描
3. 检查ANE扩展申请的Android权限是否超出声明范围
4. 输出原生代码中可被Java/JS层调用的导出函数清单及安全风险

加分项：

• 提供so文件的控制流完整性验证
• 具备对Ollvm等常见混淆方案的去混淆能力

2.3.3 AIR运行时安全（权重20%）

强制要求：

1. 检测应用程序安全沙箱配置是否正确（application.xml中的权限声明）
2. 评估以下运行时特有风险：
   • 应用目录写入保护状态（app:/ 是否可被篡改）
   • 降级攻击防护（旧版本覆盖安装风险）
   • 后台截图隐私泄露（Android场景的deactivate事件处理）
3. 检测运行时探针植入后的内存dump防护能力

加分项：

• 提供对AIR运行时自身漏洞的检测（如CVE-2018-5002等历史漏洞）
• 支持对自定义AIR运行时（修改版）的安全评估

2.3.4 数据安全与加密合规（权重15%）

强制要求：

1. 本地数据库：验证SQLite是否采用SQLCipher等加密方案，密钥派生强度是否符合GB/T 39786要求
2. EncryptedLocalStore（ELS）：明确说明ELS在Android/iOS上的实际加密状态（Android上ELS非加密，依赖Linux UID隔离）
3. 网络传输：验证HTTPS/TLS配置是否符合等保2.0要求（TLS1.2+、证书校验、国密可选）
4. 密码应用：对照GB/T 39786-2021第7章“应用和数据安全”逐条验证

加分项：

• 提供与密评机构报告格式对齐的密码应用安全性分析章节
• 支持国密算法SM2/SM3/SM4的合规性验证

2.3.5 等保2.0 & 密评专项检测（权重10%）

强制要求：

1. 检测报告需对应标注每个问题触发的等保2.0控制点（如“安全区域边界-访问控制”）
2. 覆盖等保2.0应用安全全部8个控制点：
   • 身份鉴别、访问控制、安全审计、入侵防范
   • 数据完整性、数据保密性、数据备份恢复、剩余信息保护
3. 密评部分需引用《信息系统密码应用测评要求》中的测评方法
4. 提供可直接提交给测评机构的“问题-合规条款”映射表

加分项：

• 检测团队持有商用密码应用安全性评估资质
• 提供过往通过等保三级/密评的AIR项目案例

2.4 交付物要求

2.5 服务流程与周期

强制要求：

1. 检测周期：合同签订后15个工作日内出具初测报告
2. 复测次数：至少包含2轮免费复测（对应“修复-验证”闭环）
3. 技术支持：检测期间提供即时通讯群支持，漏洞确认需在24小时内回复
4. 保密条款：必须签署独立保密协议，支持私有化部署（检测引擎部署在甲方内网）

三、评标指标体系设计（总分100分）

3.1 技术能力（45分）

否决项：技术讲标环节，供应商无法准确说出AIR的3个特有攻击面（ANE逆向、ELS非加密、SWF反编译、降级攻击等），直接扣20分。

3.2 服务能力（25分）

3.3 商务报价（20分）

拦标价建议：15万元（超出需特殊说明，含复测费用）

3.4 成功案例（10分）

四、评分表示例

A公司胜出理由：技术深度突出（ANE审计有完整方法论），修复指导承诺代码级，虽报价不是最低但综合性价比最优。

五、合同关键条款提醒

招标文件中建议明确以下条款，避免履约纠纷：

1. 复测费用锁定：合同总价包含至少2轮复测，超出按X元/轮计费（建议不超过初测费用的20%）
2. 报告被拒责任：如因检测报告格式/内容问题导致等保或密评测评机构退回，供应商需免费修改至通过
3. 源码处理方式：明确约定源码传输方式（云端/私有化/现场）、存储期限（检测完成后X日内删除）、销毁证明
4. 漏洞误报争议：设置争议处理机制（如双方共同指定第三方复核），避免“你说有我说没有”的扯皮

六、供应商应答文件 Checklist

要求供应商在投标文件中明确回应以下问题，作为技术标评审依据：

• 你们检测过几个纯AIR技术栈项目？能否脱敏展示报告首页？
• 针对ANE扩展，审计时是只看Java层还是也逆向.so文件？
• SWF反编译后，代码混淆程度达到多少时你们就无法还原了？（如实回答即可，吹牛的会露馅）
• 检测工具是否支持私有化部署？部署在甲方内网需要什么环境？
• 报告中的“高危漏洞”是否有CVE编号或等保对应条款？
• 修复建议给代码示例还是只给方案文档？能否提供一份脱敏的修复建议书样例？
• 如果第一次检测没过等保，后续复测怎么收费？合同里能不能写明？
• 检测团队中是否有通过商用密码应用安全性评估考试的人员？

把这套模板拿去用，至少能筛掉70%“什么都能测但什么都不精”的通用型安全厂商。至于最终选哪家，记住一句话：让供应商在技术讲标环节，现场对着一个真实的AIR样本说清楚它的攻击面，比看一百页PPT都有用。