pentestplate

Run penetration tests without the spreadsheet chaos.
Scope the engagement, record findings, review them, chase the fixes and generate the client report — all in one place.

Website · Getting started · Architecture · Development · Security · MIT License

---

What it is — and what it isn't

pentestplate runs the engagement. It does not scan anything.

Who does what:

• Your testers: scope, findings, CVSS, CWE/CVE references, evidence files, remediation status.
• pentestplate: the QA gate, the client-ready report, the compliance variants, and the audit trail.

Deliberately not in pentestplate:

• No scanner, no fuzzer, no discovery, no wrapper around nmap, Burp or Nuclei.
• No finding reaches a report until it has passed QA review — unless you explicitly ask for a draft that includes unapproved work.

Scanner output is an input to pentestplate, not a competitor to it. Every tool you already use produces things you have to write up — this is where that happens.

The short version

• 📋 Scope the engagement: in-scope, out-of-scope, window, methodology, testers.
• 🔎 Record findings with CVSS, CWE/CVE, evidence files and PTES/NIST fields.
• ✅ Gate findings behind QA review — only approved ones go into a report.
• 📄 Export PDF, HTML, Excel or JSON — or PCI-DSS, HIPAA, SOC 2, ISO 27001.
• 🔧 Track remediation: open → being fixed → awaiting re-test → verified.
• 📜 Leave an audit trail of every change, review and sign-off.

Does this sound familiar?

• Findings live in a spreadsheet that three people edit at the same time.
• Screenshots of the same bug are in four different folders.
• Someone asks "is that critical one fixed yet?" and nobody can answer quickly.
• The client report is assembled by hand at the end, and it takes two days.
• A tester's writing goes to the client without anyone checking it first.
• Six months later, nobody can say who signed off what.

pentestplate exists to remove those problems.

The usual way vs. pentestplate

The usual way	With pentestplate
Findings scattered across spreadsheets	One findings list per engagement — severity, CVSS, CWE/CVE references and evidence files attached
Each report written from scratch	Findings become report sections, in one click, as PDF, HTML, Excel or JSON
Unreviewed work reaching the client	Findings are held behind a QA gate — only approved ones appear in a report, and the report says how many are still waiting
"Is it fixed?" answered by email	A remediation board: open → being fixed → awaiting re-test → verified
No record of who changed what	An audit trail of every change, review and sign-off, with who and when
Scope agreed verbally and forgotten	In-scope and out-of-scope targets recorded per engagement, with a readiness checklist showing what is still missing before you report
Hosts, URLs and APIs tracked in someone's head	An asset inventory per engagement — findings link back to what they are on

Roles and the QA gate

The part most teams do by email, made explicit through permissions:

• Pentester — creates and updates findings, attaches evidence, updates engagements. Deliberately holds no finding:approve, so a tester cannot sign off their own work.
• App Owner — read access plus finding:update: enough to move remediation status and record a re-test, without touching the report.
• Admin — the only seeded role that can approve findings and reports, generate reports, manage users and roles, and read the audit trail.
• Read-only audiences — Client (findings and reports), Executive (reports, plus read-only project and engagement context) and Report Viewer (read-only across projects, engagements, findings, evidence and reports).

A finding starts as a draft and is submitted for review; an approver either releases it for reporting or returns it with notes. By default only approved findings are included in a report, and the report records how many QA is still withholding. Generating with include_unapproved overrides the gate for internal drafts — it is not meant for anything a client receives.

Permissions are wildcard-capable (project:* grants project:read), scoped per tenant, and enforced in the API — the web client holds no authorisation logic of its own.

A quick tour

See where everything stands

One screen showing active projects, total and critical findings, what is waiting on QA, what is overdue, and what still needs re-testing.

Scope the engagement

Record what is in scope and what is not, the test window, the methodology, and a plain-language executive summary. Testers are assigned per engagement, and the hosts, URLs and APIs under test are recorded as assets so a finding can point back at what it is on. A readiness checklist shows what is still missing before you can report.

Record findings properly

Each finding carries severity, a CVSS vector and score, CWE/CVE references, confidence, and the PTES/NIST fields clients ask for: steps to reproduce, proof of concept, impact, likelihood, inherent and residual risk. QA review and remediation live on the same page, so nobody has to hunt for them.

Review before it reaches the client

A finding starts as a draft and is submitted for review; a reviewer either approves it for reporting or returns it with notes. By default only approved findings are included in a report, and the report shows how many QA is still holding back — so the numbers are never a surprise.

Chase the fixes

A remediation board answering the questions that arrive after testing: what is still open, what is overdue, what a client claims is fixed and still needs re-testing, and what has nobody working it. Moving a finding through open → being fixed → resolved → verified is validated against an explicit transition table, so a finding cannot jump straight from open to verified, and the board separates what is fixed from what has actually been re-tested.

Generate the client report

Executive, technical, detailed, compliance, PCI-DSS, HIPAA, SOC 2 and ISO 27001 reports — exported as PDF, HTML, Excel or JSON. Coverage includes a cover page, severity breakdown, CVSS matrix, OWASP mapping, methodology and a remediation tracker. The report itself moves through review and delivery, and regenerating after a change creates a new version rather than overwriting the one the client already has.

Be able to prove what happened

An append-only audit trail records every state change, scope edit and sign-off, with the person responsible and the before/after values. When a client asks why something changed, you can show them.

How it is built

Next.js web  ──▶  Go / Gin API  ──▶  PostgreSQL 16
                       │
                       ├─▶  Evidence files    SHA-256, sharded directories
                       ├─▶  Report engine     PDF · HTML · XLSX · JSON
                       │                      + PCI-DSS / HIPAA / SOC 2 / ISO 27001
                       └─▶  Audit trail       every change, actor, before/after

Two containers you run yourself: the API and the web app, plus PostgreSQL. Client data, evidence and reports stay in your infrastructure — there is no telemetry, no phone-home and no vendor key. More detail in docs/architecture.md.

Who it is for

• Pentest teams who want an engagement's history in one place instead of spreadsheets and email threads.
• Team leads and reviewers who need to check findings before they reach a client.
• Anyone running a remediation programme, tracking which findings are fixed and which are still overdue.
• Compliance-driven engagements where a report has to map to a framework and an audit trail has to exist.

Getting started

The whole stack runs in Docker.

git clone https://github.com/SentinelSAST/pentestplate.git
cd pentestplate
cp .env.example .env        # optional: override the defaults
docker compose up --build

Then open http://localhost:3000 and sign in with:

admin@example.com / admin123

The API creates the schema on first boot and seeds the default tenant, the roles, the permission matrix and the admin user. Your dashboard starts empty.

Prefer to run it without Docker? See docs/development.md.

Warning

The default credentials and secrets in this repository are published here. Change the admin password, and set POSTGRES_PASSWORD and a random JWT_SECRET, before the stack is reachable by anyone else. The hardening checklist covers the rest — this tool ends up holding everything that goes into a client report.

Want some demo data to look at?

The images above come from a seeded Acme Corp engagement. Run the seeder against the same database and you get the same starting point — one project, two engagements, six findings and three demo users (Pentester, Report Viewer and Client) — and it prints the logins when it finishes:

cd apps/api
cp .env.example .env        # set DB_URL to the same Postgres
go run ./cmd/seed-data

The screenshots go a little further than the seeder: the asset inventory, the reports and the review/remediation state were built up through the UI.

Warning

The seeder creates real, loginable accounts with passwords published in this repository. Run it against a throwaway or evaluation database — never against an instance holding real client work.

Documentation

Document	What is in it
docs/architecture.md	How the system is put together, the enforced workflow states, the data model and the security model
docs/development.md	Running the API and web app locally, tests and production builds
docs/configuration.md	Every environment variable, including the ones that are placeholders
SECURITY.md	Reporting a vulnerability, what is in scope, and the operator hardening checklist

Common commands:

cd apps/api && go build ./... && go vet ./... && go test ./...
cd apps/web && pnpm lint && npx tsc --noEmit && pnpm test

Support

pentestplate is built and maintained by Proofpointed. For help, deployment questions or anything else, write to support@proofpointed.com — that reaches the people who work on it.

Found a security problem? Please follow SECURITY.md rather than opening a public issue.

Status

Actively developed, and pre-1.0 — expect occasional breaking changes between releases. The API is the source of truth for all business rules; the web client holds no authorisation logic of its own.

If pentestplate saves you a Sunday of report writing, a ⭐ helps other teams find it.

License

MIT — see LICENSE.