Back to Details

offensive-reporting

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Penetration Test Reporting — Professional Methodology

渗透测试报告——专业方法论

A great finding lost in a bad report is a wasted finding. Reports are the artifact the client pays for, the auditor reads, and the developer fixes from. Treat the report with the same rigor as the exploit.
再好的发现埋没在糟糕的报告里，也等于白费。报告是客户付费购买、审计人员审阅、开发者据此修复的交付物。撰写报告应与实施漏洞利用一样严谨。

Quick Workflow

快速工作流

  1. Capture evidence as you exploit — never reconstruct after the fact
  2. Draft each finding immediately while context is fresh; one finding = one numbered file
  3. Build the executive summary last, after all findings are scored
  4. Two-pass review: technical accuracy first, then read-as-CISO for narrative
  5. Hand off with a retest plan and a JSON/CSV index for the client's tracking system
  1. 在实施漏洞利用时实时采集证据——切勿事后重构
  2. 趁上下文尚清晰时立即起草每项发现；一个发现对应一个编号文件
  3. 所有发现完成评分后再编写执行摘要
  4. 两轮审阅：先检查技术准确性，再以 CISO 视角审阅叙事
  5. 交付时附上复测计划，以及供客户跟踪系统使用的 JSON/CSV 索引

Report Structure (Standard)

报告结构（标准）

1. Executive Summary             ← Last to write, first read
2. Engagement Overview
   2.1 Scope
   2.2 Methodology
   2.3 Limitations / Assumptions
   2.4 Timeline
   2.5 Team
3. Risk Summary                  ← Heatmap, finding count by severity
4. Technical Findings            ← One per finding, sorted by severity
5. Attack Narratives / Chains    ← Critical chains called out separately
6. Strategic Recommendations     ← Programmatic, not finding-by-finding
7. Appendices
   A. Tools Used
   B. Indicators of Compromise (for blue team)
   C. Raw Evidence Pointers
   D. Glossary
1. Executive Summary             ← Last to write, first read
2. Engagement Overview
   2.1 Scope
   2.2 Methodology
   2.3 Limitations / Assumptions
   2.4 Timeline
   2.5 Team
3. Risk Summary                  ← Heatmap, finding count by severity
4. Technical Findings            ← One per finding, sorted by severity
5. Attack Narratives / Chains    ← Critical chains called out separately
6. Strategic Recommendations     ← Programmatic, not finding-by-finding
7. Appendices
   A. Tools Used
   B. Indicators of Compromise (for blue team)
   C. Raw Evidence Pointers
   D. Glossary

Executive Summary — The 90-Second Read

执行摘要——90 秒阅读

The executive summary is for the CISO, the GRC officer, and the board member. They read this and nothing else.
Structure (one page max):
  1. Engagement context — what was tested, when, by whom (1 sentence)
  2. Headline finding — the worst thing you found, in business terms (2–3 sentences)
  3. Risk verdict — overall posture in plain language (1 paragraph)
  4. Counts — number of findings by severity, in a small table
  5. Top 3 strategic recommendations — programmatic fixes, not "patch CVE-X"
Words to avoid in the executive summary: 
payload
, 
RCE
, 
XSS
, 
LDAP
, 
SMB
, 
kerberos
, 
injection
. Translate every one. ("An attacker could run arbitrary commands on the server" not "RCE via deserialization gadget chain.")
Words to include: Business impact (
customer data
, 
regulatory exposure
, 
operational disruption
, 
financial loss
). Anchor every finding to a business consequence.
执行摘要面向 CISO、GRC 负责人和董事会成员。他们只会阅读这一部分。
结构（最多一页）：
  1. 项目背景——测试了什么、何时进行、由谁执行（1 句话）
  2. 核心发现——用业务语言说明发现的最高风险问题（2–3 句话）
  3. 风险结论——用通俗语言概述整体安全状况（1 段）
  4. 数量统计——按严重程度列明发现数量，并使用小型表格展示
  5. 前三项战略建议——提供体系性改进措施，而不是“修补 CVE-X”
执行摘要中应避免使用的词语： 
payload
、
RCE
、
XSS
、
LDAP
、
SMB
、
kerberos
、
injection
。逐一换成通俗表达。（应写成“攻击者可在服务器上运行任意命令”，而不是“通过反序列化 gadget chain 实现 RCE”。）
应使用的词语： 业务影响（
customer data
、
regulatory exposure
、
operational disruption
、
financial loss
）。将每项发现与业务后果建立联系。

Technical Finding Template

技术发现模板

markdown
undefined
markdown
undefined

Finding ID — Short Descriptive Title

Finding ID — Short Descriptive Title

Severity: Critical (CVSS 9.8 — vector below) Affected Scope: <hosts/URLs/components, with version where relevant> Status: Open / Fixed in retest / Accepted Risk CWE: CWE-89 (SQL Injection) OWASP: A03:2021 — Injection
Severity: Critical (CVSS 9.8 — vector below) Affected Scope: <hosts/URLs/components, with version where relevant> Status: Open / Fixed in retest / Accepted Risk CWE: CWE-89 (SQL Injection) OWASP: A03:2021 — Injection

Summary

Summary

One paragraph. What is the finding, why does it matter, what's the worst case.
One paragraph. What is the finding, why does it matter, what's the worst case.

Background

Background

What technology is involved and why this class of bug exists. Two paragraphs max. Skip if obvious (e.g. don't explain XSS to an XSS shop).
What technology is involved and why this class of bug exists. Two paragraphs max. Skip if obvious (e.g. don't explain XSS to an XSS shop).

Description

Description

Detailed walkthrough of the issue. The root cause, not just the symptom.
Detailed walkthrough of the issue. The root cause, not just the symptom.

Reproduction Steps

Reproduction Steps

  1. Numbered, copy-paste ready.
  2. Include the exact request/response, redacted.
  3. A reader with no engagement context should reproduce in <15 minutes.
  1. Numbered, copy-paste ready.
  2. Include the exact request/response, redacted.
  3. A reader with no engagement context should reproduce in <15 minutes.

Evidence

Evidence

  • screenshots/finding-007/01-payload.png
  • requests/finding-007/initial-poc.http
  • evidence-log.csv
    line 142 (timestamp 2025-04-12 14:33:07Z)
  • screenshots/finding-007/01-payload.png
  • requests/finding-007/initial-poc.http
  • evidence-log.csv
    line 142 (timestamp 2025-04-12 14:33:07Z)

Impact

Impact

Concrete. Quantified where possible.
  • "Read access to the entire customer table (~2.3M records)"
  • "Authenticate as any user; verified for sample ID 1, 2, 999, 1000000"
  • "Cross-tenant access — verified by reading data from acquired-tenant ABC"
Concrete. Quantified where possible.
  • "Read access to the entire customer table (~2.3M records)"
  • "Authenticate as any user; verified for sample ID 1, 2, 999, 1000000"
  • "Cross-tenant access — verified by reading data from acquired-tenant ABC"

Remediation

Remediation

Specific, actionable, ordered by precedence:
  1. Fix the bug — exact code change or config flag
  2. Defense in depth — secondary control (WAF rule, input validation)
  3. Detection — log line / SIEM rule that would have caught the exploit
Specific, actionable, ordered by precedence:
  1. Fix the bug — exact code change or config flag
  2. Defense in depth — secondary control (WAF rule, input validation)
  3. Detection — log line / SIEM rule that would have caught the exploit

References

References

  • CWE / OWASP / CAPEC
  • Vendor advisory if known CVE
  • Blog posts only if directly relevant
  • CWE / OWASP / CAPEC
  • Vendor advisory if known CVE
  • Blog posts only if directly relevant

Notes for Retest

Notes for Retest

What you'd do to verify the fix. Specific request, specific expected response.

---
What you'd do to verify the fix. Specific request, specific expected response.

---

Severity Scoring

严重程度评分

CVSS v3.1 Discipline

CVSS v3.1 评分规范

CVSS is a tool, not a verdict. Score it, then sanity-check against business impact.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 Critical
For every metric, justify the choice in one sentence:
  • AV:N
    — exposed to internet (port 443)
  • AC:L
    — no special preconditions
  • PR:N
    — no authentication needed
  • UI:N
    — no user interaction
  • S:U
    — does not cross security scope
  • C:H
    I:H
    A:H
    — full read/write/availability impact on the database
If two reasonable people would score it differently, document why you chose what you chose.
CVSS 是一种工具，而不是最终结论。先进行评分，再根据业务影响核查结果是否合理。
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 Critical
每项指标都应使用一句话说明选择依据：
  • AV:N
    ——暴露在互联网中（端口 443）
  • AC:L
    ——无需满足特殊前提条件
  • PR:N
    ——无需身份认证
  • UI:N
    ——无需用户交互
  • S:U
    ——不会跨越安全范围
  • C:H
    I:H
    A:H
    ——对数据库的读取、写入和可用性产生完整影响
如果两位具备合理判断能力的人可能给出不同评分，应记录你选择当前评分的依据。

When CVSS Lies

当 CVSS 反映失真时

CVSS doesn't capture business context. A "Medium" CVSS XSS in the customer support chat panel that authenticated agents use to handle PII is more dangerous than an unauthenticated "High" SSRF on a metadata-less internal service. Use CVSS as the floor, not the ceiling.
In those cases, score CVSS honestly and then add a "Business Impact Adjustment" paragraph that argues for higher reporting severity. Don't lie with CVSS.
CVSS 无法完整呈现业务背景。在处理 PII 的客户支持聊天面板中，一个 CVSS 评分为“Medium”的 XSS，可能比内部无元数据服务中一个未认证但 CVSS 评分为“High”的 SSRF 更危险。应将 CVSS 作为评分下限，而不是上限。
遇到这种情况时，应诚实填写 CVSS 评分，然后增加一个“业务影响调整”段落，论证为何应提高报告中的严重程度。不要篡改 CVSS 评分。

CVSS v4.0 (where required)

CVSS v4.0（按需使用）

CVSS v4.0 adds environmental and threat metrics that better capture real-world risk. Use it when the client mandates it (PCI DSS 4.0 trends this way) — otherwise v3.1 stays the lingua franca.
CVSS v4.0 增加了环境指标和威胁指标，能够更准确地反映真实世界中的风险。当客户明确要求时使用（PCI DSS 4.0 正逐步采用这一方向）；否则，v3.1 仍作为通用标准。

OWASP Risk Rating (alternative)

OWASP 风险评级（替代方案）

For web-app-only engagements where CVSS feels stretched, OWASP's risk rating (likelihood × impact across multiple factors) often communicates better.
对于仅涉及 Web 应用的测试项目，如果 CVSS 显得勉为其难，OWASP 风险评级（综合多个因素评估可能性与影响）通常更便于沟通。

Evidence Discipline

证据规范

What to Capture

需要采集的内容

For every finding, every action:
  1. Timestamp (UTC, ISO 8601)
  2. Source IP (yours, including any pivot)
  3. Target (host, URL, RPC interface)
  4. Action (what request was sent)
  5. Result (response, what you got)
  6. Hash of any data extracted (so you can prove what you saw)
csv
timestamp,operator,src_ip,target,action,result_hash,notes
2025-04-12T14:33:07Z,KA,10.10.10.5,app.client.com,SQLi probe ' OR 1=1--,sha256:abc...,initial detection
This is the audit trail. Clients with mature security teams will ask for it.
对于每项发现和每项操作，记录以下信息：
  1. 时间戳（UTC，ISO 8601）
  2. 源 IP（包括实施横向移动时使用的 IP）
  3. 目标（主机、URL、RPC 接口）
  4. 操作（发送了何种请求）
  5. 结果（响应内容以及获得了什么数据）
  6. 哈希值（对提取的任何数据进行哈希处理，以便证明所看到的内容）
csv
timestamp,operator,src_ip,target,action,result_hash,notes
2025-04-12T14:33:07Z,KA,10.10.10.5,app.client.com,SQLi probe ' OR 1=1--,sha256:abc...,initial detection
这就是审计轨迹。拥有成熟安全团队的客户会要求提供此类记录。

Redaction Rules

脱敏规则

Before any artifact leaves your secure environment:
  • Replace credentials with placeholders: 
    <REDACTED-PASSWORD>
    , 
    <TOKEN-A1>
  • Hash extracted PII — never include real names, emails, SSNs in screenshots
  • Crop screenshots to the relevant area; check for browser tab leaks (other tabs visible)
  • Strip EXIF from images; auto-redact via 
    exiftool -all= *.png
  • Remove debug toolbars from screenshots that reveal client infrastructure paths
  • Verify URLs in screenshots don't include session tokens
在任何制品离开安全环境之前：
  • 使用占位符替换凭据：
    <REDACTED-PASSWORD>
    、
    <TOKEN-A1>
  • 对提取的 PII 进行哈希处理——截图中绝不包含真实姓名、电子邮件地址或 SSN
  • 将截图裁剪至相关区域；检查浏览器标签页泄露情况（确保没有显示其他标签页）
  • 从图像中移除 EXIF；通过 
    exiftool -all= *.png
    自动脱敏
  • 从可能暴露客户端基础设施路径的截图中移除调试工具栏
  • 确认截图中的 URL 不包含会话令牌

Storage & Chain of Custody

存储与保管链

  • Encrypted volume during the engagement (LUKS, FileVault, BitLocker)
  • Per-engagement key, not a master operator key
  • Wipe to client-spec at end of engagement (typically 30–90 days post-delivery)
  • Retain only the report and a hash manifest of evidence, deletable on request
  • 测试期间使用加密卷（LUKS、FileVault、BitLocker）
  • 每个项目使用独立密钥，而不是共享的操作人员主密钥
  • 按客户要求在项目结束时清除数据（通常为交付后 30–90 天）
  • 仅保留报告和证据哈希清单，并可应客户要求删除

Scope, Limitations, and Assumptions

范围、限制与假设

These three sections protect both you and the client. Be explicit.
这三个部分既保护测试方，也保护客户。必须明确说明。

Scope

范围

  • IPs / domains / repos / accounts in scope, with start/end of engagement window
  • Excluded: third-party SaaS used by the client (they don't own it)
  • Out of scope by request: physical, social engineering against staff, DoS
  • 纳入范围的 IP、域名、代码仓库和账户，以及测试开始和结束时间窗口
  • 排除项：客户使用的第三方 SaaS（这些服务并非客户所有）
  • 按要求排除：针对员工的物理入侵、社会工程和 DoS

Limitations

限制

  • "Testing was conducted from the internet only; no internal network access provided"
  • "Source code review was not in scope"
  • "Production database mutations were avoided per ROE"
  • "No coordinated downtime — testing windows were 22:00–06:00 UTC"
  • “测试仅通过互联网进行；未获得内部网络访问权限”
  • “源代码审查不在本次范围内”
  • “根据 ROE，避免对生产数据库进行变更”
  • “未安排停机——测试窗口为 UTC 22:00–06:00”

Assumptions

假设

  • "We assumed the staging environment mirrors production"
  • "We assumed the WAF in front of app.client.com is the same as production"
  • "Service accounts with admin rights were assumed pre-existing"
  • “我们假设预发布环境与生产环境保持一致”
  • “我们假设 app.client.com 前方的 WAF 与生产环境中的 WAF 相同”
  • “假设具有管理员权限的服务账户原本就已存在”

Risk Summary & Heatmap

风险摘要与热力图

Show, don't tell. A visual summary every executive can read in 5 seconds:
Severity   Count   Top Example
Critical     3     RCE via deserialization (Finding #2)
High         7     ADCS ESC1 → Domain Admin (Finding #11)
Medium      14     Stored XSS in customer support panel (Finding #4)
Low         22     TLS 1.0 still enabled on api.client.com (Finding #29)
Info        11     —
A simple bar chart or stoplight grid converts this to a one-glance summary. Put it on page 2 (after exec summary).
用可视化方式呈现信息，让每位高管都能在 5 秒内看懂：
Severity   Count   Top Example
Critical     3     RCE via deserialization (Finding #2)
High         7     ADCS ESC1 → Domain Admin (Finding #11)
Medium      14     Stored XSS in customer support panel (Finding #4)
Low         22     TLS 1.0 still enabled on api.client.com (Finding #29)
Info        11     —
一个简单的柱状图或交通灯式网格即可将信息转换为一眼可读的摘要。将其放在第 2 页，也就是执行摘要之后。

Attack Chains / Narratives

攻击链与叙事

Critical findings rarely matter in isolation. The chain is the story:
1. Phishing email → user runs HTA payload (Finding #1, Medium)
2. Local UAC bypass via Token Manipulation (Finding #5, Low)
3. Kerberoast service account (Finding #11, High)
4. Crack TGS offline → service account password (Finding #11)
5. ACL abuse: service account has WriteDacl on Domain Users (Finding #14, High)
6. Grant DCSync, dump krbtgt → Golden Ticket → Domain Admin (Finding #15, Critical)

Total time: 4 hours. Detection points missed: 3 (see Appendix B).
Highlight chains separately because the combination often warrants higher severity than any individual finding.
严重发现很少具有独立存在的意义。攻击链才是完整的故事：
1. Phishing email → user runs HTA payload (Finding #1, Medium)
2. Local UAC bypass via Token Manipulation (Finding #5, Low)
3. Kerberoast service account (Finding #11, High)
4. Crack TGS offline → service account password (Finding #11)
5. ACL abuse: service account has WriteDacl on Domain Users (Finding #14, High)
6. Grant DCSync, dump krbtgt → Golden Ticket → Domain Admin (Finding #15, Critical)

Total time: 4 hours. Detection points missed: 3 (see Appendix B).
应单独突出攻击链，因为多个发现的组合往往比任何单项发现都值得更高的严重程度。

Strategic Recommendations

战略建议

Below the per-finding remediations, write 3–5 programmatic recommendations:
  • "Adopt SAST in CI for Java services" (addresses 12 findings)
  • "Roll out tier-0 admin model for AD" (addresses entire AD attack chain)
  • "Centralize secrets in HashiCorp Vault; rotate hardcoded creds" (addresses 9 findings)
This is what the CISO presents to the board. Make it memorable.
在各发现的修复措施之外，还应编写 3–5 项体系性建议：
  • “在 Java 服务的 CI 流程中采用 SAST”（可解决 12 项发现）
  • “为 AD 推行 tier-0 管理员模型”（可解决整条 AD 攻击链）
  • “将密钥集中管理至 HashiCorp Vault，并轮换硬编码凭据”（可解决 9 项发现）
CISO 会向董事会汇报这些内容。确保建议清晰、易记。

Deliverable Formats

交付物格式

FormatUse
PDFExecutive read, formal record, contractual deliverable
DOCXIf the client wants to redact or extend
HTMLInternal portal upload, searchable via grep
JSONSIEM / GRC tool ingestion (DefectDojo, Faraday, ServiceNow)
CSVQuick import into Jira / Asana for tracking
Markdown sourceThe single source of truth that generates all the above
Build all formats from one Markdown source via Pandoc / a static site generator. Never maintain parallel formats by hand.
bash
undefined
格式用途
PDF供高管阅读、作为正式记录以及合同交付物
DOCX客户需要删减或扩展内容时使用
HTML上传至内部门户，可通过 grep 搜索
JSON接入 SIEM / GRC 工具（DefectDojo、Faraday、ServiceNow）
CSV快速导入 Jira / Asana 进行跟踪
Markdown source生成上述所有格式的唯一事实来源
通过 Pandoc 或静态站点生成器，从同一个 Markdown 源文件构建所有格式。切勿手工维护多个并行版本。
bash
undefined

Markdown → polished PDF via Pandoc + LaTeX template

Markdown → polished PDF via Pandoc + LaTeX template

pandoc report.md -o report.pdf
--template=client-template.tex
--pdf-engine=xelatex
--metadata=title:"Penetration Test Report — Client Co."
--toc --number-sections

---
pandoc report.md -o report.pdf
--template=client-template.tex
--pdf-engine=xelatex
--metadata=title:"Penetration Test Report — Client Co."
--toc --number-sections

---

Common Report Mistakes

常见报告错误

MistakeFix
CVSS 9.0 on every finding ("over-CVSSing")Score honestly; clients lose trust if everything is critical
Marketing language ("revolutionary attack")Plain professional tone
Tool output dumped as evidenceCurate; show the relevant 5 lines
Generic remediation ("validate input")Specific code/config changes
Missing reproduction stepsIf they can't reproduce, they can't fix
Untimed evidenceEvery action gets a UTC timestamp
Confusing identical findingsGroup by class, list affected items in a table
Forgotten retest planEach finding includes how you'll verify the fix
Failure to separate scope from limitationsScope = what we tested; Limitations = what blocked us
Treating informational findings as fillerEither drop them or write them well
错误修正方式
每项发现都评为 CVSS 9.0（“过度 CVSS 化”）诚实评分；如果所有问题都是严重级别，客户会失去信任
使用营销式语言（“革命性的攻击”）采用平实、专业的语气
直接将工具输出倾倒为证据精心筛选，只展示相关的 5 行内容
修复建议过于笼统（“验证输入”）给出具体的代码或配置变更
缺少复现步骤如果无法复现，就无法修复
证据没有时间标记每项操作都要记录 UTC 时间戳
混淆相同的发现按问题类别分组，并以表格列出受影响项目
忘记制定复测计划每项发现都要说明将如何验证修复效果
未区分范围与限制范围＝测试了什么；限制＝哪些因素阻碍了测试
将信息类发现视为填充内容要么删除，要么认真编写

Reporting for Bug Bounty (Different Audience)

Bug Bounty 报告（不同受众）

Bug bounty triagers are time-pressured and skeptical. Adjust:
  • Title: include the bug class + endpoint + impact in 80 chars
  • Reproduction: a single curl command if possible, plus the expected vs actual response
  • Impact: anchor to the program's threat model (read PII? auth bypass? cross-account?)
  • Avoid: walls of text, screenshots without a request log, claims without reproduction
A good bounty report is read in 2 minutes and reproduced in 5. A bad one bounces with "more info."
Bug bounty 分诊人员时间紧张，而且持怀疑态度。应相应调整：
  • 标题：在 80 个字符内包含问题类别、端点和影响
  • 复现：尽可能只提供一条 curl 命令，并附上预期响应与实际响应
  • 影响：结合该项目的威胁模型说明（能否读取 PII？绕过身份验证？跨账户访问？）
  • 应避免：大段文字、没有请求日志的截图，以及无法复现的主张
一份优秀的 bounty 报告应能在 2 分钟内读完，并在 5 分钟内完成复现。糟糕的报告只会收到“需要提供更多信息”的回复。

Retest & Closeout

复测与收尾

markdown
undefined
markdown
undefined

Retest Summary

Retest Summary

FindingOriginal SeverityRetest StatusVerification Date
#1Critical✓ Fixed (verified)2025-05-10
#2High✓ Fixed2025-05-10
#5Medium⚠ Partially fixed — see notes2025-05-10
#11High✗ Not fixed — finding stands2025-05-10
#14Low• Accepted Risk (client decision)2025-05-10

For each finding, include the exact verification request/response showing the fix. Without proof, "fixed" is hearsay.

---
FindingOriginal SeverityRetest StatusVerification Date
#1Critical✓ Fixed (verified)2025-05-10
#2High✓ Fixed2025-05-10
#5Medium⚠ Partially fixed — see notes2025-05-10
#11High✗ Not fixed — finding stands2025-05-10
#14Low• Accepted Risk (client decision)2025-05-10

对于每项发现，都应附上证明修复情况的准确验证请求与响应。没有证据，“已修复”就只是传闻。

---

Sample CVSS Vectors (Reference)

CVSS 向量示例（参考）

ClassTypical VectorScore
Unauth RCE
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.8
Authed RCE
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.8
Stored XSS
AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
5.4
IDOR (PII read)
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
6.5
SSRF (cloud meta)
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
9.0
Open Redirect
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
4.3
Use these as starting points; adjust per environment.
类别典型向量评分
未认证 RCE
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.8
已认证 RCE
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.8
存储型 XSS
AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
5.4
IDOR（读取 PII）
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
6.5
SSRF（云元数据）
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
9.0
开放重定向
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
4.3
将这些向量作为起点，并根据实际环境进行调整。

Tooling

工具

ToolUse
Pandoc + LaTeXMarkdown → polished PDF
Sphinx / mkdocsMarkdown → HTML portal
DefectDojoFinding tracking, JSON export
FaradayMulti-engagement aggregation
DradisCollaborative report drafting
serpico (legacy but still used)Pentest report templates
PlextracCommercial reporting platform
工具用途
Pandoc + LaTeXMarkdown → 精美 PDF
Sphinx / mkdocsMarkdown → HTML 门户
DefectDojo发现跟踪与 JSON 导出
Faraday多次测试活动聚合
Dradis协作式报告起草
serpico（旧版但仍在使用）渗透测试报告模板
Plextrac商业报告平台

Key References

主要参考资料

  • NIST SP 800-115 (technical security testing reporting)
  • PTES — Penetration Testing Execution Standard, reporting section
  • OWASP Testing Guide — reporting chapter
  • FIRST CVSS v3.1 / v4.0 specifications
  • CREST Cyber Security Incident Response and Penetration Testing reporting standards
  • Source: https://github.com/SnailSploit/offensive-checklist/blob/main/reporting.md