做过代码安全扫描的人，大概率都遇到过一种情况：

扫描器告诉你：

这里可能存在漏洞。

开发者花半天检查，最后发现：

根本触发不了。

或者代码表面上看起来很危险：

User Input
↓
Sensitive Function

但继续往下看才发现：

前面还有权限校验；

参数已经被限制；

危险路径根本不可达；

真实运行环境也不满足攻击条件。

这就是安全扫描最麻烦的问题之一：

Finding不等于Vulnerability。

Codex Security目前的设计也在刻意解决这个问题。官方说明，它不是发现可疑代码后直接把结果交给人，而是先识别高可能性问题，再尝试在隔离环境中进行自动验证；能够成功复现的Finding才会被标记为Validated，从而减少人工面对的误报。

所以真正成熟的安全扫描流程不应该是：

发现可疑代码
↓
报告漏洞

而应该是：

Threat Model
↓
Discovery
↓
Hypothesis
↓
Validation
↓
Attack Path
↓
Evidence
↓
Report

这7层之间，任何一层缺失，都可能把：

“看起来危险”

误判成：

“真实漏洞”。

---

一、第一层：Threat Model——先回答“什么才算风险”

很多安全扫描误报，并不是扫描器完全看错了代码。

而是：

它不知道这个系统真正需要保护什么。

比如同样一个管理接口：

在公网系统里可能属于高风险入口。

但如果它只存在于：

Internal Network
↓
Admin Gateway
↓
Private Service

风险模型就完全不同。

Codex Security会先根据Repository生成Threat Model，其中包括项目结构、入口点、Trust Boundary、认证假设和高风险组件等信息，并允许团队后续根据真实业务情况修改。

所以安全扫描真正的第一步不是：

搜索危险函数。

而是：

这个系统的攻击面是什么？

一个基础Threat Model至少应该回答：

Assets
需要保护什么？

Entry Points
攻击者从哪里进入？

Trust Boundaries
哪些位置发生信任变化？

Security Invariants
哪些条件必须始终成立？

例如认证系统里，一个重要Invariant可能是：

未认证用户
永远不能读取其他用户的数据

后面的所有安全分析，其实都应该围绕这些Invariant展开。

---

二、为什么没有Threat Model特别容易误报？

假设代码中存在：

downloadFile(path)

单独看到：

用户能够控制：

path

扫描器很容易怀疑：

Path Traversal。

但真正判断漏洞是否成立，还需要知道：

这个接口是不是公开的？

调用之前有没有鉴权？

path是不是来自白名单ID映射？

实际文件系统是不是Sandbox？

有没有Normalize？

最终访问目录是什么？

如果不知道这些Context，

系统只能采取更保守的判断：

Possible Risk

于是Finding越来越多。

所以：

Threat Model的作用不是直接找到漏洞，而是缩小“什么情况值得被认为是漏洞”。

这也是为什么代码安全越来越依赖：

Repository Context

而不是单纯模式匹配。

---

三、第二层：Discovery——发现的是Candidate，不是结论

真正开始扫描以后，第一阶段应该叫：

Discovery。

而不是：

Vulnerability Detection。

这两个词差别很大。

Discovery的目标应该是：

找到值得继续调查的Candidate。

比如Agent看到：

用户输入
↓
URL校验
↓
Decode
↓
Redirect

这时候合理的结论不是：

存在Open Redirect。

而是：

这里存在一个值得验证的安全假设。

OpenAI在解释Codex Security设计时也提到，它更强调从Repository本身、系统行为和Threat Model出发，再对高信号问题进行验证，而不是简单把静态扫描结果直接作为漏洞列表。

所以Discovery输出最好理解成：

Candidate #1

而不是：

Confirmed Vulnerability #1

---

四、传统扫描为什么很容易在Discovery阶段停下来？

传统静态扫描非常擅长一种逻辑：

Source
↓
Data Flow
↓
Sink

比如：

用户输入：

request.query

一路进入：

database.query()

于是扫描器产生：

Possible SQL Injection

这种模式非常有效。

但真实代码往往还有：

Validation
Encoding
Framework
ORM
Runtime Constraint
Permission
State

OpenAI在介绍Codex Security与传统SAST差异时也指出，静态分析为了在大型真实代码库里可运行，需要对动态分发、回调、反射以及复杂框架控制流做近似；真正困难的问题往往不是“数据有没有到达Sink”，而是中间的安全约束是否真的成立。

这就是误报经常出现的第一个来源：

把可疑数据流直接等同于可利用漏洞。

---

五、第三层：Hypothesis——把Finding改写成“可证伪的安全假设”

这是整个流程里非常重要的一步。

不要问：

这里是不是有漏洞？

应该把它改写成一个具体假设。

例如：

不好：

这里可能有权限绕过。

更好：

假设：
未拥有Resource A权限的普通用户，
可以通过Endpoint B，
读取Resource A。

这样才能继续验证。

一个好的Security Hypothesis通常需要4个部分：

Attacker
↓
Input / Action
↓
Broken Constraint
↓
Impact

例如：

低权限用户
↓
修改某个资源ID
↓
绕过Ownership检查
↓
读取其他用户信息

现在这个问题就从：

模糊怀疑

变成：

可测试命题。

---

六、为什么Hypothesis特别重要？

因为Agent和人都容易出现：

Confirmation Bias。

一旦扫描结果先告诉你：

这里是漏洞。

后面的分析很容易变成：

我怎么证明它确实是漏洞？

而不是：

它到底是不是漏洞？

这两个思维完全不同。

更好的流程应该是：

Suspicious Pattern
↓
Create Hypothesis
↓
Try to Falsify

也就是主动寻找：

有没有什么条件会让这个漏洞不成立？

例如：

是否有上游权限控制？

是否只有管理员能访问？

数据是不是已经Canonicalize？

危险代码实际是否Reachable？

真实Deployment是不是根本没有暴露该入口？

如果这些问题没有回答，

就不能轻易进入下一层。

---

七、第四层：Validation——“理论成立”和“真实成立”之间差很远

假设建立以后，下一步就是：

Validation。

Codex Security当前的自动验证会尝试在隔离Container里复现可疑问题，并记录执行命令、日志和相关Artifacts；如果无法复现，Finding会继续保持Unvalidated，而不是自动当成已确认漏洞。

这一步非常关键。

因为：

Code Looks Vulnerable

和：

Vulnerability Reproduced

完全不是一个Confidence级别。

可以简单分成：

Level 1

Pattern Match

看起来危险。

Level 2

Reasoning

逻辑上似乎成立。

Level 3

Reachability

攻击路径真实可达。

Level 4

Reproduction

在受控环境中成功复现。

越往后，

Finding的可信度越高。

---

八、Validation真正验证的不是“代码有没有执行”

很多人会把验证理解成：

能不能让这段危险代码跑起来？

其实还不够。

真正需要验证的是：

Security Invariant有没有被破坏。

例如：

系统有一个检查：

sanitize(input)

传统分析可能会认为：

有Sanitize，

所以安全。

但真正的问题应该是：

Sanitize之后的值，经过后续Decode、Normalize或Parser处理，是否仍然满足原来的安全约束？

OpenAI举过一个典型思路：如果系统在URL Decode之前先做Allowlist校验，真正需要验证的不是“有没有执行Regex”，而是经过后续Decode和URL解析后，这个约束是否仍然有效。

因此：

Control Exists

并不等于：

Control Works

这是很多复杂漏洞真正出现的地方。

---

九、第五层：Attack Path——漏洞必须有完整路径

Validation之后还有一个非常容易被忽略的东西：

Attack Path。

漏洞不能只证明：

某个函数存在危险行为。

还需要回答：

Attacker
↓
Entry Point
↓
Reachable Code
↓
Broken Control
↓
Sensitive Sink
↓
Impact

这才是一条完整攻击路径。

例如扫描发现：

某个内部函数能够读取任意文件。

听起来非常严重。

但进一步调查：

没有任何外部输入能够控制参数。

调用者只有一个：

adminMaintenanceJob()

并且Job只运行在内部环境。

那么：

Dangerous Function
≠
Exploitable Vulnerability

这个Finding可能仍然值得Hardening，

但严重性判断已经完全不同。

---

十、Reachability为什么是降低误报的关键？

很多安全扫描真正的问题就是：

局部代码看起来危险，全局路径却不可达。

例如：

Dangerous Sink

存在。

User Controlled Source

也存在。

但中间：

Source
↓
Permission Check
↓
Type Constraint
↓
State Validation
↓
Sink

其中任意一层都可能让攻击路径断掉。

所以真正需要回答：

Source到底能不能到达Sink？

而不是：

Source和Sink是不是同时存在？

Codex Security目前的Security Workbench也会把Reachability、Source Evidence、Validation Detail、Impact和Remediation放在同一个Finding视图里，帮助Reviewer判断问题是否真正成立。

这说明安全Finding正在从：

单点告警

变成：

完整证据链。

---

十一、第六层：Evidence——“我觉得存在漏洞”必须变成证据

安全Agent最危险的一种输出方式是：

我分析后认为这里存在严重漏洞。

这种结论对工程团队意义很有限。

真正有用的结果必须带：

Evidence。

至少应该包含：

Affected Code

哪里有问题？

Entry Point

攻击从哪里进入？

Trust Boundary

哪里发生信任变化？

Validation

验证做了什么？

Observed Result

真实观察到了什么？

Impact

最终破坏了什么？

Codex Security目前也会在验证阶段保存命令、日志和相关Artifacts，并在Finding中呈现Validation Evidence。

所以Evidence真正解决的是：

可审查性。

---

十二、Evidence要特别区分Observed和Hypothesis

这是安全报告里非常重要的一条原则。

例如：

Observed

测试环境中，
未认证请求能够进入Handler A。

这是已经观察到的事实。

Hypothesis

因此攻击者可能进一步读取敏感文件。

这还是推断。

两者不能写在一起变成：

未认证攻击者能够读取敏感文件。

否则：

Inference被包装成了Fact。

好的安全分析一定应该区分：

What We Observed

和：

What We Infer

尤其是自动化安全Agent。

因为模型非常擅长构造：

逻辑上很完整的解释。

但逻辑完整：

不代表真实世界已经验证。

---

十三、Deep Scan为什么还需要Coverage，而不是只看Finding数量？

Codex Security的Deep Scan并不是简单：

多跑几次扫描。

官方说明，Deep Scan会进行更深入的Repository Review，并允许多个Discovery Worker和Subagent参与；完成以后还应该先查看Coverage Summary，因为即使Deep Scan也可能存在Deferred Surface和Proof Gap。

这里非常值得注意。

安全扫描最容易出现一个错觉：

0 Findings
=
0 Vulnerabilities

实际上正确逻辑应该是：

0 Findings
+
100% Coverage?
+
Validation Quality?

如果扫描只覆盖：

60%

那么“没有发现漏洞”的意义很有限。

所以安全报告必须同时回答：

What Was Reviewed?

以及：

What Was Not Reviewed?

---

十四、第七层：Report——最后输出的不是“漏洞列表”

很多传统扫描报告最后就是：

Critical 3
High 7
Medium 18
Low 42

然后开发团队开始痛苦地：

一个个Triage。

更好的报告应该优先告诉团队：

哪些问题已经有足够证据。

可以把结果划分成：

Validated

已经复现。

High Confidence

攻击路径和代码逻辑很清楚，但环境原因未完全复现。

Needs Review

存在合理Hypothesis，但仍有Proof Gap。

Hardening

不是已确认漏洞，但设计上值得加强。

这种结果比：

几十个没有证据的“High Severity”

有用得多。

---

十五、Severity和Confidence千万不要混为一谈

这是安全报告里另外一个常见错误。

比如一个Finding：

如果成立，

可能导致：

Remote Code Execution

影响巨大。

所以：

Severity = Critical

但现在只有一段可疑代码。

没有证明Reachability。

没有复现。

那么：

Confidence = Low

两个指标完全可以同时成立。

所以应该分开：

Severity
=
如果是真的，有多严重？

Confidence
=
我们有多确定它是真的？

如果把两者混在一起，

就会出现大量：

“Critical，但没人知道是不是真的。”

这正是安全团队容易产生Alert Fatigue的原因。

---

十六、Repository状态变化为什么会让Evidence失效？

还有一个非常工程化的问题：

假设扫描开始时Repository是：

Commit A

扫描运行几个小时以后，

开发者已经提交：

Commit B
Commit C

这时候Finding针对的到底是哪一份代码？

Codex Security当前在补丁和扫描结果处理里会继续要求匹配原始Checkout和Git Revision，近期插件更新也在加强扫描中断恢复、结果一致性以及文件系统变化后的可靠性。

原因很简单：

Security Evidence必须绑定Code State。

否则：

Evidence
→ Commit A

但Reviewer看到的是：

Commit C

最终就会产生：

“我这里根本复现不了。”

真正可靠的安全Finding至少应该记录：

Repository
Commit
File
Line
Environment
Validation Artifact

安全验证本质上也是：

Stateful Verification。

---

十七、多Worker为什么不能简单理解成“越多越好”？

Deep Scan目前支持多个Discovery Worker，并允许每个Worker进一步启动Subagents。官方也允许通过配置限制Worker数量、Subagent数量、Discovery次数和连续无新Finding后的停止条件。

为什么需要限制？

因为安全探索不是简单：

10 Agents
=
10× Coverage

更多Worker意味着：

更多Token；

更多重复搜索；

更多候选Finding；

更多协调成本。

所以Deep Scan真正需要平衡：

Coverage
Quality
Cost
Runtime

例如对于小型Repository：

无限增加Worker未必创造价值。

对于大型Monorepo：

适当增加并行Discovery可能更合理。

这和所有Agent系统一样：

Parallelism只有在任务可以独立拆分时才真正有效。

---

十八、安全扫描真正应该追求的是“减少人工Triage”

传统Scanner的问题不是：

Finding太少。

往往恰恰相反：

Finding太多。

如果：

1000 Findings

其中：

900 False Positives

真正的问题就变成：

开发者已经不相信Scanner。

所以Agent安全工具真正值得优化的指标不应该只是：

Findings Found

而应该增加：

Validated Findings

False Positive Rate

Human Triage Time

Evidence Quality

Fix Verification Rate

OpenAI也明确把Codex Security的目标之一描述为：在让人投入Review时间之前，提高Finding证据质量并减少Triage负担。

这其实比“扫描到了多少漏洞”更接近真实生产环境。

---

十九、从Threat Model到Evidence，可以建立一套7层检查表

以后看到AI安全扫描结果，不要马上问：

严不严重？

先按照下面7层检查。

1. Threat Model

这个风险是否符合系统真实攻击面？

2. Discovery

扫描器发现的是Candidate，
还是已经验证的问题？

3. Hypothesis

攻击者是谁？
输入是什么？
安全约束在哪里失效？

4. Validation

有没有真实尝试复现？

5. Attack Path

Entry Point到Impact之间是否真实可达？

6. Evidence

有哪些日志、命令、测试和Code State支持？

7. Report

Observed、Hypothesis、Severity和Confidence是否分开？

完整链条就是：

Threat Model
↓
Discovery
↓
Hypothesis
↓
Validation
↓
Attack Path
↓
Evidence
↓
Report

这7层跑完以后，

一个Finding才真正从：

Suspicion

逐渐变成：

Engineering Evidence。

---

二十、真正成熟的安全Agent不是“更敢报漏洞”

这是我觉得AI安全工具最重要的一个趋势。

早期Scanner竞争：

谁能发现更多问题。

但真正进入工程以后，

团队需要的是：

谁能更可靠地告诉我哪些问题是真的。

因为：

Finding数量增加并不一定提高安全性。

如果噪声也同步增加，

最终可能只是让工程团队更快忽略安全工具。

所以成熟的安全Agent应该逐渐从：

Detection System

变成：

Investigation System

甚至进一步成为：

Evidence System

它不仅发现：

“这里可能有问题”。

还要继续回答：

为什么？

攻击路径在哪里？

能不能复现？

Evidence是什么？

修复以后是否真的解决？

---

最后

AI安全扫描最容易产生的误解是：

模型已经很强，所以它发现的漏洞应该都是真的。

实际上越进入真实代码库，情况越复杂。

因为一个漏洞是否成立，最终取决于：

Architecture
Context
Trust Boundary
State
Control
Reachability
Runtime

而不是某一行代码看起来危险。

所以正确流程不应该是：

Scan
↓
Alert
↓
Fix

而应该是：

Threat Model
↓
Discovery
↓
Hypothesis
↓
Validation
↓
Attack Path
↓
Evidence
↓
Report

其中真正最重要的一步，是把：

“可能存在漏洞”

不断推进成：

“这里有一条可验证的攻击路径，并且我们拥有足够证据。”

从这个角度看，Codex Security真正值得关注的地方，并不是它能够生成更多安全Finding。

而是它正在尝试把安全扫描从：

Pattern Detection

推向：

Evidence-Driven Verification。

当AI开始越来越多地参与代码安全审查以后，开发者真正需要建立的也不只是：

怎么让Agent找到漏洞。

而是：

怎么判断Agent找到的漏洞到底是不是真的。

这才是AI安全扫描进入真实工程体系以后，最重要的一道门槛。

持续更新Codex、大模型开发相关技术内容。

长期使用各类代码大模型，整理了稳定的AI会员订阅渠道。