Marico's space
最近折腾跨仓库安全扫描，踩了不少状态同步和告警去重的坑，这篇把 CodeRabbit Secure 的思路说清楚。重点不是它又能扫几个仓库，而是当一个共享库里的漏洞牵连几十个下游项目时，怎么沿着依赖图追踪，又不让扫描范围和告警数量一起失控。
CodeRabbit Secure 现在可以越过仓库边界扫描，沿着依赖关系追踪漏洞，再在临时沙箱中验证漏洞能否真正利用。真正的难点在于状态管理：一个共享库存在漏洞，可能影响 50 个下游仓库，既不能触发指数级重扫，也不能给团队灌进几十条重复告警。
大多数安全工具都止步于仓库边界：扫描自己维护的代码，标出问题，然后把跨仓库关联留给人工。CodeRabbit 新增的 Deep Scan（深度扫描）把依赖图视为真正的攻击面，并通过多个安全智能体（agent）协同遍历。
Deep Scan 分三个阶段：建立基线、跨仓库遍历、增量对齐。
建立基线会对目标仓库中已经提交的代码执行完整语义分析。智能体在内部构建数据流、API（应用程序接口）边界和外部依赖组成的图谱。这不是一次差异扫描，它会检查整个代码库，找出几个月甚至几年前就已发布的漏洞。
跨仓库遍历在智能体发现依赖链接时启动。如果漏洞追踪路径进入关联仓库，例如共享库、Monorepo（单体仓库）中的同级项目，或者被 vendored（以源码形式复制进项目）的模块，智能体会在该仓库中创建新的扫描上下文。每个上下文独立维护状态，同时与父级扫描共享一个关联 ID（correlation ID）。
增量对齐在代码合并后执行。智能体不会重新扫描整个代码库，而是只复查发生变化的文件，以及此前验证结果已经失效的区域。这样既能持续更新安全覆盖，又不必重复执行昂贵的全量扫描。
智能体维护三类状态：
当智能体进入关联仓库时，会序列化当前扫描上下文，并把一个边界明确的数据子集传给新扫描。这个子集包括漏洞签名、触发边界跳转的调用链，以及一个递归深度计数器。
递归深度计数器用于避免无限循环。如果智能体检测到循环依赖，例如仓库 A 依赖 B、B 依赖 C、C 又依赖 A，它会在可配置的深度上限处停止遍历。默认最多跨 3 跳。
静态分析会产生误报。一条看起来可以利用的代码路径，可能在运行时根本不可达；调用栈中其他位置的输入校验也可能消解威胁。CodeRabbit 的运行时验证会启动一个临时沙箱，重放漏洞利用请求，确认漏洞是否真实存在。
沙箱是带检测钩子的容器化应用副本。智能体根据静态分析结果构造漏洞利用载荷（payload），从已经识别的入口注入，然后监控是否成功利用，例如任意代码执行、数据外泄或权限提升。
如果利用成功，对应发现会被标记为已确认；如果失败，智能体会记录失败原因，例如输入已被净化、代码路径不可达、权限不足，然后降低严重等级。
沙箱执行成本不低，因此 CodeRabbit 只选择性地验证高价值发现：
一个共享库中的漏洞可能扩散到几十个下游仓库。粗暴扫描会为每个受影响仓库生成一条告警，整个待办列表很快就被重复项淹没。
CodeRabbit 的关联引擎按根因对发现结果进行分组。当智能体在多个仓库中检测到相同漏洞签名时，会检查这些仓库是否依赖同一个公共组件。如果确实如此，系统只创建一个父级发现，再把各仓库中的出现记录作为子项挂上去。
父级发现包含：
开发者最终看到的是一条可执行事项，而不是 50 条重复告警。
CodeRabbit 使用协调器—执行器模式。协调器接收扫描请求，构建初始依赖图，再把任务分发给不同仓库的执行智能体。
每个执行智能体会完成以下工作：
协调器掌握所有活跃扫描的全局视图。当执行器请求跨仓库遍历时，协调器会先检查目标仓库是否已经在扫描中。如果正在扫描，就合并两个扫描上下文，而不是再启动一个重复的执行器。
执行器通过消息队列通信。按照典型的智能体架构推测，底层可能使用 Redis 或 RabbitMQ。协调器则在分布式状态存储中跟踪扫描进度，以处理执行器故障和重试，存储层可能采用 etcd 或 DynamoDB。
| 层级 | 工具 | 职责 |
|---|---|---|
| 静态分析 | Semgrep、自定义 AST（抽象语法树）解析器 | 识别代码模式、数据流和 API 调用 |
| 依赖解析 | 语言专用解析器，例如 npm、pip、Maven | 构建依赖图，解析具体版本 |
| 跨仓库遍历 | 自定义编排智能体 | 管理扫描状态、分发执行器、关联发现结果 |
| 运行时验证 | 沙箱容器，例如 Docker 或 Firecracker | 执行漏洞利用尝试，确认可利用性 |
| LLM（大型语言模型）推理 | GPT-4 或 Claude | 生成漏洞利用载荷、建议修复方式、解释攻击路径 |
LLM 不负责执行静态分析。它接收 Semgrep 等工具产生的结果，再推理漏洞可利用性和修复方案。这样可以让 LLM 集中处理理解上下文、生成修复等高价值任务，同时避免用大模型做模式匹配所带来的延迟和成本。
依赖图不是树，而是包含共享节点的有向无环图（DAG）。一个库可能同时出现在几十个位置。直接遍历会导致扫描任务指数级膨胀。
CodeRabbit 设置了三层限制：
深度限制可以配置。依赖链较深的团队可以调高它，但成本也会迅速增加。每多跨一跳，扫描仓库数量都可能成倍增长。
广度限制用于阻止失控扫描。如果一个 Monorepo 包含 500 个内部包，智能体会根据使用频率、安全历史以及开发者设置的优先级，扫描其中最关键的 100 个，其余直接跳过。
首次 Deep Scan 完成后，CodeRabbit 会切换到增量模式。每次提交时不再重扫整个代码库，只检查发生变化的文件，以及此前验证结果已经失效的区域。
结果失效由以下条件决定：
增量扫描会在合并时自动执行。智能体比较当前提交和上次扫描时的提交，识别差异并重新检查受影响的代码路径。如果差异涉及调用关联仓库的文件，智能体会针对这条特定调用链触发跨仓库遍历。
这样既能持续更新安全覆盖，又不必承担全量重扫的成本。
如果存在尚未解决的严重安全问题，CodeRabbit 可以阻止 PR 合并。Security Check 会作为 GitHub 状态检查或 GitLab 流水线阶段运行。一旦智能体发现严重漏洞，例如 RCE、SQL 注入或认证绕过，检查就会失败，在问题修复前无法完成合并。
开发者可以手动审批覆盖阻断，但覆盖操作会被记录下来，并显示在安全仪表盘中。
CodeRabbit 通过 Webhook（网络钩子）把发现结果送入 Jira 和 Linear。每条发现都会生成一个工单，包含：
API（应用程序接口）还支持以 JSON（JavaScript 对象表示法）格式导出发现结果，便于团队接入自己的仪表盘、SIEM（安全信息与事件管理）系统或合规报告工具。
沙箱超时：如果运行时验证沙箱没有在超时时间内完成，默认是 5 分钟，对应发现会被标记为未验证，并降低严重等级。
依赖解析失败：如果智能体无法解析依赖，例如私有镜像源、网络故障或缺少凭据，它会跳过依赖图中的对应分支，并记录警告。
关联冲突：如果两个互不相关的漏洞产生了相同签名，智能体可能会错误地将它们分组。这种情况很少出现，但确实存在。缓解方式是人工复核被分组的发现。
执行器崩溃：如果执行智能体在扫描过程中崩溃，协调器最多重试 3 次。所有重试都失败后，扫描会被标记为未完成，并通知对应团队。
以下情况适合使用 CodeRabbit Secure 的跨仓库扫描：
以下情况不太适合：
跨仓库遍历和运行时验证是 CodeRabbit Secure 最有辨识度的能力。如果团队用不到这两项能力，更轻量的单仓库扫描器通常更快，也更便宜。