# 烛龙（Zhulong）：面向本地智能体的模块化安全代码审计工作流

> 烛龙是一个面向本地 AI 智能体的模块化安全代码审计工作流，采用"Docker 先验证再确认"的核心原则，通过轻量级架构实现从代码导入到证据打包的完整审计流程。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-06T03:47:13.000Z
- 最近活动: 2026-06-06T03:51:42.194Z
- 热度: 154.9
- 关键词: 安全审计, 代码审计, Docker, 漏洞验证, 智能体, 安全工具, 开源安全, 静态分析, 漏洞复现, 安全工作流
- 页面链接: https://www.zingnex.cn/forum/thread/zhulong
- Canonical: https://www.zingnex.cn/forum/thread/zhulong
- Markdown 来源: ingested_event

---

## 原作者与来源

- 原作者/维护者：Torchbearer127
- 来源平台：github
- 原始标题：zhulong
- 原始链接：https://github.com/Torchbearer127/zhulong
- 来源发布时间/更新时间：2026-06-06T03:47:13Z

# 烛龙（Zhulong）：面向本地智能体的模块化安全代码审计工作流\n\n## 原作者与来源\n\n- **原作者/维护者：** Torchbearer127\n- **来源平台：** GitHub\n- **原始标题：** zhulong\n- **原始链接：** https://github.com/Torchbearer127/zhulong\n- **发布时间：** 2026年6月6日\n\n---\n\n## 项目背景与核心理念\n\n在安全代码审计领域，传统工具往往面临一个两难困境：轻量级扫描器产生大量误报，而重量级审计平台又需要复杂的部署和昂贵的维护成本。更重要的是，许多安全漏洞的发现停留在源码层面的推测，缺乏可复现的运行时证据。\n\n烛龙（Zhulong，取名自中国古代神话中"烛九阴，是谓烛龙"的神兽，寓意照亮幽暗之处）正是为解决这些问题而设计的。它不是一个单纯的扫描工具，也不是一个臃肿的审计平台，而是一个面向本地 AI 智能体的模块化工作流，强调"Docker 先验证再确认"的核心原则。\n\n### 核心原则\n\n> **只有经过 Docker 或 Docker Compose 复现验证的漏洞，才会被标记为已确认。其他所有发现（扫描器告警、依赖提示、静态分析结果、LLM 推测）在获得足够证据前都保持隔离状态。**\n\n这一原则从根本上解决了安全审计中的误报问题，确保每一个报告给审查者的漏洞都有确凿的运行时证据支撑。\n\n---\n\n## 烛龙解决的四大痛点\n\n### 1. 高误报负担\n\n传统扫描器或 LLM 生成的未经验证的声明会消耗大量审查者时间。烛龙通过机器可读的决策日志（`audit-disposition.json`）跟踪每个潜在问题，确保未验证的线索不会悄然变成已确认的报告。\n\n### 2. 复现鸿沟\n\n源码层面的怀疑并不等同于运行时影响证明。烛龙要求智能体在报告漏洞前，先在 Docker 或 Docker Compose 环境中复现该问题，建立从怀疑到证据的完整链条。\n\n### 3. 工件碎片化\n\n证据、脚本、报告和分类笔记往往分散各处。烛龙将每个已确认漏洞打包为包含报告、复现说明、附件索引、证据 JSON、日志、截图和根运行脚本的完整证据包。\n\n### 4. 交接脆弱性\n\n长对话上下文难以被其他智能体或人类审查者接手。烛龙通过工作区文件、交接摘要和确定性输出，确保审计过程对 AI 和人类都清晰可读。\n\n---\n\n## 系统架构与工作流\n\n### 整体架构\n\n烛龙采用本地模块化工作流设计，核心路径由智能体运行时、本地脚本、自动化检查、参考文档、Docker 安全检查和工作区输出共同驱动。\n\n```\n导入项目 → 映射攻击面 → 生成候选 → Docker 复现 → 打包证据 → 交接结果\n```\n\n### 模块化设计\n\n烛龙的架构设计体现了轻量化和模块化的理念：\n\n- **无强制后端**：不需要复杂的服务器架构\n- **无仪表板**：不依赖 Web 界面\n- **无数据库**：使用文件系统存储\n- **无向量存储**：不依赖 RAG 平台\n- **无重型依赖**：通过本地智能体模块和脚本运行\n\n### 审计工作流阶段\n\n#### 阶段一：项目导入\n\n智能体接收目标仓库地址，执行初始分析，理解项目结构、技术栈和潜在风险点。\n\n#### 阶段二：攻击面映射\n\n系统性地识别代码中的潜在入口点，包括：\n- HTTP 端点和 API 路由\n- 数据库查询和 ORM 使用\n- 文件系统操作\n- 外部命令执行\n- 反序列化点\n- 认证和授权逻辑\n\n#### 阶段三：生成候选\n\n基于攻击面映射，生成潜在漏洞候选列表。这些候选包括：\n- 扫描器告警（待验证）\n- 依赖漏洞提示（待验证）\n- 静态分析发现（待验证）\n- LLM 推测（待验证）\n\n所有候选都记录在 `audit-disposition.json` 中，明确标记为未验证状态。\n\n#### 阶段四：Docker 复现\n\n这是烛龙工作流的核心环节。对于每个可以运行时检查的候选漏洞，智能体需要：\n\n1. 构建 Docker 环境（使用项目提供的 Dockerfile 或自行创建）\n2. 配置测试场景\n3. 执行漏洞利用尝试\n4. 收集运行时证据（日志、截图、网络流量等）\n5. 记录复现步骤和结果\n\n只有通过 Docker 验证的漏洞才会被提升为"已确认"状态。\n\n#### 阶段五：打包证据\n\n已确认的漏洞被打包为标准化证据包，包含：\n\n- **漏洞报告**：详细描述漏洞类型、影响、复现步骤\n- **复现说明**：精确的 Docker 复现指南\n- **附件索引**：所有相关文件的清单\n- **证据 JSON**：机器可读的证据数据\n- **日志文件**：运行时日志和输出\n- **截图**：可视化证据\n- **根运行脚本**：一键复现脚本\n\n#### 阶段六：交接结果\n\n最终输出包括：\n- 完整的工作区文件结构\n- 机器可读的决策日志\n- 人类可读的审计报告\n- 确定性输出，便于其他智能体或审查者接手\n\n---\n\n## Docker 安全与清理机制\n\n烛龙在 Docker 使用方面采取了严格的安全措施：\n\n### 状态记录\n\n审计开始时记录 Docker 的初始状态，包括容器、镜像、网络和卷的清单。\n\n### 残留检测\n\n审计结束时检查新创建的容器、镜像、网络和卷，确保审计过程不会留下未清理的资源。\n\n### 拒绝广泛清理\n\n烛龙拒绝执行可能删除用户无关资源的广泛清理操作，只清理审计过程中明确创建的资源。\n\n---\n\n## 平台支持与快速开始\n\n### 支持平台\n\n| 平台 | 推荐路径 | 说明 |\n|------|----------|------|\n| **macOS** | ✅ 支持并已发布测试 | 使用 Docker Desktop，Python 3.11+，Bash |\n| **Linux** | ✅ 支持的目标路径 | 使用 Docker Engine，Docker Compose，Python 3.11+ |\n| **Windows** | ⚠️ 使用 WSL2 | 在 WSL2 内运行，审计工作区放在 WSL 文件系统 |\n\n### 安装与同步\n\n```bash\n# 1. 测试并同步\npython3 scripts/selftest_plugin.py\nbash scripts/sync_to_claude_skill.sh\n\n# 2. 验证安装布局\npython3 ~/.claude/skills/zhulong/scripts/selftest_plugin.py\n```\n\n### 使用方式\n\n重启本地智能体会话后，使用简洁的提示词启动审计：\n\n```\n请使用 zhulong skill 对此仓库执行端到端的安全代码审计：\nhttps://github.com/owner/repo\n\n输出语言：zh-CN\n```\n\n---\n\n## 项目结构与组件\n\n```\nzhulong/\n├── .claude-plugin/          # Claude 插件配置\n├── .codex-plugin/           # Codex 插件配置\n├── assets/                  # 品牌资源和图示\n├── docs/                    # 文档（USAGE.md 等）\n├── scripts/                 # 运行时脚本\n│   ├── selftest_plugin.py   # 插件自检\n│   └── sync_to_claude_skill.sh  # Claude 技能同步\n├── skills/zhulong/          # 核心技能实现\n│   ├── scripts/             # 审计阶段脚本\n│   ├── checks/              # 自动化检查\n│   └── docs/                # 参考文档\n├── templates/               # 模板（Claude skill 模板等）\n├── CHANGELOG.md             # 变更日志\n├── CONTRIBUTING.md          # 贡献指南\n├── DISCLAIMER.md          # 免责声明\n└── README.md                # 项目说明\n```\n\n---\n\n## 与传统方案的对比\n\n| 传统审计痛点 | 烛龙解决方案 |\n|--------------|--------------|\n| 嘈杂的扫描器或 LLM 输出 | 机器可读决策日志隔离未验证线索 |\n| 手动证据重建 | 每个确认漏洞附带完整证据包 |\n| 源码声明缺乏信任 | Docker 复现后才标记为确认 |\n| 重型平台昂贵 | 本地智能体模块 + 脚本，无强制后端 |\n| 仅叙述性最终状态 | 自动化检查验证报告文件、证据、决策日志和清理状态 |\n| Docker 残留和环境漂移 | 记录起始状态，检查新资源，拒绝广泛清理 |\n| 智能体工作成为黑盒 | 工作区文件和交接摘要对 AI 和人类都可读 |\n\n---\n\n## 安全声明与责任边界\n\n烛龙明确声明其设计用途和限制：\n\n- **仅用于授权审查**：烛龙仅应用于获得明确授权的目标\n- **禁止非法用途**：不得用于未授权访问、攻击或任何违法活动\n- **用户责任**：使用者对审计活动的合法性和道德性负全责\n- **免责声明**：项目提供方不对滥用行为负责\n\n完整的免责声明见项目 `DISCLAIMER.md` 文件。\n\n---\n\n## 实际应用价值\n\n烛龙特别适合以下场景：\n\n1. **企业内部安全审计**：对内部代码库进行系统化安全评估\n2. **开源项目安全评估**：评估第三方依赖的安全性\n3. **安全研究团队**：建立标准化的漏洞验证流程\n4. **开发团队自检**：在发布前进行自动化安全审查\n5. **安全培训**：作为教学工具展示完整的审计流程\n\n---\n\n## 总结与展望\n\n烛龙代表了安全代码审计工具的一种新思路：不是追求全自动化的"一键扫描"，而是通过结构化工作流和严格的验证机制，在轻量级架构和审计质量之间取得平衡。\n\n其"Docker 先验证再确认"的原则，从根本上解决了安全审计中的误报问题，为 AI 智能体参与安全审计提供了可靠的工作框架。对于希望建立高质量安全审计流程的团队来说，烛龙是一个值得深入研究和采用的开源方案。\n\n项目目前处于发布候选阶段，持续迭代中。社区欢迎贡献，详见项目 `CONTRIBUTING.md` 文件。