mcpField
R
report-generate

report-generate

github.com/wgpsec安全1.8k57 次安装4 天前更新
代码仓库

关于 report-generate

report-generate 是面向渗透测试人员的报告编写方法论，涵盖数据收集、报告结构、风险评级和交付检查。它强调让管理层理解业务影响、让技术人员能够复现问题，并对敏感信息进行脱敏。

主要功能

  1. 01整理资产、漏洞与凭据数据
  2. 02提供渗透测试报告结构模板
  3. 03按风险等级描述漏洞与修复建议
  4. 04强调可复现、可理解和可操作
  5. 05检查敏感信息脱敏与交付质量

适用场景

  1. 01将测试发现整理成正式报告
  2. 02向管理层说明风险和优先行动项
  3. 03在交付前检查漏洞细节与敏感数据处理

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/wgpsec/aboutsecurity --skill report-generate

安装后在 Claude Code 中输入/report-generate确认已加载。

附带文件evals/evals.jsonevals/recall.json

详细介绍

来自项目 README

渗透测试报告生成方法论

报告是渗透测试的最终交付物——再厉害的攻击，如果报告写不好，客户看不懂，等于白做。

数据采集

先收集所有已有数据：

  • get_store_stats — 整体统计
  • evidence_list（按类型筛选）— 资产清单
  • list_vulns — 漏洞列表
  • evidence_list + evidence_read（筛选凭据类型）— 凭据（脱敏后放入报告）

报告结构模板

1. 执行摘要（1 页，给管理层看）

用非技术语言概述：

  • 评估范围和时间
  • 一句话结论：整体安全状况如何（如"发现 3 个严重漏洞，攻击者可远程获取服务器完全控制权"）
  • 关键数字：资产数量、漏洞数量（按等级分布）
  • 最紧急的行动项
2. 评估范围与方法
  • 目标清单（域名/IP/应用）
  • 测试类型（黑盒/灰盒/白盒）
  • 使用的方法论和工具
  • 限制条件（时间、范围排除）
3. 发现总览

漏洞统计图表：

严重: ■■ 2
高危: ■■■ 3
中危: ■■■■■ 5
低危: ■■■ 3
信息: ■■■■■■ 6
4. 漏洞详情（核心部分）

每个漏洞按以下结构描述：

[严重] SQL 注入 — 用户搜索功能

  • 位置：https://target.com/search?q=
  • 描述：搜索参数未经过滤直接拼入 SQL 查询，攻击者可读取/修改/删除数据库内容
  • 影响：可获取所有用户数据（含密码哈希）、可读取服务器文件
  • 复现步骤：
    1. 访问 https://target.com/search?q=' OR 1=1--
    2. 页面返回所有记录（正常应只返回匹配项）
    3. 使用 UNION SELECT 可提取 users 表
  • 修复建议：使用参数化查询（Prepared Statement），禁止字符串拼接 SQL
5. 风险评级标准

使用 CVSS 3.1 或简化版：

等级CVSS典型场景
严重9.0-10.0RCE、SQL注入可获取shell、认证完全绕过
高危7.0-8.9敏感数据泄露、权限提升、任意文件读取
中危4.0-6.9存储型XSS、CSRF、信息泄露
低危0.1-3.9反射型XSS、目录列表、版本泄露
信息0安全配置建议、最佳实践偏离
6. 修复建议优先级

按修复紧迫性排序：

  1. 立即修复：严重和高危漏洞
  2. 计划修复：中危漏洞（下个版本）
  3. 择机改进：低危和信息级
7. 附录
  • 工具列表和版本
  • 详细测试时间线
  • 原始扫描数据（可选）

写作原则

  • 可复现：技术人员看完复现步骤能自己验证；小型 PoC 可放在复现步骤，较长 PoC 放附录并在正文引用
  • 可理解：管理层看完执行摘要能理解风险；漏洞影响要落到业务后果，而不是只写技术名词
  • 可操作：修复建议具体到代码/配置级别
  • 不夸大：客观描述风险，不为了显得重要而提升等级
  • 可交付：最终交付优先使用 PDF；不要把可编辑的 Word/Markdown/LaTeX 作为唯一交付物
  • 避免主观情绪化表述，保持专业

交付质量检查

敏感信息脱敏
  • 对密码、Token、身份证件、个人照片、客户数据做不可逆遮盖，避免只用半透明模糊
  • 截图导入文档前先在图片文件中完成遮盖；不要依赖 Word 里的覆盖图形，原图可能仍保存在文档包内
  • 对凭据只保留必要前后缀用于定位，例如 AKIA...ABCD
截图规范
  • 截图只保留能证明漏洞的最小区域，确保命令、URL、状态码和关键响应可读
  • 避免暗色透明终端；报告经常会被打印或压缩，低对比度截图会失真
  • 每张图加标题或说明，图中高亮关键证据
  • 命令行截图应包含实际命令；纯输出截图不利于复现
文档卫生
  • 列表要去重并排序（按严重度、域名、IP、端口或时间线）
  • 避免“多个”“一些”等模糊数量，能量化就写具体数量
  • 不要把客户敏感数据发送到不受控的在线 LLM；如需辅助写作，优先使用本地模型或先脱敏
  • 交付前检查拼写、链接、图片清晰度、目录、页眉页脚和附件是否完整

评论

支持 Markdown