企业官网建设流程全解析

为什么 Shannon 不能在生产环境运行？渗透测试的数据变更风险与安全环境选择

【免费下载链接】shannonShannon is an AI pentester for web applications and APIs. It analyzes your source code, identifies attack vectors, and executes real exploits to prove vulnerabilities before they reach production.项目地址: https://gitcode.com/GitHub_Trending/shan/shannon

如果你的 Web 应用或 API 准备接一次自动化渗透测试，你需要先弄清一件事：Shannon 这类"以利用证明漏洞"（proof-by-exploitation）的 AI 渗透工具，为什么文档明确要求不要指向生产系统，以及应该把它放到哪个环境里跑。Shannon 会分析源码、规划攻击路径，然后对正在运行的应用真实执行漏洞利用来生成可复现的 PoC——这意味着它会向目标发起真实的请求、创建用户、提交表单。本文基于 Shannon 仓库内的 Safety and Limitations、Platforms and Networking、Configuration 和 Source Build and CLI Commands，说明风险来源、文档推荐的安全环境，以及在这些环境里完成一次扫描并核对结果的完整操作路径。

为什么 Shannon 不能指向生产系统

safety.md 中有一节标题就是 "Do Not Run on Production"，核心表述是：

Shannon is not a passive scanner. Exploitation agents actively execute attacks to confirm vulnerabilities. This can mutate application state and data.

也就是说，Shannon 不是只发探测请求、不改写任何东西的被动扫描器。它的 exploitation 阶段会对目标执行真实攻击来确认漏洞可利用，而文档列出了这类运行可能带来的状态与数据变更（mutative effects）：

• Creating new users（创建新用户）
• Modifying or deleting data（修改或删除数据）
• Compromising test accounts（攻破测试账号）
• Triggering unintended side effects from injection attacks（注入攻击触发非预期副作用）
• Generating unexpected outbound traffic（产生意外的出站流量）
• Writing exploit artifacts to reports or deliverables（把利用工件写进报告或交付物，这类文件会落在本地工作区中）

README.md 的 Safety 部分给出了同一结论的复述：exploitation agents 可以创建用户、提交表单、变更应用状态、触发出站请求，因此要求"Use sandboxed, staging, or local development environments with disposable data"。此外文档还有一条硬性前提：运行前必须持有目标系统所有者的明确书面授权（explicit written authorization），未经授权扫描不属于你的系统是违法的。

所以"不能在生产环境运行"不是性能或兼容性问题，而是工具的工作方式决定的：它为了拿到可利用性证明，必然对目标做有写入行为的操作。

文档推荐哪些环境，隔离程度如何

结合 safety.md 和 platforms.md，文档给出的环境选择是：

1. 沙箱 / staging / 本地开发环境：Use sandboxed, staging, or local development environments where data integrity is not a concern.即选一个数据损坏不影响业务的环境。
2. 一次性虚拟机：For maximum isolation, run Shannon inside a disposable virtual machine.需要更强隔离时，把整个 Shannon 运行放进可丢弃的 VM。

两点与隔离相关的事实可以帮助你判断风险边界：

• 每次扫描都运行在一个临时的 Docker 容器里，配有独立 workspace；
• 目标源码仓库在 worker 容器内以只读方式挂载（The target repository is mounted read-only inside the worker container.，见 README.md 和 development.md），所以 Shannon 不会改动你的源码目录，变更风险集中在被扫描的应用和它的数据上，而不是一份生产数据库。

运行前的前置条件（来自 README.md 的 Quick Start）：

• Docker：worker 容器必需；
• Node.js 18+：npx工作流需要；
• AI 提供商凭据：Anthropic、OpenAI、xAI 或 AWS Bedrock，官方推荐 Claude 模型（Shannon 官方仅支持 Claude 模型，其他模型可能不完整或不稳定）；
• 提供商网络安全防护已开通：Anthropic 和 OpenAI 会对网络安全类工作负载做实时防护，可能在扫描中途拦截，首次运行前需按 AI Providers 的 "Cyber safeguards" 一节完成对应厂商对合法安全测试者的验证流程。

在非生产环境中执行一次扫描

主路径使用npx工作流，两条命令完成配置与启动：

# 交互式向导配置凭据 npx @keygraph/shannon setup # 对目标执行渗透测试 npx @keygraph/shannon start -u https://your-app.com -r /path/to/your-repo

-u是目标应用地址，-r是目标源码仓库路径——请把https://your-app.com和/path/to/your-repo替换为你自己的staging 或本地开发环境地址和仓库路径，这两处是文档保留给读者填值的占位。

如果你测的是本机开发环境里跑着的应用，注意 Docker 容器访问不到宿主机上的localhost，文档（platforms.md "Testing Local Applications" 一节）要求改用host.docker.internal：

npx @keygraph/shannon start -u http://host.docker.internal:3000 -r /path/to/repo

其中3000是文档示例端口，替换为你的本地应用实际监听端口。

可选：用配置文件进一步压缩数据变更面

Shannon 可以不写配置文件直接运行，但如果目标是共享的 staging 环境，configuration.md 提供了几个直接服务于"少动数据"的开关。可以复制仓库内的 example-config.yaml 修改后通过-c传入：

npx @keygraph/shannon start -u https://your-app.com -r /path/to/your-repo -c ./my-app-config.yaml

与数据安全直接相关的配置项（均出自 configuration.md 的示例结构与 config-schema.json）：

# 描述目标环境，例如本地开发环境、凭据仅为本地使用 description: "Local dev environment; .env files contain local-only credentials." # 跳过 exploitation 阶段，只做分析，不对运行中的应用执行利用 exploit: "false" # 自由格式交战规则，渲染进每个 agent 的提示词 rules_of_engagement: | - No password brute-force; cap login attempts at 5 per account. - Throttle to under 5 requests per second per endpoint; back off 60s on any 429. - Use placeholders like [order_id] in deliverables; no real data values. rules: avoid: - description: "AI should avoid testing logout functionality" type: url_path value: "/logout"

说明几条适用条件：

• exploit: "false"表示本次运行不执行漏洞利用阶段，只跑分析。这是文档给出的跳过利用的正式开关，适合只想先拿到分析结论、完全避免对运行应用做写入操作的场景；
• rules_of_engagement是自由文本规则（最多 1000 字符），上面限流、登录尝试上限、交付物用占位符的示例直接来自文档，可防止真实数据值出现在报告里；
• rules.avoid/rules.focus支持url_path、subdomain、domain、method、header、parameter、code_path等类型，用来排除或聚焦特定范围。

需要留意：exploit: "false"时报告按 confidence 评级，min_severity会被忽略并记录警告；min_confidence才生效（见 configuration.md 的 Report Options 表）。

如何确认运行完成并核对结果

运行期间的监控命令（development.md）：

npx @keygraph/shannon status npx @keygraph/shannon logs <workspace>

也可以打开 Temporal Web UI 观察详细进度：

open http://localhost:8233

结果落在 workspace 目录：npx模式在~/.shannon/workspaces/，源码构建模式在./workspaces/，目录名为{hostname}_{sessionId}。运行目录顶层只有最终报告Security-Assessment-Report.md，其余过程文件（deliverables、各 agent 日志、prompts、session.json、workflow.log）都在隐藏目录.shannon/下（development.md、workspaces.md）。

两点来自文档的运行预期：

• 一次完整测试通常约 1 到 1.5 小时，LLM API 成本随模型定价、目标复杂度和并发变化（safety.md）；
• 报告必须经人工复核：Shannon 采用以利用证明的 methodology，但最终报告仍可能包含支持不足或错误的细节，human review 是文档明确要求的环节。

在 Windows 上还有一条环境相关记录：Windows Defender 可能把报告中的利用代码误报为威胁，文档建议在 Shannon 目录加排除项或使用 Docker/WSL2 隔离（platforms.md）。

不随环境改变的限制

选对环境并不能消除以下文档明确写出的边界：

• 授权：只能测试自己拥有或持有明确书面授权的目标；
• 提示注入风险：不要把 Shannon 指向不受信或对抗性的代码库——读取源码的 AI 工具可能被恶意仓库内容影响；
• 覆盖范围：Shannon 只针对可主动利用的漏洞类别（Broken Authentication、Broken Authorization、Injection、XSS、SSRF），无法证明可利用的依赖漏洞、不安全配置类问题不会出现在报告里；
• 模型：官方仅支持 Claude 模型。

完成一次运行后，实际产出就是 workspace 根目录的Security-Assessment-Report.md（含可利用发现的 PoC 复现步骤）与.shannon/下的过程文件；按文档要求先人工复核，再决定是否把修复后的代码重新跑一轮验证。

【免费下载链接】shannonShannon is an AI pentester for web applications and APIs. It analyzes your source code, identifies attack vectors, and executes real exploits to prove vulnerabilities before they reach production.项目地址: https://gitcode.com/GitHub_Trending/shan/shannon