AI 资源库 · 已整理 6 项
查看与安全测试编排相关的 AI 资讯、工具、Skill、工作流和开源项目。
GitHubSecurityLab/seclab-taskflows-fuzzing · An LLM-driven fuzzing pipeline powered by the GitHub Security Lab Taskflow Agent
该项目是 GitHub Security Lab Taskflow Agent 的模糊测试任务流，面向原生 C/C++ 项目提供 LLM 驱动的自主模糊测试流水线。它结合 AFL++ 执行、clang+lcov 覆盖率采集以及 LLM Agent，自动完成目标识别、构建系统分析、harness 编写与构建、覆盖率反馈迭代、崩溃去重与分类，并生成含可利用性判断和修复建议的可读漏洞报告，同时提供实时 HTML 仪表盘。
很多团队都有一份长期没人处理、也不指望处理完的漏洞清单，过去把它当成“技术债”：先按严重程度挑一部分修，剩下的默认没人会碰。但现在三个前提变了：代码产出量远超清理速度（产品数据显示大约每修1个漏洞就新增6个）、越来越多代码由AI代理生成、无法追问作者意图、攻击方也用上自动化，能低成本扫描并组合利用那些低危小问题。文中举例说，几个单独看都不严重的问题串起来，可能形成远程代码执行的攻击路径。所以清单不只是排队问题，而是一份攻击者能拼装的零件表；光把排序做得更准，也只能让队列更有序，并不会让它变短。
提供的材料未提及具体可用工具。
agent-sh/audit-project · Multi-agent iterative code review until zero issues remain
audit-project 是一个多智能体迭代代码审查工具，可运行最多 10 个专用审查 agent（4 个常驻加最多 6 个按项目特征条件激活），发现代码问题后自动按严重程度修复，并对修改过的文件重新审查，循环往复直到代码库干净或用户中止。每个发现包含 file:line 位置、严重级别、代码片段、修复建议和改动量估计；破坏测试或构建的修复会被回滚。支持全项目审查、指定路径、仅安全域、单次快速扫描、最近 5 次提交范围、生成 TECHNICAL_DEBT.md 以及从保存队列恢复，并可在已有 repo-intel 数据时用测试缺口信号优先审查高频变动且无配套测试的文件。
WHOOP 是一家做健康手环的公司，每天要处理成千上万条漏洞告警，靠全员连续多天手工分类才能不漏掉问题，既费人力又容易被噪音淹没。这次他们用 Datadog 的 Bits AI 和 Workflow Automation 搭了一套自动化的漏洞响应流程：先结合运行时数据判断哪些漏洞真的在被利用，再把工单自动分配给对应微服务的负责人，让开发者能自己处理一部分。原文尚在预告 2026 年 10 月 7 日的线上分享，具体实现细节和效果数据没有给出；不过它的思路是自动化处理加人工最终确认，对同样被大量漏洞告警困扰的安全和运维团队有参考意义。
传统代码扫描器只能靠规则匹配找已知模式，而大语言模型能顺着程序逻辑追踪攻击者可控的输入是否真的能到达危险位置，因此能发现规则没覆盖的漏洞。但模型本身不稳定：同一份没变的代码扫两次，结果可能不同，耗时和花费也难预测，没法直接用在每次提交都跑的自动化扫描上。Harness 的 Security Test Orchestration（STO）在模型外面加了一层编排：控制扫描什么时候触发、只扫改动范围、每步怎么约束、结果怎么统一，变成可比较、可信任的扫描。用 GPT-5.5 对三个故意留漏洞的测试应用跑基准，增量扫描比全量扫描最高省约 83% 费用、快约 72%，且没有漏掉全量扫描找到的问题；连续跑 10 次时增量方案比全量便宜约 75%。目前该能力基于 OpenAI Codex Security，配合 Mythos 代理插件，以安全扫描技能方式调用，具体开放范围和价格原文未说明。
Harness 发布了一篇博客，解释漏洞“修复”和“缓解”的区别：修复是打补丁或升级，彻底消除漏洞；缓解则是隔离、封堵或关闭功能，让漏洞难以被利用，但漏洞本身还在。博客说，当补丁还没有、修复需要停机窗口，或攻击路径本来就不通时，可以先选缓解；但每个缓解措施都要有负责人和到期日，否则临时措施会变成永久隐患。对开发团队来说，这能帮助决定什么时候必须真正修、什么时候可以先顶住，而不是把风险一直存着。文中还提到 Harness 的安全测试编排可对接 40 多个合作扫描器，并引用调查称：最频繁使用 AI 编程工具的人群中，50% 表示采用后漏洞和安全事件变多了。