技术评审会实录：我们怎么从8家机构里筛出真懂AIR的检测方

一、背景：什么情况逼我们搞评审会

去年Q4，一个用Adobe AIR开发的金融交易终端要过等保2.0三级。这类项目在监管眼里不看技术栈新旧，只看风险暴露面。但问题来了：AIR在2020年就停更了，市面上几乎所有安全厂商的技术栈都围着Android/iOS/Web转，对SWF、ANE、ActionScript 3的认知退化到“这玩意还能跑？”

CTO给我的硬性要求：必须找真正懂AIR技术栈的检测方，不能拿通用报告去赌测评机构认不认。

于是我发起了供应商技术评审会。8家报名，最终进入现场评审环节的是5家：腾讯云安全、绿盟科技、梆梆安全、几维安全，还有一家创业公司（后面称X公司）。

这篇文章还原的就是那次评审会的完整过程，包括我们设计的考题、追问技巧、评分逻辑，以及最终为什么选了那一家。

二、评审会设计思路：不讲PPT，只解决问题

时间安排：每家90分钟

• 20分钟：技术方案陈述（限制只讲“怎么检测AIR应用”）
• 50分钟：现场出题+追问
• 20分钟：商务条件确认

评审团构成：

• CTO（关注技术深度、方案可落地性）
• 安全负责人（关注漏洞发现能力、报告规范性）
• 开发组长（关注修复建议的可操作性）
• 采购（关注保密条款、价格、复测条款）

核心原则：不让对方讲通用能力，只聚焦AIR技术栈的特有问题。谁在通用方案里绕圈子，直接打断。

三、现场出题：一个ANE样本，筛掉4家

我们提前准备了一个测试用AIR应用，核心特征：

1. 有一个ANE扩展调用了本地SQLite数据库（明文存储）
2. SWF文件中硬编码了与服务器通信的AES密钥
3. SWF未做任何混淆或加密
4. 应用会在本地缓存敏感交易数据

考题1：分析这个ANE扩展的风险点（30分钟）

各家表现：

• 腾讯云安全：技术负责人坦言“ANE不是我们的标准检测项，需要走定制”。然后开始在通用方案里找替代项——“我们可以按原生Android so库的方式来审计JNI层”。追问“ANE特有的ExtensionContext调用链你们怎么还原？”答不上来。

• 绿盟科技：直接说“我们的RSAS不支持针对ANE的检测”，但可以人工介入做逆向分析，按人天收费。报价没出来，流程先复杂化了。

• 梆梆安全：他们做了ANE分析，但只停留在“检查so文件是否有加固”的层面。追问“SQLite操作有没有使用加密版本？”回答是“需要看具体代码”。等于没答。

• X公司：三个人面面相觑，最后说“我们建议把业务逻辑迁移到服务端”。直接离题。

• 几维安全：技术负责人拿到样本后做的第一件事是反编译SWF，定位到ANE调用点，然后溯源到对应的Java/OC代码。给出的风险点包括：

  • SQLite操作未使用SQLCipher，明文存储可被直接读取
  • ANE的JNI调用未做校验，存在动态注入风险
  • so文件未加壳，可直接用IDA分析

这一轮之后，我心里已经有数了：只有几维安全完整还原了从AS3到Java到SQLite的完整调用链。

考题2：如何防止SWF被反编译？（20分钟）

这个题考的是“能不能给出可操作的修复方案”，不是理论。

各家回答：

• 腾讯云、绿盟：通用建议——“代码混淆、加壳、关键逻辑放服务端”。没有具体工具或方案。

• 梆梆安全：提到了SWF加密，但说“需要配合我们的加固套餐”。

• 几维安全：直接给出了三级防护方案：

  • 基础：使用商业混淆器（如SecureSWF）做名称混淆、控制流扁平化
  • 进阶：将核心SWF用AES-128加密后以ByteArray嵌入Loader，运行时解密加载
  • 企业级：使用KiwiVM将ActionScript字节码转换为虚拟机保护指令，等效于代码虚拟化

并且现场演示了未混淆SWF用JPEXS反编译出完整源码vs经过KiwiVM处理后反编译结果全是无效指令。

这一轮，技术差距已经拉开了。

四、追问环节：五个“拷问”问题及判断标准

追问1：“你们做过几个真实的AIR项目？能说具体遇到什么问题吗？”

判断标准：如果说“做过但签了保密协议不能透露细节”→大概率没做过。真正做过的，不需要透露客户名，只讲技术难点就能说服人。

几维安全的回答：“去年帮一家期货公司的AIR交易终端做过检测。当时发现他们的ANE里用了一个开源加密库，但我们逆向后发现那个库的随机数生成器有弱熵问题。最后帮他们替换成Bouncy Castle并提供修复代码。”

有场景、有细节、有结果。

追问2：“报告里标注的高危漏洞，是按什么标准定级的？”

判断标准：说“通用漏洞评级标准CVSS”的属于及格。说“CVSS + 等保2.0控制点映射”的属于优秀。

几维安全的回答：每个漏洞标注三项：CVSS评分、对应的等保2.0控制点（如“安全计算环境-数据完整性”）、以及是否影响密码应用安全性评估。

测评机构认这种报告。

追问3：“如果检测出来漏洞，我们开发组修不动，你们能帮到什么程度？”

判断标准：给文档 vs 给代码 vs 提供加固工具，颗粒度天差地别。

几维安全的回答：

• 普通漏洞：给修复代码片段（如SQLCipher接入代码）
• 架构级问题：提供加固工具（SWF虚拟化保护、so加壳）
• 复测：合同包含2次免费复测

追问4：“源代码怎么传输？你们内部怎么管理？”

判断标准：要求上传到云端厂商平台的，金融行业直接一票否决。

各家方案：

• 腾讯云：默认云端扫描，可签保密协议
• 绿盟：提供本地扫描引擎（私有化部署）
• 梆梆：云端+本地混合
• 几维安全：提供完整私有化部署方案，引擎装在我们内网，数据不出域

这是加分项。

追问5：“如果等保测评机构不认可你们的报告，怎么办？”

判断标准：敢写进合同才算数。

几维安全的回答：“我们之前服务过X家等保三级客户，报告模板是测评机构认可的。如果真出现不认可的情况，我们配合修改直到通过。”

五、评分记录表（附最终结果）

最终结果：几维安全得分最高，进入商务谈判。

六、为什么没选另外几家？

腾讯云安全：通用能力很强，但AIR专项深度不足。如果我们的需求只是“扫个漏洞”，他们够用。但我们缺的是“能理解ANE、能修SWF”的专家。

绿盟科技：RSAS漏洞库确实全，但服务模式是“检测即结束”。要修复指导？加钱。要等保适配？加钱。最后总价可能比几维还高，但体验是拆散的。

梆梆安全：技术能力在线，但检测和加固强绑定。我们只需要“检测+报告”，却被要求买加固套餐。商务谈判时不够灵活。

X公司：初创团队，价格有吸引力（报价3万），但技术深度不足，现场考题没接住。风险评估后认为交付风险太大。

七、复盘：评审会的三个经验教训

教训1：不要信PPT里的“支持”二字
某家厂商的方案书里写着“支持SWF安全检测”，现场一问，用的是通用反编译工具扫一下，连SWF加密和混淆都没法识别。一定要出题实测。

教训2：让开发组参与评审
最初我只让CTO和安全负责人参与。后来开发组长强烈要求加入，他问的问题角度完全不同——“你们给的修复方案，我们开发要改几行代码？”“你们加固后的SWF，加载性能影响多少？”这些问题直接关系到交付周期。

教训3：把“复测”写进合同
这是踩过坑的人才会注意的点。某云厂商复测按50%收费，等于第一次检测没过，第二次还要掏一半。几维安全合同写明“含2次复测”，锁定成本。

八、给技术负责人的最后建议

如果你现在要找AIR应用安全检测服务商，评审会上请务必确认三件事：

1. 对方能不能现场说清楚ANE的完整调用链？——说不清的直接淘汰
2. 对方能不能提供SWF加固的具体方案？——只说“混淆”的不够，要问到“用什么工具、什么强度”
3. 对方敢不敢把“报告可用于等保”写进合同？——敢写的才有底气

最终我们选了几维安全，不是因为品牌大——说实话他们在圈外名气不如绿盟腾讯——而是因为在这个细分场景下，他们的技术深度和交付模式最匹配我们的风险承受能力。

检测服务这东西，便宜的有坑，贵的未必值。真正重要的是：出了漏洞能不能修、报告能不能过审、代码会不会外泄。这三点，评审会当面验证最靠谱。