Open-Source Pentest Reporting: What Free Actually Costs

An open-source pentest reporting tool costs nothing to download, and on the assumptions set out below a three-tester firm spends roughly £7,700 to £13,800 running it in the first year and £5,500 to £9,900 in each year after, almost all of it in staff hours rather than servers. The software is often good. What the free licence does not include is the second job that comes with it: patching, backing up and securing a server that holds every client's findings, keeping templates working, and delivering reports once the PDF exists.

What free options do well

Start with what the free tools get right, because several are good software built by testers who had the same frustrations you do.

• No licence fee and no per-seat pricing, which matters most when the team grows faster than the revenue.
• Source you can read. You can see how findings are stored, how templates render and what leaves the server.
• Data on your own infrastructure, with no vendor in the path and the option of running entirely offline.
• Freedom to change it, if you have someone who can write the changes and keep maintaining them.
• Community findings and templates that give a new firm a starting library.

For a solo tester learning how a good report fits together, or an internal team that never delivers outside the building, that list can settle the decision on its own.

Hosting, patching and backups

The server is the cheap part: a small virtual machine and off-site backup storage come to £25 to £50 a month on our assumptions. The hours are where the money goes.

Every layer under the application needs keeping current: operating system, language runtime, database, reverse proxy, certificates and the application itself, whose upgrades can include database migrations you should rehearse on a copy before running them for real. Backups need encrypting, copying off the server and restoring on a schedule, because a backup nobody has restored is a hope rather than a control. Someone has to notice when the disk fills or the service stops, and that someone is usually the tester with the most reports due.

Templates and who maintains them

Every reporting tool has its own template system: HTML and CSS rendered to PDF, a typesetting language, or Word documents with tags the tool fills in. Getting your house style into it, with tables that break cleanly across pages, a contents page that updates and findings that sort by severity, typically takes several days the first time.

The cost that surprises firms comes later. An upgrade changes the template syntax or the data model, and the template breaks in the week a large report is due. The person who built it leaves, and nobody else understands it. Budget a day or two a year to keep templates working, make sure two people can change them, and if your clients expect Word, check whether the output is a genuinely editable document or a PDF in disguise.

The findings library is the other template. Community libraries give you a start, but the asset is your own wording, severity reasoning and remediation advice, built up engagement by engagement. Open source removes licence lock-in, not data lock-in: that library lives in one tool's schema, and moving it later is a migration project rather than an export button.

Securing the server that holds every client's findings

A reporting server is the most valuable machine a testing firm owns: every client's unfixed weaknesses, the evidence that proves them and often the credentials used to find them. Run it the way you would tell a client to run it.

• Enforce multi-factor authentication for every account. If the tool cannot, put single sign-on or an identity-aware proxy in front of it.
• Keep the administration interface off the internet, and the whole service too if clients do not need to log in.
• Encrypt disks and backups, and keep backup keys somewhere the server cannot reach.
• Give administrators separate accounts, log what they do and review who has access every quarter.
• Test your own instance at least once a year, and fix what you would have reported.

Read the licence as well. Under section 13 of the AGPL (version 3), if you modify software released under it and let users interact with it over a network, as clients would through a portal, you must offer them the source of your modified version. This is not legal advice, and it only bites if you change the code, but it catches out firms that do. The wider architecture choice, including the hosted alternatives, is covered in self-hosted or cloud pentest reporting, and our security architecture page shows the level of detail worth demanding from anything that holds findings, including your own server.

Client delivery after the PDF

Most free tools stop at the document, and the engagement does not. What follows is usually manual: an encrypted PDF by email with the password sent by text, a file-share link that expires before the client's security lead opens it, a second version after the debrief that leaves two "final" copies in circulation, and remediation tracked in a spreadsheet both sides edit. Then the retest, which means finding last quarter's evidence, writing up what changed and repeating the delivery. Attestation letters for auditors are usually written by hand in Word, outside the tool, and drift from the report they summarise.

Giving clients logins to a self-hosted tool solves some of that and creates another job: client accounts, password resets, second-factor support and a server that now has to face the internet. Our post on delivering pentest reports without emailing PDFs sets out what good delivery looks like, whatever you run.

The total cost, counted

The server is well under a tenth of every total. A solo tester with 20 reports a year spends less on delivery and about the same on patching; a firm already running infrastructure for other reasons spends less on the build and the same on everything else. Whatever you compare free against, compare it on the same basis, hours included, as we do in Word and spreadsheets or a pentest reporting platform.

When free is the right answer

• Solo testers and very small firms with low volume and real system administration skills, especially while learning what they want from a report.
• Internal security teams that report only to their own organisation.
• Isolated environments where no external service is permitted, such as classified or air-gapped work.
• Firms with developers who want to change the tool itself and will maintain those changes.

Free stops being the right answer when clients start asking where their findings live and who can read them, when the person maintaining the server is also your busiest tester, or when delivery and retests take more hours than the server ever did. None of that is a failing of the software. It is the point at which the second job outgrows the first.

If you start free, start deliberately. Write down where the data lives, who can reach it, how it is backed up and how you would move it, so that the day you outgrow the tool brings a planned migration rather than an emergency.