report-generate

name report-generate description 渗透测试报告生成。当完成安全评估需要输出正式报告时使用。覆盖报告结构模板、风险评级标准（CVSS）、漏洞描述写法、修复建议规范。适用于正式渗透测试报告和红队评估报告 metadata {"tags":"report,报告,summary,documentation,渗透测试报告,风险评级,修复建议","category":"general"} 渗透测试报告生成方法论 报告是渗透测试的最终交付物——再厉害的攻击，如果报告写不好，客户看不懂，等于白做。 数据采集 先收集所有已有数据： 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 查询，攻击者可读取/修改/删除数据库内容 影响 ：可获取所有用户数据（含密码哈希）、可读取服务器文件 复现步骤 ： 访问 https://target.com/search?q=' OR 1=1-- 页面返回所有记录（正常应只返回匹配项） 使用 UNION SELECT 可提取 users 表 修复建议 ：使用参数化查询（Prepared Statement），禁止字符串拼接 SQL 5. 风险评级标准 使用 CVSS 3.1 或简化版： 等级 CVSS 典型场景 严重 9.0-10.0 RCE、SQL注入可获取shell、认证完全绕过 高危 7.0-8.9 敏感数据泄露、权限提升、任意文件读取 中危 4.0-6.9 存储型XSS、CSRF、信息泄露 低危 0.1-3.9 反射型XSS、目录列表、版本泄露 信息 0 安全配置建议、最佳实践偏离 6. 修复建议优先级 按修复紧迫性排序： 立即修复 ：严重和高危漏洞 计划修复 ：中危漏洞（下个版本） 择机改进 ：低危和信息级 7. 附录 工具列表和版本 详细测试时间线 原始扫描数据（可选） 写作原则 可复现 ：技术人员看完复现步骤能自己验证；小型 PoC 可放在复现步骤，较长 PoC 放附录并在正文引用 可理解 ：管理层看完执行摘要能理解风险；漏洞影响要落到业务后果，而不是只写技术名词 可操作 ：修复建议具体到代码/配置级别 不夸大 ：客观描述风险，不为了显得重要而提升等级 可交付 ：最终交付优先使用 PDF；不要把可编辑的 Word/Markdown/LaTeX 作为唯一交付物 避免主观情绪化表述，保持专业 交付质量检查 敏感信息脱敏 对密码、Token、身份证件、个人照片、客户数据做不可逆遮盖，避免只用半透明模糊 截图导入文档前先在图片文件中完成遮盖；不要依赖 Word 里的覆盖图形，原图可能仍保存在文档包内 对凭据只保留必要前后缀用于定位，例如 AKIA...ABCD 截图规范 截图只保留能证明漏洞的最小区域，确保命令、URL、状态码和关键响应可读 避免暗色透明终端；报告经常会被打印或压缩，低对比度截图会失真 每张图加标题或说明，图中高亮关键证据 命令行截图应包含实际命令；纯输出截图不利于复现 文档卫生 列表要去重并排序（按严重度、域名、IP、端口或时间线） 避免“多个”“一些”等模糊数量，能量化就写具体数量 不要把客户敏感数据发送到不受控的在线 LLM；如需辅助写作，优先使用本地模型或先脱敏 交付前检查拼写、链接、图片清晰度、目录、页眉页脚和附件是否完整