APTRS turns pentest findings into client ready reports

A reporting system for the part of pentesting that happens afterwards

APTRS stands for Automated Penetration Testing Reporting System, and the project describes itself as a Python and Django based automated reporting tool for penetration testers and security organizations. The scope is worth stating precisely, because the name invites a different assumption. It does not scan, exploit or enumerate anything. It is the half of the workflow that happens once the testing is over and somebody has to turn a pile of findings into a document a client will read.

The problem it addresses is repetition. A consultancy running several engagements produces several reports that share a structure, differ in scope and findings, and have to be assembled by hand each time. APTRS stores the findings as data instead, tracks them per project, and generates the document. The feature list names the pieces: manage vulnerabilities, keep a vulnerability database, hold all projects in one place, manage customers and companies, and track project status, schedules and retest. There is also dynamic addition of proof of concept, description and recommendations to a finding, which is the part that varies most between engagements and therefore the part most worth not retyping.

The audience is professional testers and small security organisations with more than one client. A single person doing occasional work would probably find a word processor faster, and the tool's cost is a running stack plus the discipline of entering findings consistently enough for templates to fill in.

The stack behind the docker compose file

The compose file in the repository root is the clearest description of the architecture, and it has four services rather than one. Nginx sits in front, built from a separate frontend Dockerfile at docker/Dockerfile_frontend, publishing ports 80 and 443 and mounting a static volume and a media volume. The application service is the APTRS image itself, pulled as ghcr.io/aptrs/aptrs:latest, and it receives its configuration from an .env file.

The other two services are stateful. Postgres holds the data, with credentials taken from the .env file and a healthcheck that runs pg_isready every ten seconds, retrying five times. Redis is used as the cache and as the broker, running the 6.2 alpine image with a password supplied through the command line. The application connects to both through environment variables, POSTGRES_HOST and POSTGRES_PORT, REDIS_URL, and it also takes WHITELIST_IP, ALLOWED_HOST, CORS_ORIGIN and the USE_S3 switch.

Behind the application, the Python dependencies in pyproject.toml show the machinery. Django 4.2.22 with Django REST Framework 3.15.2 and simplejwt for token authentication, celery and django-celery-beat for background and scheduled jobs, redis and django-redis for caching, psycopg2-binary for the database, docxtpl for Word templates, weasyprint for PDF rendering, xlsxwriter for Excel output, jinja2 for templating, bleach for sanitising HTML, pillow for image handling, boto3 with django-storages for S3 storage, and gunicorn as the WSGI server.

The frontend is a separate TypeScript application in the frontend directory, and it has its own workflow for tests and builds alongside a Django build workflow and a CodeQL workflow.

The template is the report, and it comes in two flavours

Report generation is the reason the project exists, so it is worth looking at how it works. You write a template, either in DOCX or in HTML and CSS, and APTRS fills it with the data from the project and its findings. The feature list puts both templates at the top: custom report template in Docx or HTML/CSS, easily generate PDF, DOCX and Excel report, and easily customize PDF and DOCX report template.

The Python dependencies explain the split. docxtpl handles the Word route, taking a .docx file with placeholder fields and substituting values into it. WeasyPrint handles the HTML and CSS route, rendering styled markup to PDF, which means a team that already designs in CSS can style a report the same way they style a web page. xlsxwriter produces the spreadsheet export, and jinja2 is there for template rendering in general, with bleach limiting the HTML that can be injected into a template.

The practical advantage of a template based system is that a senior tester can change the wording and layout of a report without touching the application or writing code, and the same data produces a client facing PDF, an editable Word file and a spreadsheet for internal tracking. The cost is the same as any template system: the template has to be designed, and every report carries whatever fields the template author remembered to include.

The documentation asks you to review the Installation and Deployment Guide, and the API is published separately and can be fetched into Bruno, which suggests the project expects some automation around the reporting workflow rather than only manual data entry.

Projects, findings, customers and a portal the client logs into

The data model is what makes the tool more than a PDF generator, and the feature list is organised around it.

At the top are projects. Each engagement is a project, and the project carries status, schedule and retest information, so a team can see at a glance what is in progress, what is overdue and what is waiting for a second round. Findings live against a project, and there is a vulnerability database behind them, which is the piece that compounds: a title that has been found before can be described once and reused rather than rewritten in every report.

Around that sit customers and companies. Those entities exist because a tester may work for one company across many projects, or for many companies, and the report needs to be addressed to the right legal entity with the right scope statement. That is a small feature in the list and a large one in practice for anyone who has written a scope section by hand.

The customer dashboard is the other side of the boundary. The documentation states that a customer can log in, check their projects and download reports, which moves report delivery out of email and into a place the client controls. It also means the tool holds a client facing surface, so the security configuration the README warns about, with its environment variables, whitelist, allowed hosts and CORS origin, is part of setting this up rather than an afterthought. A demo of that portal is available at live.aptrs.com, and the project publishes default credentials for it in the README, which is fine for a demo instance and not something to copy into production.

Getting it running with the documented quick install

The quick installation path in the documentation is a clone, an environment file and a compose start:

git clone https://github.com/APTRS/APTRS
cd APTRS
cp env.docker .env
nano .env
docker-compose up

The copy step is the important one, because the file env.docker in the repository root holds the template for the environment variables that the compose file and the application both read. Editing .env before the first start covers the Postgres credentials, the Redis password, the allowed host, the CORS origin and the whitelist values that the compose file passes through. The project supports Python 3.9 and above, Django 4.2.22, and NodeJS 18 and above for the frontend, and it states that the platform badge covers osx, linux and windows.

Two warnings in the documentation are worth honouring. The first is the review of the Installation and Deployment Guide before installing, and the second is the review of the Security Configuration section for environment variables and other installation methods. Given that the compose file publishes Postgres, Redis and the application alongside nginx, the security configuration step is not optional in a shared or reachable network.

Beyond the compose path, the repository also ships a container image published to the GitHub Container Registry, and the compose file uses that image for the application service, so an installation that only wants the prebuilt image does not need a source build. A working set of environment variables is the part of this setup you will actually have to get right, since the stack refuses to start cleanly without a coherent .env.

A licence mismatch worth resolving before you adopt it

The licence story in this repository is not as simple as the badge suggests. The project description lists the licence as MIT, and the repository root contains a LICENSE.md file, and the README carries a badge pointing at the Apache style MIT badge image, all of which point one way. The pyproject.toml says something different. Under the poetry metadata the package version is 1.0, the author is Sourav Kalal, and the licence field reads APTRS Licence rather than MIT.

This is not a nitpick. Commercial buyers often run a dependency licence check before adopting a tool, and a metadata field that names an unspecified licence will either fail that check or trigger a legal review. The repository also contains a Certificate directory, which suggests signed or certification material ships with the source, and the README shows a sponsor and donation section rather than a conventional dual licence notice.

Since the README directs readers to the Security Policy for responsible disclosure and the repository ships CODE_OF_CONDUCT.md, the project is organised like a company or commercial open source project rather than a community utility, and that is consistent with the custom licence name. The practical step for an evaluator is to read the LICENSE.md and Certificate material in the repository, and to get a written answer from the maintainers about what obligations the named licence imposes, rather than relying on the MIT badge.

The MIT label in the project metadata may simply be an oversight, but an oversight in a licence field is the kind of thing that has to be closed out before a client engagement depends on it.

Release rhythm, maintenance state, and the alternative of doing it by hand

The repository is not archived. The last push was on 2026-09-27, and the same day produced the release v2.0.2. Before that came v2.0.1 on 2026-03-31 and v2.0 on 2025-05-18, so the project has a clear major version line and moves in step releases rather than constant churn. The v2 releases are recent enough to mean the report template and dashboard features described in the documentation are part of the current line rather than a roadmap.

The alternative to APTRS is the manual path, and the difference is specific rather than a matter of taste. Writing the report in a word processor means a tester copies findings from a spreadsheet or a personal note system into a document, one engagement at a time, with no reuse of a description you already wrote, no record of retest status, and no client portal. A template based generator turns the same effort into data entry, but it demands that findings are recorded in a consistent shape, which is a discipline the manual path never required.

A third option is to build the reporting layer on top of an existing vulnerability tracker and write only the document generation yourself. That gives you a single tool instead of two, and it gives up the customer dashboard, the retest tracking and the DOCX and PDF template machinery that are the reason most teams look at APTRS in the first place.

For a team with repeat engagements, the deciding factor is not the feature list, it is whether your testers will enter findings into a structured form instead of writing prose. If they will, the templates and the client portal pay for themselves quickly. If they will not, any tool of this kind ends up as a second place to store data nobody maintains.

Editorial conclusion

APTRS is worth adopting for a consultancy or in house team that repeatedly writes the same kind of client report, has several projects running at once, and wants a customer portal where a client can read status and download finished reports. It is the wrong tool if you need to run the testing itself, if a single consultant works on two engagements a year, or if you are unwilling to operate Postgres, Redis, Celery and nginx through Docker Compose. Before you install it, read the Installation and Deployment Guide and the Security Configuration section in the documentation, change the default credentials used by the live demo, and settle the licence question for your organisation, because the repository carries an MIT licence file while the pyproject.toml metadata names a different licence.

Frequently asked questions

Official sources

1. APTRS/APTRS on GitHub
2. License: MIT
3. Project website
4. README
5. Releases