Security Swarm 是 Devin 的安全扫描与修复产品。它会根据你的代码构建专属威胁模型，调查并验证潜在漏洞，并通过拉取请求帮助你修复发现项。它可以识别远程代码执行 (RCE) 、SQL 注入、路径遍历、服务器端请求伪造 (SSRF) 、授权绕过、内存安全 bug、拒绝服务漏洞等各类漏洞，甚至还能识别跨多个文件的链式利用。
Security Swarm 是一种由多个 Devin 组成的定制编排，我们称之为 Agentic MapReduce 。它会将你的代码仓库拆分给并行运行的 Devin，在控制成本的同时兼顾广泛覆盖和深入调查，因此能够高性价比地扫描大型代码库。我们还将 Security Swarm 与 GitHub Advisory Database 中公开漏洞的真实标注数据集进行了基准测试对比。
要运行一次扫描：
你的组织必须有权访问你要扫描的代码仓库。
你需要已获授权使用 Devin 会话。
你需要具备 Use code scans 权限。
要配置自动扫描计划，你还需要具备 Manage code scans 以及管理 Automations 的权限。
如果你在侧边栏中看不到 Security ，或者无法启动扫描，请让管理员检查你的角色。详情请参见 访问与权限 。
在左侧边栏中打开 Security ，然后点击 Start scan 。
在 Single repo 下，选择一个要扫描的代码仓库。
确保已启用 交互模式 。
点击 Run Scan 。
当系统建议的威胁模型 准备就绪后，先审阅，再点击 Looks good, start scanning 或提出反馈。
随着发现项陆续出现，查看相关证据，并处理需要关注的发现项 。
对于需要重复执行的扫描，创建一个 Profile 来记录你的作用域、威胁模型、严重性标准、验证步骤和修复约束。
打开某次扫描即可查看其发现项。页面左侧显示按严重程度分组的发现项列表，右侧显示当前选中发现项的详细信息。
状态选项卡会显示实时数量：
打开 — 需要关注。已审查 — 已完成审查，不再需要处理。已忽略 — 被判定为误报或重复项。
扫描运行期间，页面会随着发现项的到达自动更新。
已审查 是一种工作流程状态，并不表示某个修复已合并。发现项既可以被手动标记为“已审查”，也可以在后续扫描判定其已不再存在时被标记为“已审查”。
一个发现项包括：
严重性、状态、可利用性、置信度和类别 。受影响的文件路径和代码片段 。
问题的描述 以及修复建议 。
运行时验证结果 、支持性证据和验证产物。关联的**拉取请求 (PR) **及其打开、已合并或已关闭状态。
代码所有者 和备注 (如有) 。
将高风险代码模式视为线索，而不是漏洞已被证实的依据。检查该发现项是否说明了从攻击者可控输入出发的可达路径，是否考虑了输入验证和授权控制，以及是否解释了具体的安全影响。
启动一个 Devin 会话来修复该问题并创建拉取请求。该会话及其生成的拉取请求都会在该发现项中跟踪。
将上下文发送到反馈会话，以优化后续扫描的扫描 Profile。例如，说明某个上报的数据流受到内部网关保护，这样后续扫描就能将该控制措施考虑在内。
覆盖该发现项的严重程度，并可选择为 Devin 提供上下文。例如，当利用漏洞需要特权内部访问权限时，可降低严重程度，并将该限制条件作为上下文一并提供。
将发现项标记为“Open”“已审查”或“已忽略”。当发现项仍需处理时，将其保持为“Open”；完成分流后，将其标记为“已审查”；如果它是误报或重复项，则将其设为“已忽略”。
扫描 Profile 用于控制扫描作用域，并为扫描的各个阶段提供指导。每次扫描只能使用一个 Profile。若要针对多个攻击者画像或威胁类别评估同一个代码仓库，请分别使用不同的 Profile 运行扫描。
清晰具体的威胁模型，是让不同扫描之间的覆盖范围保持一致的最有效方法之一。请定义攻击者、敏感资产、信任边界、重要入口点以及明确的排除项。
可在 Security 页面中的 Profiles 选项卡中管理 Profile。
你可以通过两种方式创建 Profile：
使用 Devin 生成 — 用自然语言描述应用程序、威胁、作用域、排除项和严重程度标准。Devin 会为你起草 Profile。手动创建 — 你自己填写 Profile 的每个输入项。
使用 Devin 生成是一个很好的起点，但在使用该 Profile 之前，请检查每个生成的字段。将可选指导字段留空，将对此阶段应用 Security Swarm 的内置行为。
Profile 名称 — 应按应用程序暴露面或威胁类别命名，而不是按执行扫描的团队命名。示例：Multi-tenant API authorization。描述 — 概述该 Profile 的作用域和安全目标。示例：查找公共 API 中的身份验证、授权和租户隔离漏洞。
下面的示例可组合成一个适用于多租户 API 的单个 Profile。请根据你的应用程序调整边界、命令和严重性标准。
请描述攻击者、敏感资产、信任边界、重要入口点，以及任何明确不在作用域内的内容。这些说明将决定 Devin 在调查开始前生成的规则。
假设攻击者为未经身份验证的互联网攻击者，或某一租户中已通过身份验证的用户。 重点关注公开的 HTTP 处理程序、OAuth 回调、API 令牌、管理操作， 以及对租户数据的访问。将内部开发脚本和仅限本地的工具视为超出范围。 优先排查身份验证 Bypass、跨租户访问、令牌泄露、注入攻击和 SSRF。
说明 Devin 应如何调查潜在问题，以及需要收集哪些证据。要求它结合现有缓解措施进行评估，并区分可被利用的漏洞与理论上的担忧。
Trace untrusted input from the route through middleware and service layers to the sensitive operation. Check authentication, authorization, tenant scoping, validation, and escaping at every boundary. Identify the exact reachable path and cite the relevant files and lines. Do not report a theoretical issue when an effective mitigation blocks the path.
定义 Devin 应如何对发现项去重并确定优先级。请包含你的严重程度判定标准，以便结果符合你的组织的标准。
将具有相同根本原因的发现归为一组。将未经身份验证的远程代码执行和跨租户写入访问视为严重级别。将跨租户读取访问和凭据泄露视为高级别。将单用户可用性问题视为中级别，除非其可能影响共享基础架构。将纵深防御建议标记为低级别。
当 Devin 可以安全地构建并实际操作应用程序时，请启用运行时验证。请说明如何启动应用程序、创建测试数据、完成身份验证，并演示预期的安全边界。
使用代码仓库中已记录的开发环境配置。启动 API 并创建两个非生产租户，每个租户中各有一个测试用户。以另一个租户的用户身份发起可疑请求，然后验证 HTTP 响应和持久化数据。 请勿调用生产服务或修改生产数据。
验证未成功并不一定说明某项发现项不成立。请查看验证结果和工件，以判断是有效的缓解措施阻止了漏洞利用，还是环境配置导致 Devin 无法完成测试。
运行时验证会为每项发现项启动一个独立的 Devin 会话。有关环境方面的说明，请参阅 配置运行时验证 。
当你需要在扫描后生成摘要报告时，请启用报告。请指定目标受众以及报告应重点突出的信息。
为安全和工程负责人撰写一份执行摘要。首先列出已确认的严重和高危发现，其次列出未经验证的发现。包括受影响的组件、验证状态、拉取请求（PR）状态以及按优先级排序的修复计划。
当你将某个发现项分配给 Devin 处理时，请明确 Devin 需要遵循的约束条件。包括测试要求、兼容性要求以及需要避免的做法。
优先采用最小安全变更，并保留现有的公共 API 行为。添加一个 回归测试，使其在修复前失败、修复后通过。运行受影响软件包的 lint 和测试命令。除非不进行升级就无法安全修复该漏洞，否则避免进行重大依赖项升级。
打开 Advanced 以控制文件作用域和调查批次：
Include globs — 将扫描范围限制为匹配的文件。例如，apps/api/** 和 packages/auth/**。Exclude globs — 从所选作用域中排除无关文件。例如，**/generated/**、**/vendor/** 和 **/fixtures/**。Batch size — 控制每个调查批次中包含多少个带有信号的文件。除非你是有意调整扫描行为，否则请保留默认值。可接受的范围是 1–500；默认值为 5。
排除范围过宽可能会隐藏存在漏洞的代码，或移除理解数据流所需的上下文。仅排除你确信与该 Profile 无关的文件。
新的 Profile 具有组织级作用域。Enterprise admins 之后可以将 Profile 的可见性更改为 Enterprise ，使其在整个企业内可用。
企业级 Profile 只能由 Enterprise admins 编辑或归档。其他有权访问 Security 的 users 可以查看和使用这些 Profile，但无法修改。
启用 交互模式 后，Devin 会先构建一个建议的威胁模型，并在开始调查前暂停。扫描页面会显示建议的规则，并让你可以：
没问题，开始扫描 — 接受该威胁模型并开始调查。针对威胁模型提供反馈 — 说明需要添加、删除或强调的内容，然后查看修订后的模型。
对于代码仓库的首次扫描，以及其风险暴露面或 Profile 发生重大变化时，建议使用交互模式。一旦 Profile 纳入了已批准的指导，常规扫描即可无需暂停直接运行。
只有在所选 Profile 已启用运行时验证且包含验证指引时，才会执行运行时验证。请向 Devin 提供足够的信息，以便它能在其沙盒中构建、运行、填充种子数据并完成应用程序认证。
如果代码仓库具有声明式配置 ，Devin 可以复用其中的构建和安装配置。否则，请将所需的设置命令添加到 Profile 的验证指引中。
不要将生产凭据或敏感值直接写入 Profile 指引。请使用非生产测试账户和凭据，并通过你的组织的环境配置提供这些内容。
在“新建扫描”对话框中，使用 所有代码仓库 选项卡即可为整个组织中的代码仓库批量排队扫描：
可选择输入 代码仓库名称筛选条件 。
可选择扫描 Profile。
保持 跳过已扫描的代码仓库 处于启用状态，以排除已用所选 Profile 扫描过的代码仓库。
点击 预览 。
查看匹配的代码仓库，取消选择你不想扫描的代码仓库，然后确认。
预览只是一次试运行。更改筛选条件、Profile 或 skip 设置都会使预览失效，因此你无法确认过时的列表。
自动扫描会定期扫描自上次完成扫描以来新增的提交。你可以按以下方式进行配置：
在启动单个代码仓库扫描时，选择按日、按周、按月或自定义计划。
对于现有扫描，可添加、编辑、禁用其计划，或立即运行该计划。
自动扫描是通过 自动化 实现的。配置它需要同时具备 管理代码扫描 和管理自动化的权限。计划时间会按你的本地时区显示。
对于已完成的扫描，点击 扫描新提交 ，即可查看自上次扫描的提交以来新增的提交。自动扫描也采用相同的增量机制，因此后续扫描比反复扫描整个代码仓库作用域的成本更低。
根据扫描及其 Profile，扫描标头中可能包含：
报告 — 下载为该扫描生成的报告。用量 — 查看消耗的 ACU、会话数、扫描时长以及 PR (拉取请求) 统计信息。会话 — 打开执行该扫描的主 Devin 会话。导出为 CSV — 导出扫描的发现项。归档 或 取消归档 — 将扫描从默认列表中隐藏，或将其恢复到默认列表。扫描新的提交 — 启动增量扫描。
扫描作为 Devin 会话运行，并会消耗 ACUs 。
在组织完成首次扫描后，Security 页面会显示整个组织在最近 7、30 或 90 天内的仪表板：
拉取请求统计 — 已创建、已合并、处于打开状态和已关闭的拉取请求，以及合并率。发现项趋势 — 在所选时间段内按严重程度分组的发现项。
安全访问通过角色编辑器中的代码扫描权限来控制：
权限 解锁的功能 默认角色 查看代码扫描 查看扫描、Profile、发现项以及关联的扫描会话。 Admin 使用代码扫描 启动扫描、创建组织 Profile、提交发现项反馈、调整发现项、更改发现项状态，以及将发现项分配给 Devin。 Admin 管理代码扫描 归档或取消归档扫描，并配置 Auto Scan 计划。 Admin 管理账户代码扫描 将组织 Profile 提升到企业作用域，并编辑或归档企业 Profile。 Enterprise Admin
启动扫描、提交反馈以及将发现项分配给 Devin，还需要具备使用 Devin 会话的权限。Auto Scan 还要求具备管理 Automations 的权限。
默认情况下，成员不会获得代码扫描权限。所有者拥有全部权限，管理员可通过自定义角色 向成员授予权限。
将 Security Swarm 与另一款扫描器进行比较 要进行有参考价值的比较，请为两款扫描器设定相同的作用域、威胁模型、严重性判定标准和验证预期。否则，配置差异可能会掩盖其底层能力的差别。
使用 Profile 定义比较标准，使用交互模式确认生成的威胁模型，并使用运行时验证对报告出的发现采用相同的证据标准。
Security Swarm 会结合你的代码仓库上下文调查潜在漏洞，而不是孤立地报告存在风险的模式。Devin 会追踪相关数据流，检查验证和授权控制，并评估该问题是否会带来实际的安全影响。 每条发现项都包含置信度等级和支持性证据。请先查看这些证据再采取行动，尤其是在某条发现项尚未经过运行时验证时。
请检查受影响的代码、入口点、数据流、现有缓解措施、所述影响、置信度和可利用性。启用运行时验证后，还应查看验证结果及其支持性工件。 如果证据忽略了某项控制，或声称了缺乏依据的影响，请使用反馈 补充缺失的上下文，以改进后续扫描。
运行时验证会尝试通过在隔离环境中构建并运行应用程序来复现一条发现项。验证成功会提供更强的可利用性证据，而验证失败则可以识别出需要进一步审查的假设或环境限制。 运行时验证是可选的，并且需要提供足够的验证指引 ，以便 Devin 能够安全地构建、运行、植入数据并完成应用程序认证。
Security Swarm 如何发现跨多个文件的漏洞？
Security Swarm 会并行分析代码仓库的不同部分，并将结果整合为覆盖整个代码仓库的全局视图。这样它就能识别组件之间的关系，例如某个端点暴露了利用另一个端点所需的标识符。 任何由此产生的链式发现项仍应指出相关代码路径，并说明各项条件如何共同构成实际影响。
Security Swarm 使用以 Agent 为核心的分析，因此不同次扫描产生的发现项或表述可能并不完全一致。聚焦的作用域、明确的威胁模型、清晰的严重性标准以及具体的调查指引，都有助于保持覆盖范围一致。 请将这些要求记录在可复用的扫描 Profile 中，使用交互模式 审查建议的威胁模型，并在结果遗漏重要上下文时提供反馈。
任何安全扫描器都无法保证完全覆盖。结果取决于所选作用域、Profile 指引、可用的代码仓库上下文，以及发现项是否能在已配置的环境中得到验证。 请针对不同的攻击者模型或威胁类别分别运行扫描，随着应用程序变化及时更新 Profile，并将 Security Swarm 与你现有的安全审查和测试实践结合使用。
