security-pentest

name	security-pentest
description	Write a dual-audience PTES/OWASP-style penetration-test report — an Executive Summary for leadership (background, posture, risk profile, general findings, recommendation summary, strategic roadmap) plus a Technical Report for engineers (information gathering, vulnerability assessment, exploitation, post-exploitation, and a mandatory severity-ranked findings table scored against a current CVSS rubric). Use when the deliverable is an authorized penetration-test engagement report that must brief executives and equip remediation engineers from the same evidence base. Anti-trigger; for a controls-vs-framework compliance mapping use nist-sp or compliance-audit, for an operational incident-response procedure use playbook or sre-runbook.
argument-hint	<the engagement or system under test to report on>

security-pentest

Produces a dual-audience penetration-test report: a single deliverable that serves both an executive reader and an engineering reader from one evidence base, following the Penetration Testing Execution Standard (PTES) reporting model with an OWASP-style findings discipline (scope, methodology, findings with CVSS severity, proof-of-concept, remediation). Its center of gravity is the severity-ranked findings table — a report is not conformant without one mapping every surviving finding to a CVSS-scored severity, affected assets, evidence, and remediation. This genre is for authorized engagements only; the authorization and scope statement is required matter, not optional framing.

Pattern (industry: PTES / OWASP-style, dual-audience)

Front matter

• Authorization & Scope Statement — engagement authorization, in-scope targets, rules of engagement, and the testing window. Required matter for every report this genre produces.

Part 1 — Executive Summary (strategic altitude)

1. Background — engagement purpose, scope summary, and objectives in business terms.
2. Posture — overall security posture assessment in plain language.
3. Risk Profile — the aggregate risk picture: severity distribution and business exposure, not per-finding exploit detail.
4. General Findings — themes and systemic weaknesses, framed for a non-technical reader.
5. Recommendation Summary — prioritized remediation recommendations at the program level.
6. Strategic Roadmap — a sequenced, time-phased remediation plan (short / medium / long term).

Part 2 — Technical Report (operational altitude)

1. Information Gathering — reconnaissance, enumeration, and attack-surface mapping.
2. Vulnerability Assessment — identified weaknesses, each tied to a finding.
3. Exploitation / Confirmation — confirmed exploitation with reproducible evidence; distinguishes confirmed from theoretical.
4. Post-Exploitation — privilege escalation, lateral movement, persistence, and demonstrated business impact.
5. Risk / Remediation — a required severity-ranked findings table: for every finding, its CVSS severity rating, affected assets, evidence (proof-of-concept), and concrete remediation guidance. A report without this table is not a conformant penetration-test report.

Rules

• The Risk/Remediation findings table is mandatory, not optional matter — it is the section that grounds severity and remediation priority. Render it as a Markdown table, never ASCII art or an image.
• Every claim — reconnaissance result, vulnerability, exploitation step, and severity rating — traces to a finding and its evidence; no orphan facts.
• Report verification verdicts; do not silently drop weakened or inconclusive findings — annotate them inline. Exclude only falsified findings: an unconfirmed exploit asserted as confirmed is a defect.
• Keep the two audiences distinct: no exploit primitives or raw command output in the Executive Summary; no business-only hand-waving in the Technical Report.
• Severity is scored against a current, cited rubric (e.g. CVSS). Verify the current CVSS version live at authoring time and cite the rubric used — do not bake a fixed edition into the report as settled fact.
• Exhaustive coverage: build the report from the full surviving-findings corpus — every surviving finding gets its own row (evidence, severity, remediation), never condensed to a cherry-picked subset. A silently dropped finding is a defect.
• Any figure, chart, or diagram (e.g. a severity-distribution chart) is a fenced mermaid code block — never ASCII art, an image link, or Graphviz/DOT — and a required figure is never silently omitted; say so in prose if the data cannot support it.

Anti-triggers — do not use this genre for

• A controls-vs-framework compliance mapping (e.g. NIST CSF / SP 800-series control coverage, audit attestation) — that is nist-sp or compliance-audit: framework-driven control assessment, not an authorized offensive-testing engagement with exploitation evidence.
• A tactical, step-by-step response to one alert or incident — that is sre-runbook: reactive operational procedure, not a scoped, authorized testing engagement with findings and CVSS severity.
• A strategic, multi-incident coordination procedure across roles — that is playbook: operational coordination, not an evidence-based engagement report.

MIF frontmatter

type: semantic — a penetration-test report is declarative finding-and-remediation knowledge captured after the engagement, not a time-bound event stream or a step sequence. Climb to L2 with namespace (security-pentest/<area>, e.g. security-pentest/web-application), modified, title, and tags when the engagement context supplies them. entity.entity_type is pentest-report. Gate every output with mif-validate at its target level; the floor is --level 1.

Why machine-readable — the point of MIF here

Question an agent asks	Answered by (frontmatter)
Is this engagement's risk picture still current?	temporal.validFrom / ttl
Where did each finding's evidence come from; can I trust it?	provenance (W3C-PROV) + citations[]
What does this report formalize or relate to (e.g. a remediation ticket or ADR)?	typed relationships[] (relates-to)
Which findings survived falsification vs. were excluded or annotated?	the per-finding verdict recorded against citations[]

The same document still reads as a human engagement report and projects losslessly to JSON-LD and back — one artifact, two readers.

The L1 -> L3 climb (two exemplars)

• templates/good-l1.md — L1 floor: id, type, created + body. A complete, valid report, but opaque to a machine consumer.
• templates/good.md — L3 (highest this genre supports): adds namespace, modified, temporal validity, W3C-PROV provenance, citations[] tied to each finding, and a typed relationships[] graph (e.g. relates-to the remediation engineering report that acts on the findings). Validate with mif-validate --level 3.

Author at the highest level the drafting context supports (grade down rather than fabricate). templates/bad.md shows the antipattern: a report that asserts findings and severities in prose with no severity-ranked findings table to ground them.