目录Taskflow 简介从代码扫描告警到报告的分流 taskflow通用 taskflow 设计信息收集审计 issue决策与报告生成报告校验与 Issue 创建Issue 审查与仓库特定知识分流示例与结果GitHub Actions 告警JavaScript 告警Taskflows 开发经验分享使用数据库存储中间状态将复杂任务拆分为更小的任务尽可能将任务委派给 MCP 服务器使用可复用的 taskflow在多个 taskflow 中统一应用调整在多个 taskflow 中统一配置模型结语免责声明作者Man Yue Mo排版Alan Wang了解我们如何使用新发布的 GitHub Security Lab Taskflow Agent对 GitHub Actions 和 JavaScript 项目中的各类漏洞进行分流与分类处理。安全告警的分流工作往往非常重复因为误报通常源于一些对人工审计员来说很明显、但难以用格式化代码模式表达的特征。而大语言模型LLM在匹配这类传统工具难以处理的模糊模式方面表现出色因此 GitHub Security Lab 一直在尝试使用 LLM 来对安全告警进行分流。为此我们采用了近期发布的 GitHub Security Lab Taskflow Agent AI 框架发现其效果非常显著。 了解更多内容并查看如何启用该 Agent可参考我们之前的博客文章。在本文中我们将介绍这些分流任务流展示实际效果并分享一些实用经验帮助你为漏洞分流或其他安全研究工作流开发属于自己的任务流。通过使用本文中描述的任务流我们在短时间内对大量代码扫描告警进行了分流自 8 月以来发现了许多约 30 个真实世界中的漏洞其中不少已经被修复并公开。在分流过程中LLM 仅被授予了基础的文件获取和搜索能力。除了使用 CodeQL 生成告警之外我们没有使用任何其他静态或动态代码分析工具。虽然本文主要展示了我们如何使用 LLM 任务流来分流 CodeQL 查询结果但这一通用流程的本质是通过 LLM Taskflow 来实现自动化。如果你的工作流程符合以下条件那么它就非常适合采用这种方式你的任务包含大量重复步骤并且每一步都有清晰、明确的目标。其中一些步骤需要在代码中识别逻辑或语义层面的特征这些特征对传统编程方式来说难以准确识别但对人工审计员来说相对容易。尝试用代码识别它们往往会导致大量补丁式的启发规则、糟糕的的正则表达式等。这些正是 LLM 自动化的绝佳应用场景如果你的项目满足上述条件就可以使用 LLM Taskflow 将这些优势场景自动化同时借助 MCP Server 来完成那些更适合传统编程方式处理的任务。seclab-taskflow-agent 和 seclab-taskflows 两个仓库都是开源的任何人都可以基于它们开发 LLM 任务流来完成类似的工作。在本文结尾我们还将分享一些在实践中总结出的开发经验与技巧。GitHub Security Lab Taskflow Agenthttps://github.com/GitHubSecurityLab/seclab-taskflow-agent?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactor之前的博客文章https://github.blog/security/community-powered-security-with-ai-an-open-source-framework-for-security-research/?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactor任务流https://github.com/GitHubSecurityLab/seclab-taskflows/tree/main/src/seclab_taskflows/taskflows/alert_triage_examples?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactor修复并公开http://securitylab.github.com/ai-agents?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactorseclab-taskflow-agenthttps://github.com/GitHubSecurityLab/seclab-taskflow-agent?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactorseclab-taskflowshttps://github.com/GitHubSecurityLab/seclab-taskflows?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactorTaskflow 简介Taskflow 是一种 YAML 文件用于描述我们希望借助 LLM 完成的一系列任务。通过这种方式我们可以为不同任务编写提示词并让任务之间形成依赖关系。seclab-taskflow-agent 框架负责按顺序执行这些任务并将一个任务的结果传递给下一个任务。例如在审计 CodeQL 告警结果时我们首先需要获取代码扫描结果。随后对于每一条结果我们可能会有一系列需要检查的任务。例如我们可能需要检查该告警是否可以被不受信任的攻击者触达以及是否存在认证检查。这些都会成为我们在 taskflow 文件中定义的一组任务。我们使用任务而不是一个大型提示是因为 LLM 的上下文窗口有限而复杂的多步骤任务往往无法被正确完成。一些步骤经常会被遗漏因此使用 taskflow 来组织任务可以避免这些问题。即使对于拥有更大上下文窗口的 LLM我们也发现 taskflow 依然非常有用它为我们提供了一种控制和调试任务的方式同时也有助于完成规模更大、更复杂的任务。seclab-taskflow-agent 还可以异步执行类似批量 “for loop” 的任务。在审计告警时我们通常希望对每条告警应用相同的提示和任务但告警细节各不相同。seclab-taskflow-agent 允许我们创建模板化提示在执行任务时遍历告警列表并为每条告警替换其特定细节。从代码扫描告警到报告的分流 taskflowGitHub Security Lab 会定期针对一组选定的开源仓库运行一组 CodeQL 查询。对这些告警进行分流的过程通常非常重复并且对于某些告警误报的原因往往高度相似也很容易被识别出来。例如在对 GitHub Actions 的告警进行分流时误报往往来自于已经设置的某些检查这些检查确保只有仓库维护者才能触发存在漏洞的工作流或者该存在漏洞的工作流在配置中已被禁用。这些访问控制检查形式多样且不存在易于匹配的代码模式因此像 CodeQL 这样的静态分析工具很难检测到它们。然而具备代码语义基础知识的人类审计员通常可以很容易地识别这些检查因此我们期望 LLM 也能够识别这些访问控制检查并消除误报。在数个月的时间里我们主要使用 Claude Sonnet 3.5针对少量 CodeQL 规则测试了我们的 taskflow。我们识别出了多个真实且可被利用的漏洞。这些 taskflow 并不会执行“端到端”的分析而是生成一份包含所有细节和结论的漏洞报告以便我们能够快速验证结果。我们并未指示 LLM 通过构造利用代码来验证结果也没有为其提供任何运行时环境来测试其结论。然而即便缺少自动化验证步骤结果依然保持了较高的准确性我们也能够快速移除 CodeQL 查询中的误报。这些规则的选择基于我们自身在分流此类告警方面的经验以及这些任务是否能够被表述为清晰、明确、适合 LLM 理解的指令。通用 taskflow 设计Taskflow 通常由多个任务组成这些任务被划分为几个不同阶段。在第一阶段任务会收集与告警相关的各类信息。随后这些信息会被传递到审计阶段在该阶段中LLM 会基于我们以往分流告警的经验查找常见的误报原因。在审计阶段之后会使用收集到的信息生成一份漏洞报告。在实际的 taskflow 中信息收集阶段和审计阶段有时会合并为一个任务有时则会拆分为多个任务这取决于任务的复杂程度。为了确保生成的报告包含足够的信息供人工审计员做出判断我们增加了一个额外步骤用于检查报告是否具备正确的格式并包含正确的信息。之后会创建一个 GitHub Issue等待进一步审核。创建 GitHub Issue 不仅便于我们审查结果也为后续扩展分析提供了一种方式。在审查和检查这些 Issue 之后我们经常会发现一些在审计阶段遗漏的误报原因。此外如果 agent 判断某条告警是有效的但人工审查者不同意并发现其因某个此前 agent 未知的原因而实际上是误报人工审查者可以将该原因记录为告警驳回原因或 Issue 评论。当 agent 未来分析类似案例时它将能够感知这些存储在 Issue 和告警驳回原因中的历史分析将新的信息纳入其知识基础中从而更有效地检测误报。告警驳回https://docs.github.com/en/code-security/code-scanning/managing-code-scanning-alerts/resolving-code-scanning-alerts?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#dismissing-alerts/?wt.mc_id3reg_webpage_reactor信息收集在这一阶段我们会指示 LLM示例见下方分流示例章节收集与告警相关的信息这些信息会结合威胁模型以及人类对该类告警的一般认知。例如对于 GitHub Actions 告警它会查看 GitHub 工作流文件中设置了哪些权限、哪些事件会触发该工作流、该工作流是否被禁用等。这些通常是相互独立的任务并遵循简单、明确的指令以确保所收集信息的一致性。例如检查 GitHub 工作流是否被禁用会通过 MCP server 调用 GitHub API 来完成。为了确保所收集信息的准确性并减少幻觉我们要求 LLM 提供精确的源代码引用包括文件名和行号以支持其收集到的信息你应当包含不受信任代码被调用的位置行号以及在注释中包含被调用的不受信任代码或包管理器。每个任务都会将其收集到的信息存储在审计笔记中这些笔记类似于对某条告警的持续记录。任务完成后这些笔记会被序列化并存储到数据库中后续任务完成时可以继续在其基础上追加内容。通常每个信息收集任务都是相互独立的不需要读取其他任务的笔记。这有助于每个任务专注于自身的范围而不被此前收集的信息干扰。最终的结果是一个与告警关联的“信息集合”以笔记的形式传递给审计任务。审计 issue在这一阶段LLM 会遍历已收集的信息并执行一系列特定检查以剔除最终被判定为误报的告警结果。例如在分流 GitHub Actions 告警时我们可能已经收集了触发存在漏洞工作流的事件信息。在审计阶段我们会检查这些事件是否可以被攻击者触发或者是否在特权上下文中运行。经过该阶段后许多对人工审计员来说显而易见的误报都会被移除。决策与报告生成对于通过审计阶段的告警下一步是使用收集到的信息生成漏洞报告并说明在审计阶段作出决策的理由。同样地在提示词中我们会非常精确地规定报告的格式以及所需包含的信息。特别是我们希望报告简明扼要同时包含足够的信息以便我们验证结果例如精确的代码引用和代码块。生成的报告会使用前几个阶段笔记中收集的信息仅在需要时从源代码中获取必要的代码片段。该阶段不会执行进一步的分析。任务的高度严格和精确有助于进一步减少幻觉。报告校验与 Issue 创建报告生成后我们会指示 LLM 检查报告以确保其包含所有相关信息并且信息之间保持一致检查报告是否包含所有必要信息-该条件仅在包含告警的工作流是可复用 action 且不存在高权限触发器时适用。你应使用 gh_actions 工具箱中的相关工具进行检查。如果不满足该条件则忽略此检查。在这种情况下检查报告是否包含列出受影响 action 使用者的章节。如果不存在受影响的 action 使用者且不存在高权限触发器则将该告警标记为无效并使用 alert_id 和 repo 删除键为 {{ RESULT_key }} 的 memcache 条目。缺失或不一致的信息通常意味着幻觉或其他误报原因例如无法追踪攻击者可控的输入。在这些情况下我们会驳回该报告。如果报告包含所有信息且保持一致性我们便会创建一个 GitHub Issue 来跟踪该告警。Issue 审查与仓库特定知识在上一步中创建的 GitHub Issue 包含验证该问题所需的全部信息包括代码片段以及文件和行号引用。这相当于一个“检查点”和信息摘要使我们能够方便地继续扩展分析。事实上在创建 Issue 之后我们经常会发现某些仓库特定的权限检查或清洗逻辑会使该问题成为误报。我们可以通过创建新的 taskflow在提示中加入仓库特定知识对这些 Issue 进行复审。一种我们尝试过的方法是收集仓库中的告警驳回原因并指示 LLM 在审查 GitHub Issue 时考虑这些驳回原因。这使我们能够移除那些因仓库特定原因导致的误报。在这种情况下LLM 在考虑了记录于告警驳回原因中的自定义check-run权限检查之后能够将该告警识别为误报。收集仓库中的告警驳回原因https://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/collect_dismiss_reasons.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#L16/?wt.mc_id3reg_webpage_reactor分流示例与结果在本节中我们将给出一些 taskflow 在实际中的示例特别是用于分流 GitHub Actions 和 JavaScript 告警的 taskflow。GitHub Actions 告警我们分流的具体 Actions 告警包括在特权上下文中检出不受信任代码以及代码注入。这些查询的分流过程具有高度相似性。例如它们都需要检查工作流触发事件、存在漏洞的工作流权限以及追踪工作流调用者。主要差异在于对漏洞细节的本地分析对于代码注入需要分析注入代码是否被清洗、表达式如何求值、输入是否真正可控例如pull request ID 通常不太可能导致代码注入问题对于不受信任检出则需要判断在检出之后是否存在有效的代码执行点。由于这些 taskflow 中有大量相同的元素我们以代码注入的分流 taskflow 作为示例。需要注意的是由于这些 taskflow 具有很强的共性我们大量使用了seclab-taskflow-agent中的可复用特性例如可复用的提示和任务。在针对这些规则手动分流 GitHub Actions 告警时我们通常会因为以下原因遇到误报存在漏洞的工作流未在特权上下文中运行。这由触发该工作流的事件决定。例如由pull_request_target触发的工作流运行在特权上下文中而由pull_request事件触发的工作流则不是。通常只需查看工作流文件即可判断这一点。存在漏洞的工作流在仓库中被显式禁用。这一点可以通过查看仓库中的工作流设置轻松确认。存在漏洞的工作流显式限制了权限且未使用任何 secrets在这种情况下可获取的权限非常有限。漏洞特定问题例如在代码注入场景中用户输入无效或清洗器缺失在不受信任检出场景中不存在有效的代码执行点。存在漏洞的工作流是可复用工作流但无法从任何在特权上下文中运行的工作流中被触达。在很多情况下分流这些告警需要进行大量类似上述所列的简单但繁琐的检查而只要满足其中任意一个条件就可以很快将某条告警判定为误报。因此我们基于这些标准来建模我们的分流 taskflow。因此在信息收集阶段和审计阶段我们的 action 分流 taskflow 由以下任务组成工作流触发分析该阶段同时执行信息收集和审计。它首先收集触发存在漏洞工作流的事件以及该工作流中使用的权限和 secrets同时检查该工作流是否在仓库中被禁用。所有信息均仅限于该存在漏洞的工作流本身。这些信息会被存储在持续更新的笔记中随后序列化为数据库条目。由于该任务较为简单且仅涉及对存在漏洞工作流的检查因此还会基于工作流触发条件执行初步审计以移除一些明显的误报。代码注入点分析这是另一个仅分析存在漏洞工作流的任务将信息收集与审计合并为一个任务。该任务会收集代码注入点的位置以及被注入的用户输入信息并执行本地审计以检查用户输入是否构成有效的注入风险以及是否存在清洗器。工作流用户分析该任务执行一次简单的调用者分析用于查找存在漏洞的工作流的调用者。由于该步骤可能需要检索并分析大量文件因此被拆分为两个主要任务分别执行信息收集和审计。在信息收集任务中会获取存在漏洞的工作流的调用者并将其触发事件、权限以及 secrets 的使用情况记录在笔记中。随后在审计任务中使用这些信息来判断该存在漏洞的工作流是否可以被攻击者触达。这些任务都会依次应用于告警并在每个步骤中根据任务中定义的标准过滤掉误报。在完成信息收集和审计阶段后我们的笔记通常会包含如下信息触发存在漏洞工作流的事件、涉及的权限和 secrets以及如果是可复用工作流使用该工作流的其他工作流及其触发事件、权限和 secrets。这些信息将构成漏洞报告的基础。作为一项合理性检查为确保当前收集的信息完整且一致在创建报告之前会使用 review_report 任务来检查是否存在缺失或不一致的信息。随后使用 create_report 任务生成漏洞报告该报告将作为 GitHub Issue 的基础。在创建 Issue 之前我们会再次确认报告包含所需的全部信息并符合我们要求的格式。缺失信息或不一致通常意味着某些步骤失败或出现幻觉因此这些情况会被拒绝。下图展示了 triage_actions_code_injection taskflow 的主要组成部分随后我们使用 create_issue_actions taskflow 创建 GitHub Issue。如前所述创建的 GitHub Issue 包含足够的信息和代码引用能够快速验证漏洞同时也作为当前分析的总结使我们可以基于该 Issue 继续深入分析。下方展示了一个由 LLM 创建的 Issue 示例。特别地我们可以将 GitHub Issue 和告警驳回原因作为引入仓库特定安全措施并进一步分析的手段。为此我们使用 review_actions_injection_issues taskflow首先从仓库中收集告警驳回原因然后将这些驳回原因与 GitHub Issue 中描述的告警进行比对。在这一过程中我们直接以 Issue 作为起点并指示 LLM 审计该 Issue检查是否有任何告警驳回原因适用于当前问题。由于 Issue 已包含该告警的所有相关信息和代码引用LLM 能够结合 Issue 和告警驳回原因进一步推进分析并发现更多误报。下方展示了一个基于驳回原因被否决的告警示例。下图展示了 Issue 创建与审查 taskflow 的主要组成部分在特权上下文中检出不受信任代码https://codeql.github.com/codeql-query-help/actions/actions-untrusted-checkout-critical/?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactor代码注入https://codeql.github.com/codeql-query-help/actions/actions-code-injection-critical/?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk提示https://github.com/GitHubSecurityLab/seclab-taskflow-agent/blob/v0.0.9/doc/GRAMMAR.md?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#reusable-tasks/?wt.mc_id3reg_webpage_reactor任务https://github.com/GitHubSecurityLab/seclab-taskflow-agent/blob/v0.0.9/doc/GRAMMAR.md?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#reusable-tasks/?wt.mc_id3reg_webpage_reactor工作流触发分析https://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_actions_code_injection.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#L40/?wt.mc_id3reg_webpage_reactor存储在持续更新的笔记中https://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/trigger_analysis.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#L49/?wt.mc_id3reg_webpage_reactor初步审计https://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/trigger_analysis.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#L35-L39/?wt.mc_id3reg_webpage_reactor用户输入是否构成有效的注入风险https://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_actions_code_injection.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#L105/?wt.mc_id3reg_webpage_reactor清洗器https://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_actions_code_injection.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#L122/?wt.mc_id3reg_webpage_reactor信息收集任务https://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/actions_common/track_workflow_users.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactorreview_reporthttps://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_actions_code_injection.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#L257/?wt.mc_id3reg_webpage_reactorcreate_reporthttps://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_actions_code_injection.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#L277/?wt.mc_id3reg_webpage_reactor再次确认https://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/triage_actions_code_injection.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#L310/?wt.mc_id3reg_webpage_reactorcreate_issue_actionshttps://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/create_issues_actions.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactorreview_actions_injection_issueshttps://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/review_actions_injection_issues.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactor收集告警驳回原因https://github.com/GitHubSecurityLab/seclab-taskflows/blob/eadd066316e3d8a3933158de0bbe302fc8e4a9b5/src/seclab_taskflows/taskflows/alert_triage_examples/triage_taskflows/review_actions_injection_issues.yaml?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#L22/?wt.mc_id3reg_webpage_reactorJavaScript 告警与对 GitHub Actions 告警进行分流类似我们也对 JavaScript / TypeScript 语言的代码扫描告警进行了分流但覆盖范围相对较小。在 JavaScript 领域我们主要分流的是客户端跨站脚本的 CodeQL 规则告警js/xss。与 GitHub Actions 告警相比客户端 XSS 告警在来源、汇点以及数据流方面具有更高的多样性。用于分析这些 XSS 漏洞的提示侧重于帮助负责分流的人做出有根据的判断而不是替他们直接做决定。具体做法是突出显示那些看起来可能使告警可被攻击者利用的因素以及更重要的——哪些因素很可能阻止该潜在问题被利用。除此之外任务流的整体结构与 GitHub Actions 告警章节中描述的方案基本一致。在手动分流 XSS 告警时我们经常会因为以下原因识别出误报使用了自定义或 SAST 工具无法识别的清洗器例如基于正则表达式的处理工具无法验证其有效性。报告的来源在实际中很可能不可达例如需要攻击者直接从 Web 服务器发送消息。不受信任的数据流入了潜在危险的汇点但其输出仅以不可被利用的方式使用。SAST 工具不了解不受信任数据最终使用位置的完整上下文。基于这些误报情况我们对相关任务流中的提示甚至是当前使用的 personality 进行了扩展和调整。如果你在某个项目中遇到特定类型的误报对其进行审计并扩展提示是有意义的这样可以确保这些误报被正确标记同样地如果某些来源或汇点在你的项目中并不被视为漏洞也应在提示中体现。最终在执行triage_js_ts_client_side_xss和create_issues_js_ts这两个任务流之后告警会生成对应的 GitHub Issue例如这是一个值得继续跟进的示例告警最终被确认是真实存在的漏洞可通过使用javascript:URL 进行利用。而对于被任务流 agent 判定为误报的告警其对应的 Issue 会被打上 “FP”false positive的标签例如js/xsshttps://codeql.github.com/codeql-query-help/javascript/js-xss/?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactorTaskflows 开发经验分享在本节中我们将分享在开发这些 taskflow 过程中积累的一些经验以及我们认为在 taskflow 开发中非常有用的实践。希望这些经验能帮助其他人构建属于自己的 taskflow。使用数据库存储中间状态在开发由多个任务组成的 taskflow 时我们有时会在后续阶段的任务中遇到问题。这些问题可能是一些常见的软件问题例如 API 调用失败、MCP 服务器缺陷、与 prompt 相关的问题、token 限制或配额问题等。通过保持任务足够小并将每个任务的结果存储到数据库中我们避免了在发生失败时重复执行耗时较长的任务。当某个 taskflow 中的任务失败时我们只需从失败的任务开始重新运行 taskflow并复用数据库中已保存的前序任务结果。这不仅在任务失败时为我们节省了时间也帮助我们隔离各个任务的影响并可以以前一个任务生成的数据库结果为起点对单个任务进行调优。将复杂任务拆分为更小的任务在开发告警分流相关的 taskflow 时我们当时使用的模型并不擅长处理大上下文和复杂任务。当尝试在同一个上下文中执行多个复杂任务时经常会遇到诸如任务被跳过、指令未被正确执行等问题。为了解决这一问题我们将任务拆分为更小、相互独立的任务每个任务都从一个全新的上下文开始。这种方式有效降低了上下文窗口的大小缓解了我们遇到的诸多问题。一个典型的例子是使用模板化的 repeat_prompt 任务它会遍历一组任务列表并为每个任务启动一个新的上下文。通过这种方式相比在同一个 prompt 中处理整个列表我们能够确保列表中的每一个任务都被执行同时将每个任务的上下文控制在最小范围内。这种设计的一个额外好处是我们可以以更细粒度对 taskflow 进行调试和优化。通过将任务拆分得足够小并将每个任务的结果存储到数据库中我们可以轻松地抽取 taskflow 的某一部分并单独运行。repeat_prompthttps://github.com/GitHubSecurityLab/seclab-taskflow-agent/blob/main/doc/GRAMMAR.md?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#running-templated-tasks-in-a-loop/?wt.mc_id3reg_webpage_reactor尽可能将任务委派给 MCP 服务器在最初进行信息检查和收集例如从源码中获取 workflow 触发条件时我们直接在 prompt 中加入指令认为 LLM 能够自行从源码中提取这些信息。虽然这种方式在大多数情况下可行但由于 LLM 的非确定性特性我们也观察到了一些不一致的结果。例如LLM 有时只记录了触发 workflow 的部分事件或者在判断某个触发条件是否以特权上下文运行 workflow 时得出不一致的结论。鉴于这些信息和检查都可以通过程序方式轻松完成我们最终在 MCP 服务器中实现了相应的工具用于收集信息并执行这些检查从而获得更加一致、可靠的结果。通过将那些可以轻松程序化完成的任务迁移到 MCP 服务器工具中而将更复杂的逻辑推理任务例如查找权限检查留给 LLM我们既发挥了 LLM 的能力又保证了结果的一致性。使用可复用的 taskflow在多个 taskflow 中统一应用调整在开发告警分流 taskflow 的过程中我们意识到许多任务可以在不同的 taskflow 之间共享。为了确保在一个 taskflow 中进行的调整可以同步应用到其他 taskflow并减少大量的复制粘贴工作我们需要一种方式对 taskflow 进行重构提取可复用的组件。为此我们引入了可复用任务和可复用 prompt 等功能。借助这些特性我们能够在不同的 taskflow 之间复用任务并一致性地应用修改。可复用任务https://github.com/GitHubSecurityLab/seclab-taskflow-agent/blob/v0.0.9/doc/GRAMMAR.md?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#reusable-tasks/?wt.mc_id3reg_webpage_reactor可复用 prompthttps://github.com/GitHubSecurityLab/seclab-taskflow-agent/blob/v0.0.9/README.md?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#prompts/?wt.mc_id3reg_webpage_reactor在多个 taskflow 中统一配置模型随着 LLM 的持续演进和新版本的频繁发布我们很快意识到需要一种方式在多个 taskflow 中统一更新模型版本。因此我们增加了模型配置功能使我们能够跨 taskflow 切换和更新模型。这在需要升级模型版本或希望使用不同模型重新运行 taskflow 进行实验时尤为有用。模型配置功能https://github.com/GitHubSecurityLab/seclab-taskflow-agent/blob/main/README.md?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk#model-configs/?wt.mc_id3reg_webpage_reactor结语在本文中我们展示了如何为seclab-taskflow-agent创建 taskflow以分流代码扫描告警。通过将分流过程拆解为精确、具体的任务我们能够利用 LLM 自动化大量重复性工作。通过在提示中设定清晰、明确的标准并要求 LLM 提供包含代码引用的精确答案LLM 能够按指示完成任务同时将幻觉控制在最低水平。这使我们能够在无需动态验证告警的情况下利用 LLM 的能力进行告警分流并大幅减少误报。最终我们在运行这些分流 taskflow 后从 CodeQL 告警中发现了约 30 个真实世界漏洞。文中讨论的 taskflow 已发布在我们的仓库中我们也非常期待看到你基于它们构建的内容近期我们还在 AI 辅助代码审计和漏洞挖掘领域进行了更多实验敬请期待后续内容。 获取 GitHub Security Lab Taskflow Agent 的配置指南我们的仓库https://github.com/GitHubSecurityLab/seclab-taskflows?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactor获取 GitHub Security Lab Taskflow Agent 的配置指南https://github.blog/security/community-powered-security-with-ai-an-open-source-framework-for-security-research/?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactor免责声明当我们使用这些 taskflow 来报告漏洞时研究人员都会在提交报告之前对所有生成的输出进行仔细人工审查。我们强烈建议你也采取同样的做法。请注意运行这些 taskflow 可能会触发大量工具调用从而很容易消耗掉大量配额。这些 taskflow 可能会创建 GitHub Issues。在对他人的仓库运行之前请务必征得仓库所有者的同意并保持必要的克制与尊重。配额https://docs.github.com/en/billing/concepts/product-billing/github-models?utm_campaigncli-sdk-jan-2026utm_sourceblog-announcement-cli-sdk/?wt.mc_id3reg_webpage_reactor引入地址