CodeMender 预览：把漏洞扫描、可利用性验证和补丁生成串成一条流水线

传统代码安全工具通常停在“发现问题”：扫描器产生告警，安全团队判断真假，开发者再编写补丁、运行测试并提交代码。CodeMender 的变化在于，它试图把扫描、漏洞验证、补丁生成和回归测试连接成一个由安全代理执行的闭环，同时保留开发者的最终审批权。

目前 CodeMender 处于预览阶段，可通过 Gemini Enterprise Agent Platform 使用已正式可用的 Gemini 模型，也可以作为 AI Threat Defense 的核心组件部署。它采用多模型路线，允许团队根据成本、扫描速度、深度分析和编码能力选择模型，并计划在后续支持第三方前沿模型。

从告警列表走向可验证的风险

CodeMender 的工作流可以概括为三个阶段：Scan、Verify 和 Remediate。

扫描阶段不只匹配孤立的危险函数或语法模式，而是结合仓库目标、程序功能和代码上下文寻找漏洞。其覆盖的风险类型包括内存破坏、注入、Web 安全问题、密码学缺陷和不安全的数据处理，支持 C/C++、Go、Java、Python、Ruby、Rust 与 TypeScript 等常用语言。

验证阶段是这套流程与普通静态扫描器的重要区别。代理可以制定验证计划，在客户管理的隔离沙箱中构建并运行概念验证代码，判断漏洞是否真的能够被利用。这让团队能够按照可利用性而不只是静态严重级别安排修复顺序，也能减少误报带来的告警疲劳。

修复阶段会生成针对性的代码差异并执行测试。CodeMender 还会使用 LLM-as-a-judge 检查补丁是否可能破坏原有功能，并可根据团队提供的编码约定调整补丁风格。不过，生成结果不会绕过代码评审：开发者仍需检查并批准补丁，代码才应进入仓库。

这种闭环的价值不只是“AI 会写补丁”，而是把证据一并送到评审者面前：漏洞位置、验证方案、可执行利用结果、代码差异和测试结果可以形成一条可审计链路。

接入点决定了安全边界

CodeMender 可以集成到 CI/CD，也可以通过轻量 CLI 在本地开发环境运行，并能连接代码仓库及 VS Code 等开发工具。扫描和利用验证还可以放在客户自行管理的沙箱中执行。

平台侧提供了面向企业环境的治理能力，包括通过 VPC 进行安全流量路由、数据隔离与加密，以及源代码数据零保留。即便如此，团队仍应把代理视为能够读取代码并执行程序的高权限主体，明确以下边界：

• 默认使用只读仓库令牌，仅在创建修复分支或拉取请求时临时提升权限。
• 验证环境不得持有生产凭据，也不应直接访问生产网络和客户数据。
• 对网络出口、CPU、内存、运行时间和磁盘容量设置硬限制。
• 补丁必须通过现有单元测试、集成测试、静态检查和人工评审。
• 保存代理版本、模型选择、提示上下文、验证证据和审批记录，以便审计与复现。

“客户管理的沙箱”尤其关键。概念验证程序本质上是在主动触发缺陷；内存破坏、命令注入或路径穿越测试都可能改写文件、启动子进程或访问网络。把它们直接放进普通 CI Runner，会让验证能力本身变成新的攻击面。

可以这样实践：为安全代理准备隔离的 CI 作业

下面是一个可改造的 GitHub Actions 示例。这是根据来源描述设计的集成骨架，并非 CodeMender 官方 CLI 语法。接入预览版时，需要把占位命令和镜像替换为实际文档提供的客户端、认证方式及参数。

name: agentic-security-review

on:
  pull_request:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  scan-and-verify:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - name: Check out untrusted code without credentials
        uses: actions/checkout@v4
        with:
          persist-credentials: false

      - name: Run scan in a restricted container
        env:
          CODEMENDER_TOKEN: ${{ secrets.CODEMENDER_TOKEN }}
        run: |
          mkdir -p "$RUNNER_TEMP/codemender-output"
          docker run --rm \
            --network none \
            --read-only \
            --cap-drop ALL \
            --security-opt no-new-privileges \
            --memory 4g \
            --cpus 2 \
            --pids-limit 256 \
            -e CODEMENDER_TOKEN \
            -v "$GITHUB_WORKSPACE:/workspace:ro" \
            -v "$RUNNER_TEMP/codemender-output:/output" \
            YOUR_APPROVED_CODEMENDER_IMAGE \
            codemender scan \
              --source /workspace \
              --verify-exploitable \
              --patch-output /output/fix.diff \
              --report-output /output/report.json

      - name: Upload evidence for human review
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: codemender-review
          path: |
            ${{ runner.temp }}/codemender-output/report.json
            ${{ runner.temp }}/codemender-output/fix.diff
          retention-days: 14

运行前至少要修改三处：将 YOUR_APPROVED_CODEMENDER_IMAGE 换成经过组织审核的镜像；将 codemender scan 参数替换为预览服务的真实命令；根据网络架构决定是否允许代理访问受控 API 端点。示例中的 --network none 适合完全离线的验证容器，如果代理必须调用托管模型，应通过独立代理或严格的域名白名单开放出口，而不是允许任意联网。

更稳妥的生产流程可以拆成两个权限等级不同的作业：第一个作业只读扫描并生成报告；安全人员确认需要验证后，第二个作业在一次性沙箱中运行利用代码；验证成功后，第三个作业生成补丁，但只创建待评审的差异或拉取请求。任何阶段都不应自动合并到受保护分支。

多模型不是简单的成本开关

CodeMender 允许按照成本、速度、深度扫描和编码表现选择模型。实际落地时，不必让所有提交都运行最昂贵的深度分析。可以建立分层策略：

模型判断仍然不是漏洞存在或补丁正确的最终证明。LLM-as-a-judge 可以增加一道检查，但不能替代确定性的编译、测试、模糊测试、静态分析和人工安全评审。对于并发、密码学、内存安全边界以及业务授权逻辑，更应要求领域专家批准。

在试点中衡量闭环，而不是扫描数量

引入 CodeMender 时，可以先选择一个测试充分、依赖边界清晰且不接触生产数据的仓库。评价试点效果时，重点记录经过验证的漏洞比例、误报率、从发现到可评审补丁的时间、补丁测试通过率、人工修改量和回滚率，而不是单纯统计告警总数。

上线前的检查清单应包括：

• 沙箱与生产网络、凭据和数据完全隔离。
• 仓库权限遵循最小权限原则，禁止代理直接合并代码。
• 利用代码、补丁和报告有明确的保留与脱敏策略。
• 深度扫描按风险触发，避免模型成本失控。
• 现有测试能够覆盖关键业务行为和安全不变量。
• 预览产品的接口、模型行为和服务边界可能变化，集成层应便于替换。

CodeMender 展示的是一种从“报告漏洞”转向“验证并提交可测试修复”的工作方式。它有机会缩短零日风险暴露时间，但真正决定效果的仍是沙箱隔离、权限控制、测试质量和人工审批。把这些基础设施准备好，安全代理才能提高修复速度，而不会把自动化速度变成新的风险放大器。