V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member  Sign In
爱意满满的作品展示区。
nnnnon

做了个开源的 AI 代码安全智能体 mythos-agent,想在 V 站求轻拍

  •  
  •   nnnnon ·
    zhijiewong · 4 days ago · 253 views

    大佬们,我在这分享一个最近捣腾的开源项目:mythos-agent 一个 AI 驱动的代码安全智能体。

    简单说下为什么做这个,以及怎么跑。

    起点

    Semgrep / Snyk / CodeQL 这类扫描器用多了,会发现一个很现实的问题:它们能找到的漏洞,基本就是规则库里写过的那些。规则库覆盖不到的结构变体 —— 比如 eval 不是直接作用在 req.body 上,而是中间过了两层函数、变量名被改了 —— 基本就漏掉了。

    做一段时间代码审计之后,我意识到人在读这类代码时其实是在提假设

    "这里 path.join 拼了用户传的 path ,但没解析 symlink ,是不是路径穿越?" "这里对同一行先读后写,没加锁,是不是 TOCTOU 竞态?"

    传统规则匹配做不到这一步,但 LLM 可以。mythos-agent 做的就是这件事:在传统 AST 扫描之上,加一层 LLM 假设生成 + 验证。不是用 LLM 替代规则库,是给规则库补一个"大胆假设、小心求证"的 stage 。

    三条命令先跑起来

    npx mythos-agent scan        # 纯规则扫描,不需要 API key ,完全离线
    npx mythos-agent hunt        # 完整 AI 假设 + 验证流水线(需要 LLM 端点)
    npx mythos-agent quick       # 10 秒快速体检
    

    典型输出:

     ✗ src/api/transfer.ts:38   [HIGH, conf 0.88]
       Hypothesis: 对 balance 的读-改-写没加行锁,并发请求可能双花。
       Evidence:   line 42 读 balance ,line 51 写 balance - amount ;
                   作用域内没有 FOR UPDATE / 事务隔离。
       Suggested:  BEGIN ... SELECT ... FOR UPDATE ... COMMIT ,
                   或 SERIALIZABLE 隔离级别。
    

    架构

    四个阶段:Recon → Hypothesize → Analyze → Exploit( Exploit 默认关闭)。

    关键是 Hypothesize 和 Analyze 分成两个 agent。Hypothesize 阶段让模型"大胆假设"——允许它对每个函数产出很多不一定成立的具体猜测; Analyze 阶段让另一个 agent 逐条去验证,带置信度打分。两步合成一个 prompt 会退化成"模型既出题又打分",实际结果是生成一堆看起来合理但实际不存在的 false positive 。

    分成两个 agent 之后,--severity high 这种阈值过滤才真的有意义。

    技术选型

    • TypeScript 写的,TS/JS 用 Babel 解析器,其他语言( Python 、Go 、Java 、PHP 、Rust 、C/C++)走各自的 parser 适配器,统一到一个 normalized CST
    • 43 个扫描分类( 15 个正式上线,28 个实验中):SQL 注入、SSRF 、路径穿越、命令注入、XSS 、JWT 算法混淆、竞态、加密误用、AI/LLM 安全( prompt injection 、cost attack )、供应链( typosquatting )、零信任、隐私/GDPR 等
    • 329+ 条内置规则,8 种目标语言
    • 后端支持 Claude 、GPT-4o 、Ollama ,以及任意 OpenAI 兼容端点;纯规则模式完全离线,不需要任何 API key
    • 输出 SARIF 2.1.0 ( GitHub Code Scanning 直接能用)、HTML 报告、JSON
    • 发布产物用 Sigstore (cosign) 签名,附带 CycloneDX SBOM

    目前难题

    • 动态类型语言 (Python 、JS) 的 false positive 比静态类型语言多。类型信息是 Analyze 阶段的重要信号,没有的话整体置信度偏低。
    • 跨第三方依赖的污点追踪会丢信号。污点流进一个没源码的 dep ,假设阶段只能按 public API 推测,容易过度生成。
    • 成本。全仓跑假设生成用 Claude / GPT-4o 一次不便宜,CI 里建议只跑 diff 。

    适合谁用

    • 平时写 TypeScript / Node.js 后端,想给 CI 加一层 SAST 又不想买商业扫描器
    • 给 LLM 集成类项目做安全审查( prompt injection / 客户端 API key 泄漏 / 未鉴权的付费模型调用这几类传统 SAST 基本覆盖不到)
    • 对 SAST + LLM 的结合方式感兴趣,想看看一个开源实现长什么样

    最后

    MIT 协议,v4.0.0 今天刚发。欢迎拍砖,特别想听几个方向的反馈:

    1. 假设生成这套路子,你们有没有踩过类似的坑?哪些假设类型特别容易翻车?
    2. 对动态类型语言的 AST 归一化,有什么经验?
    3. SARIF 2.1.0 除了 GitHub Code Scanning ,还有哪些下游消费者真的能把字段完整渲染出来?

    如果有 bug 或者 false positive 例子,直接开 issue ,最好附一小段能复现的代码片段。谢谢各位。

    No Comments Yet
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   5782 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 136ms · UTC 07:15 · PVG 15:15 · LAX 00:15 · JFK 03:15
    ♥ Do have faith in what you're doing.