Building security tools always sounds more impressive than it really is at the beginning.
In my case, PentestScan started as a practical idea:
I wanted to build a simple Web & API security scanner that could help developers, small teams, and DevOps engineers catch common security issues earlier - before an application reaches production.
Not as a replacement for professional penetration testing.
Not as a magic “find everything” scanner.
But it is a practical DevSecOps tool that gives fast, understandable feedback.
The problem I wanted to solve was simple:
A lot of small teams do not have a dedicated AppSec engineer.
Security reviews often happen too late.
Reports from bigger tools can be too complex, too noisy, or too expensive for early-stage projects.
And developers usually need something direct:
What is wrong?
Why does it matter?
How can I fix it?
That is the direction I took with PentestScan.
What PentestScan does
PentestScan is a Web & API security scanner focused on practical checks around common security weaknesses.
The current version is built around:
Web application scanning
API security testing
OWASP Top 10 related checks
Security headers analysis
JWT and session-related checks
Basic exposure detection
Report generation
DevSecOps-friendly workflow
The goal is not to overload the user with hundreds of unclear findings.
The goal is to provide a clean report that helps someone understand the risk and take action.
Tech stack
The project is built with a simple and practical stack:
Python
FastAPI
Docker
Nginx
HTML reporting
API-first backend structure
Security-focused scanning modules
I wanted the architecture to stay modular because security tooling can become messy very quickly if everything is placed into one large script.
So the scanner is organized around separate modules and checks, with the idea that new functionality can be added gradually without breaking the existing structure.
Why I built it
I built PentestScan mainly as a hands-on DevSecOps project.
I wanted to combine several areas that I work with and care about:
application security
backend development
automation
Linux deployment
Docker-based services
CI/CD security thinking
security reporting
One thing I learned while building it is that detection is only one part of the problem.
The harder part is explaining the finding in a useful way.
A security report should not only say:
Missing security header detected.
It should explain:
what was detected,
why it matters,
how it could be abused,
how serious it is,
and what the developer can do next.
That became one of the most important ideas behind the project.
What I am trying to improve
PentestScan is still evolving.
Some of the things I am working on or planning to improve are:
better API scanning
cleaner report structure
more contextual findings
CI/CD integration
better severity scoring
improved attack-path style explanations
more useful remediation guidance
public sample reports
I am also trying to keep the tool realistic.
Security scanners can easily create false confidence.
Just because a scanner does not find something does not mean the application is secure.
So I see PentestScan as a first security layer - something that can help teams catch obvious and common issues earlier, not as a full replacement for manual testing.
Current version
The project is currently available for free here:
Before trying the scanner, you can also check a public sample report:
Sample vulnerability report:
https://pentestscan.app/api/v1/public/marketing/vulnerability_report.html
I am sharing PentestScan publicly to get feedback from developers, DevOps engineers, and security people.
I would especially appreciate feedback on:
- report structure and clarity,
- usefulness of the findings,
- scanning flow,
- missing checks,
- and whether the tool feels useful for small teams or solo developers.
This project is still a work in progress, but it has already been a valuable learning experience in building security tooling that is not only technical but also understandable and useful.
That, for me, is the main point of PentestScan:
help developers see security issues earlier, understand them faster, and fix them with less friction.
Top comments (0)