在过去一段时间里，我们对多个开源项目运行了 Codex Security 的安全扫描工具，并对这些项目产生的 findings 做了一次系统性分析。与传统的安全扫描不同，这些报告不仅包含漏洞列表，还提供了完整的攻击路径、动态验证结果以及可应用的修复补丁。 某种意义上，它更像一次自动化安全审计，而不是一次简单的静态代码检查。
这些扫描覆盖的项目大多并不是所谓的“AI 系统”。它们只是普通应用，只不过部分代码由 AI 辅助生成。这一点非常重要，因为它改变了我们理解问题的方式。AI 并没有创造一种新的软件系统类型，也没有发明全新的漏洞类别。最终运行在服务器上的仍然是一个普通应用，它有 API、前端渲染链、数据库访问、外部请求以及部署环境。真正发生变化的，是代码的生产方式。
当代码生成成本下降时，代码产量会迅速上升。如果工程系统没有相应的约束机制，这种增长往往会同时放大缺陷传播速度。因此，与其说我们需要“AI 安全”，不如说我们需要一种新的方式来治理 大规模自动生成的代码。这正是 Harness Engineering 在防御视角下的价值所在。
AI 并没有发明漏洞，只是放大了缺陷
如果从漏洞类型来看，Codex Security 的 findings 并没有太多陌生内容。扫描结果中最常见的仍然是那些已经存在几十年的安全模式：未认证 API、命令注入、SSRF、HTML 渲染未清洗内容以及权限绕过。换句话说，我们面对的仍然是熟悉的软件缺陷。
真正发生变化的不是漏洞类型，而是 缺陷扩散机制。
在传统开发模式中，一个不严谨的实现可能来自某个开发者的疏忽或经验不足。代码 review、测试以及团队经验通常可以在一定程度上阻止这些问题扩散。但在 AI 辅助开发中，一旦模型生成了一种“看起来合理”的实现模式，这种模式就可能在多个模块、多个文件甚至多个仓库中重复出现。模型不会自动理解团队的安全边界， 它只会复现训练数据中常见的实现方式。因此，如果系统没有明确的工程约束，错误实现就可能被系统化复制。
从软件工程角度看，AI 更像一个 缺陷放大器。过去偶尔出现的错误模式，现在可能在短时间内被复制几十次。这也是为什么在 AI 时代，仅依赖人工 code review 已经难以维持同样的安全水平。代码生成速度越高，约束就必须越自动化。
Codex Security 的实现思路
从实现角度看，Codex Security 的扫描流程实际上很好地体现了这种工程化思路。
工具不会只扫描当前代码库的一个快照，而是沿着 Git 历史逐步分析代码的变化。每个发现都能够追溯到具体的 commit、作者以及引入时间，这意味着漏洞不再只是一个静态问题，而是一个可以被定位到“何时进入系统”的变更事件。这种分析方式与持续交付的开发流程非常契合， 因为安全问题往往正是在这些细小的代码修改中被引入。
在代码层面，扫描依赖的是静态分析与数据流追踪的结合。分析会从典型输入源开始，例如 HTTP 请求参数、RPC 调用或 URL 查询字符串，然后沿着代码路径追踪数据的传播过程，直到抵达危险操作，例如 shell 执行、HTML 渲染或外部网络请求。通过这种方式，工具不仅可以发现某个危险函数的使用，还可以理解数据是如何从外部输入一路传播到执行点，从而还原完整的攻击路径。
在识别潜在漏洞之后，系统还会尝试模拟攻击场景并进行动态验证。扫描器会在沙箱环境中生成 PoC 并尝试触发攻击路径，例如执行命令注入或访问内部服务。如果验证成功，报告会标记该漏洞已经被实际利用，从而显著降低误报。最后，每个 finding 都会附带一份可应用的补丁，例如为接口增加认证、替换危险调用或移除高风险配置。这样的输出方式让扫描结果不仅指出问题，也直接推动修复。
新的扫描模式：AI 范式带来的风险
在分析 Codex Security 的 findings 时，我们还观察到了一类新的风险模式。这些问题并不是传统应用中的典型漏洞，而是与 AI 开发工具的行为直接相关。例如在多个项目中，都出现了类似这样的配置：
--dangerously-skip-permissions--allow-all-toolsbypassPermissions:true
这些参数通常出现在 AI Agent 或 CLI 工具的启动配置中，其目的往往是减少交互成本，让 Agent 可以自动调用工具。在本地开发环境中，这种配置可能只是一个便利选项。但一旦代码被部署到服务器环境，这类参数就可能绕过所有权限确认机制， 使系统能够在没有用户干预的情况下执行高风险操作。
这种风险与传统漏洞的不同之处在于，它并不是某一段代码的问题，而是 工具行为与系统环境之间的不匹配。 模型可能会生成这些参数，因为它们在某些示例中是合法的；但在真实系统中，它们意味着权限控制被完全绕过。
因此，AI 时代的安全扫描开始出现新的方向：不仅需要检查代码中的危险调用，还需要识别 AI 工具的危险使用模式。 这些模式往往隐藏在配置、命令行参数或工具调用链中，如果没有专门规则，很容易被忽略。
Harness Engineering 的防御意义
从这个角度看，Harness Engineering 不只是一个提升 AI 编程效率的实践，它同样是一种防御架构。
Harness Engineering 的核心思想，是把系统的结构、规则和边界明确表达出来，使 AI 能够理解并遵守这些约束。在防御视角下，这意味着两件事。首先，危险能力需要被收敛到少数受控接口中，例如统一的外部请求客户端、安全的 HTML 渲染器或受限的命令执行层。其次，系统需要具备自动化的检查机制，以便在代码进入主干之前识别高风险模式。
当这些机制存在时，无论代码是由人类编写还是由 AI 生成，它都会经过同一套工程约束。系统不再依赖开发者记住每一条安全规则，而是通过架构本身来减少误用空间。
这种方式的优势在于，它并不试图判断代码的作者是谁，而是关注代码是否违反了工程系统的安全边界。
从扫描到治理
把这些观察放在一起，一个更清晰的结论就出现了。AI 时代的软件安全问题，并不是因为 AI 本身不安全，而是因为代码生成速度已经超过了传统治理方式的承载能力。手动 review、零散规范和经验判断，很难在高吞吐代码生产环境中保持同样效果。
工具化扫描因此不再只是安全团队的辅助工具，而逐渐成为工程系统的一部分。它们的角色类似于测试或 CI 检查：在代码进入主干之前，自动识别那些已知危险模式。通过这种方式，团队可以把安全约束从“开发者需要记住的规则”转变为“工程系统自动执行的策略”。
在这种模式下，Harness Engineering 的意义就变得更加清晰。它不仅帮助 AI 更好地理解系统，也帮助系统更好地约束 AI 和人类共同生成的代码。安全不再依赖作者的经验，而是由工具和架构共同保证。
软件工程系统的下一步
从 Codex Security 的扫描分析中得到的最大启发，并不是 AI 让软件变得更危险，而是 AI 让工程系统中长期存在的问题变得更加明显。当代码生成能力提升时，工程系统必须具备更强的自动化防御能力，否则缺陷只会以更快速度进入代码库。
在这个意义上，AI 时代的软件工程并不是一个完全新的领域。它只是把一个旧问题推到了新的规模：当代码越来越多时，我们如何确保系统仍然保持正确的边界与约束。
Harness Engineering 提供的答案，并不是让 AI 更聪明，而是让软件工程系统本身变得更强壮。
