传统代码安全扫描的问题
静态应用安全测试（通常称为 SAST）已成为超过二十年来自动代码安全分析的主导范式。该方法在概念上很简单：在不执行代码的情况下分析源代码，查找与已知漏洞特征相匹配的模式。从用户输入组合的 SQL 查询、没有边界检查的内存分配、使用弱参数的密码学函数——SAST 工具可以以任何大小的代码库高速标记这些模式。
问题在于误报率。成熟的企业代码库通常会收到包含数千个标记项目的 SAST 报告，其中大多数代表不可利用的代码模式、已缓解的漏洞或合法使用标记的 API。安全工程师花费大量时间对这些报告进行分类。信噪比不够好，以至于许多组织按计划运行 SAST 工具，但已形成了忽视其大部分输出的机制性容忍度。
这是 OpenAI 表示希望通过 Codex Security 解决的问题——也是它选择不在产品中包含 SAST 报告的原因。
约束推理作为替代方案
Codex Security 使用 OpenAI 所称的 AI 驱动约束推理和验证的不同方法。该系统不是模式匹配与漏洞特征，而是尝试根据其出现的具体环境推理漏洞是否真正可被利用。
这种区别在实践中至关重要。SAST 工具可能会标记特定字符串格式化函数的每个实例为潜在的格式字符串漏洞，无论该函数的输入是否真的可以被攻击者影响。Codex Security 尝试追踪数据流、理解信任边界，并评估具有现实访问权限的攻击者是否真的可以触发有问题的代码路径。
此方法借鉴了学术安全研究中使用的形式化验证和约束满足方法，但应用 AI 推理来处理真实世界代码库的歧义和复杂性，这些是形式化方法历来难以扩展到的领域。
更少的发现，更高的置信度
这种方法固有的权衡是 Codex Security 可能会错过 SAST 会捕捉到的漏洞。OpenAI 对此限制是透明的。该系统被设计为优先考虑精度而非召回率：它标记的漏洞应该是真实且可利用的，即使代码库中存在该系统未识别的真正漏洞。
对于被低质量 SAST 输出淹没的安全团队来说，这种权衡可能很有吸引力。一组较小的高置信度、可行的发现可以被一致地修复，从而在安全态势中产生可衡量的改进。大量发现中大多数是误报的情况会导致分析瘫痪，实际上，通常最后什么都没有被修复。
OpenAI 辩称，当发现是可信的时，开发者体验也会显著改善。学会了在其代码库中 80% 的安全工具发现是噪音的开发者会习惯于忽视安全警告。一个几乎每次都是对的工具会培养不同的行为：认真对待每项发现并修复它。
验证管道
Codex Security 将初始约束推理与验证步骤结合在一起，验证步骤使用 AI 生成概念验证测试用例，尝试在沙箱环境中实际触发漏洞。如果系统的关于如何利用漏洞的模型可以转化为工作的漏洞利用——即使是仅仅证明代码路径执行的良性漏洞利用——对该发现的置信度也会大幅提高。
相比静态模式匹配，这个验证步骤计算量很大，这是为什么该方法在安全工具中不是通用的原因之一。但它代表了一个重要的质量门控。同时通过约束推理阶段和漏洞利用验证阶段的漏洞明显更可能代表真正的安全风险，而不是未经任何基于执行的验证的 SAST 发现。
在安全工具生态中的定位
Codex Security 不是作为所有安全工具的替代品而定位的。OpenAI 将其描述为对 Fuzzing、渗透测试和手动代码审查的补充。其定位是针对自动代码分析的具体工作，基于推理的方法相比基于特征的方法可以在 AI 推理足够成熟的代码库和漏洞类别中提供更好的结果。
该产品继续了 AI 辅助安全工具中的更广泛趋势，即朝向理解代码语义而不仅仅是语法的系统发展。随着在大型代码语料库上训练的 AI 模型变得更能够推理程序行为，自动工具能够可靠发现的内容与熟练的人类安全研究人员能够发现的内容之间的差距在缩小——尽管还没有完全消除。
本文基于 OpenAI 的报道。阅读原文。
Originally published on openai.com