DEV Community: Sandro

How Bug Hunter Evolved From a Test Runner Into a Self-Hosted Quality Intelligence Platform

Sandro — Sun, 13 Sep 2026 17:05:15 +0000

A few months ago, I wrote about Bug Hunter as a self-hosted testing tool for web applications and APIs.

At that point, the project could already:

discover application routes,
execute Playwright browser tests,
run direct API scenarios,
import OpenAPI definitions,
collect runtime evidence,
detect deterministic findings,
reproduce supported failures,
and generate reports.

Since then, the project has changed significantly.

The biggest change is not one individual feature.

It is the direction of the product itself.

Universal Bug Hunter is no longer something I think of as just a test runner.

It is becoming a self-hosted Quality Intelligence platform.

The current goal is:

Discover application behavior, generate and execute tests, detect regressions, explain failures, reduce test maintenance, and track product quality over time.

And importantly, the core workflow still works without an LLM.

AI is optional assistance, not the execution engine.

The workflow is now much broader

The current operator flow looks more like this:

Analyze application
→ build Application Map
→ create deterministic Test Plan
→ optionally generate AI suggestions
→ run tests
→ collect evidence
→ detect Quality Issues
→ qualify results
→ compare regressions
→ track reliability, coverage and performance

That is a very different product from the early version I shared.

The focus has moved from:

"Run a scenario and detect a failure"

toward:

"What changed in product quality, why did it change, and what should the operator investigate next?"

Reliability became a first-class concept

One of the first major improvements was reliability tracking.

A failed test is not automatically treated as a confirmed product bug.

The conceptual flow now looks more like this:

detected signal
→ Needs review
→ expected
   ignored
   observation
   quality_issue
→ regression evaluation where applicable

This distinction matters.

If a test produces seven signals, that does not automatically mean the product has seven bugs.

Some signals may be browser noise.

Some may be known behavior.

Some may be expected.

Some may become a confirmed quality_issue only after review.

That model makes the platform much more useful for real engineering workflows.

Self-healing and likely-cause analysis

Test maintenance is another problem I wanted to address.

UI automation can become expensive when selectors or page structures change frequently.

Universal Bug Hunter now includes a self-healing layer that can help identify alternative targets when an existing interaction no longer matches the application.

The important rule is that healing is not silent magic.

The system preserves evidence and keeps the behavior explainable.

The same principle applies to failure analysis.

Instead of simply showing:

Test failed

the platform can correlate evidence and surface a likely cause when there is enough information to support it.

For example:

Browser action
→ network request
→ HTTP 500
→ UI failed to update
→ likely cause: backend request failure

I deliberately avoid labeling every console or network event as a root cause.

Evidence and interpretation remain separate.

Visual regression testing

Visual testing is now part of the platform as well.

The system can work with baseline screenshots and compare them with current execution results.

The workflow includes:

baseline
→ current screenshot
→ visual comparison
→ threshold evaluation
→ regression result

This is useful for catching changes that functional assertions may miss.

Examples include:

layout shifts,
missing elements,
unexpected responsive changes,
visual regressions after frontend changes.

The goal is not to replace visual review.

The goal is to make visual changes measurable and reproducible.

Accessibility testing

Accessibility testing was added as another quality signal.

The platform can detect WCAG-related issues and associate them with the same project/run context as functional, visual and API testing.

This is important to me because I do not want Universal Bug Hunter to become a collection of disconnected testing tools.

Accessibility findings should live in the same quality model as other product evidence.

Project Knowledge

Another large change was adding Project Knowledge.

Applications often cannot be understood only from routes and DOM elements.

Business requirements matter.

Product documentation matters.

Rules matter.

Universal Bug Hunter can now ingest project documentation and retrieve relevant context for AI-assisted exploration.

But there is an important security boundary:

Project documentation is context, not permission.

A document cannot:

expand allowed routes,
enable destructive actions,
override safety policy,
introduce credentials,
or bypass human approval.

The system treats retrieved project knowledge as untrusted reference material.

That distinction is especially important when AI is involved.

API Intelligence moved beyond basic smoke tests

The earlier version supported simple API smoke scenarios.

That area has expanded significantly.

The platform now has a stronger API testing model around:

OpenAPI contracts,
request and response validation,
parameters,
authentication profiles,
extracted variables,
request chaining,
assertions,
negative cases,
and boundary testing.

The intention is to keep browser and API testing connected to the same product quality model rather than building a separate API-testing product inside the project.

Test Impact Analysis and CI/CD integration

Running every test for every code change does not always make sense.

Universal Bug Hunter now supports Test Impact Analysis.

Conceptually:

Git change
→ changed files
→ affected application areas
→ affected tests
→ recommended test set

A critical design rule here is uncertainty handling.

If the platform cannot confidently determine which tests are affected, it must not silently select zero tests.

Instead, it falls back to a defined policy such as:

smoke
critical
all

smoke is the default fallback, but the policy can also be configured to use critical or all.

The important rule is that uncertainty must not silently produce an empty test set.

This makes the system usable in CI without creating false confidence.

Quality Intelligence Dashboard

The project now tracks quality across runs instead of looking only at one execution.

The Quality area includes concepts such as:

Quality Issues
Regressions
Reliability
Coverage
Performance

The dashboard intentionally avoids vanity metrics.

If the system cannot calculate a trustworthy percentage, I prefer showing counts instead of inventing a percentage.

Similarly:

Regression not evaluated

is represented as:

—

not:

Those details sound small, but they matter when people start making engineering decisions from dashboards.

Performance Intelligence

Performance testing has also been integrated into the same workflow.

The platform can execute performance measurements and compare them against approved baselines.

The important part is that performance semantics remain separate from functional execution.

A run can be:

functionally successful

while performance regression status is:

failed

or:

not evaluated

These are not the same outcome.

The platform keeps:

execution status
performance verdict
release gate

as separate concepts.

Another safety rule is that performance measurement does not re-run destructive browser workflows.

Repeated API measurements are constrained to safe, read-only request patterns.

The enterprise layer

One of the largest recent changes was Phase 35: the team and enterprise platform.

Universal Bug Hunter now has an organization-based tenant model.

The structure is roughly:

User
→ Organization Membership
→ Team / Project Grants
→ Capability-based permissions

A user can belong to multiple organizations.

Teams belong to one organization.

A normal member does not automatically receive access to every project.

Authorization is evaluated through a central access-control service.

I intentionally avoided spreading checks such as:

if (user.role === "admin")

through route handlers.

Roles are labels over capabilities.

The permission engine remains the authority.

Persistent collaborative triage

Quality triage is now shared and persistent.

When one authorized team member classifies a detected signal, that decision is stored as platform state.

The supported classifications are:

expected
ignored
observation
quality_issue

The decision includes revision tracking so concurrent edits can produce a conflict instead of silently overwriting another user's work.

Confirmed quality_issue classifications can then appear in the Quality Issues view without changing the original run result.

That separation is intentional.

Platform audit log

Enterprise operations also need accountability.

The platform now has an append-only application-level audit log for governance events such as:

membership changes,
teams,
project grants,
invitations,
triage,
service accounts,
API tokens,
OIDC configuration,
and other administrative operations.

The audit log is tenant-scoped and redacted.

I also try to be precise about what it is not.

It is not currently a cryptographically immutable WORM audit system.

Service accounts and API tokens

CI/CD workflows should not depend on human accounts.

Universal Bug Hunter now supports service accounts with scoped Bearer tokens.

The security model is:

service-account permissions
∩
token scopes
=
effective token authority

A token can reduce authority.

It cannot increase it.

Raw tokens are shown once.

Only a hash is stored.

Revocation and expiry are checked from the database.

An invalid Bearer token also does not silently fall back to a valid browser cookie.

Machine identity and human identity remain separate.

OIDC SSO

OIDC support was added as an enterprise SSO extension point.

The flow includes:

authorization code
PKCE S256
state
nonce
JWKS signature validation
issuer validation
local durable session

One of the most important rules is:

Identity provider claims authenticate the user. They do not grant Bug Hunter permissions.

If an IdP sends something like:

{
  "roles": ["admin"]
}

that does not make the user an administrator inside Universal Bug Hunter.

Authorization remains local and capability-based.

Account linking is also based on trusted OIDC identity:

issuer + subject

not simply matching an email address.

Production migration safety

After building the enterprise control plane, the next question became:

Can this system actually be operated safely in production?

That started Phase 36.

Database upgrades are now treated as an operational contract.

The platform schema is currently v9.

The migration system includes:

preflight
→ backup acknowledgement
→ migration lock
→ durable migration marker
→ stepwise transaction
→ schema version update
→ startup

A production database newer than the binary is rejected.

No downgrade is attempted.

A failed migration cannot falsely advance the schema version.

Only one migrator is allowed at a time.

If a migration is interrupted, the next startup fails closed instead of pretending everything is healthy.

Production backup and restore

The latest production-hardening work has focused on backup, restore and disaster recovery.

This implementation is currently under review before being merged into the main branch.

The first production model is intentionally conservative:

Backup and restore are offline maintenance operations.

I chose this instead of pretending the current SQLite architecture supports online distributed snapshots.

A backup includes:

platform database
project data
run artifacts
manifest
checksums

SQLite is copied using the SQLite backup API rather than copying a live WAL database file.

Included backup files are covered by SHA-256 integrity metadata, together with a deterministic artifact-tree digest.

The backup format is versioned independently from the platform schema.

Restore is also a security operation

A restore is not just copying old data back.

It can also restore old credential state.

Imagine this sequence:

T0: backup
T1: API token revoked
T2: restore T0

Without additional protection, the old token could become valid again.

Universal Bug Hunter therefore applies a post-restore credential safety policy.

By default:

human sessions      → invalidated
OIDC transactions   → invalidated
pending invitations → revoked
API tokens          → invalidated

API tokens can only be preserved through an explicit high-risk operator override.

Human sessions are always invalidated.

Crash-safe restore boundary

Database and artifact directories cannot be atomically replaced together across all environments.

Instead of pretending otherwise, restore uses a durable state marker.

The flow looks roughly like:

validate backup
→ verify integrity
→ stage database
→ stage artifacts
→ apply credential safety
→ write restore marker
→ rotate database
→ rotate projects
→ finalize
→ clear marker

If the process crashes after the database is swapped but before project artifacts are swapped, the marker remains.

On the next startup:

restore_interrupted

blocks normal API startup.

The server does not listen until an operator resolves the recovery state.

That is much safer than starting with a database from one recovery point and artifacts from another.

Integrity is not authenticity

This was another important distinction.

The backup uses SHA-256 checksums.

That gives integrity checking against corruption or mismatched files.

It does not mean the backup is cryptographically authenticated.

If an attacker can modify:

payload
+
manifest
+
checksums

they can potentially produce a different internally consistent backup.

Signed backups are not part of the current format.

I prefer documenting that limitation rather than implying stronger security than the system actually provides.

Backups are still sensitive data

Another thing I wanted to make explicit is that a backup is not equivalent to a secret-free archive.

Plaintext provider secrets and environment secret values are excluded, but the platform database can still contain security-sensitive material such as:

password hashes
token hashes or digests
identity metadata
session metadata
encrypted application credential material
customer and project data

That means backup files should still be protected with restrictive filesystem permissions and treated as sensitive operational data.

The current implementation uses restrictive permissions where the platform supports them.

Current production topology

Another thing I wanted to make explicit is the supported deployment topology.

Today the honest supported model is:

1 API writer instance
+ optional stateless web instances
+ SQLite platform database
+ shared project/artifact storage
+ reverse proxy / TLS

The project does not currently claim:

active/active API HA
multi-writer SQLite
distributed job execution

Those may be future directions, but they are not things I want to pretend already work.

Where the project is now

Universal Bug Hunter has moved a long way from the version I originally shared.

The platform now covers several layers:

Application discovery
Test planning
Browser testing
API testing
Visual testing
Accessibility
Quality triage
Regression tracking
Reliability
Performance
CI impact analysis
Project knowledge
Teams and RBAC
Audit
Service accounts
OIDC
Migration safety
Backup and restore

Some of the latest backup and restore work is still going through final review before merge, but the broader architecture is already clear.

The design principle has stayed surprisingly consistent:

Automation should reduce uncertainty, not hide it.

If the system is unsure which tests are affected, it should say so.

If a regression was not evaluated, it should not show zero.

If a backup is not authenticated, it should not claim authenticity.

If the architecture is single-writer, it should not advertise high availability.

If AI generates something, that does not mean the system should trust or execute it automatically.

What comes next

The current production-hardening roadmap continues with:

production configuration validation
health and readiness hardening
operational logging and observability
reference production deployment
multi-instance safety review
operator recovery drills

The platform already has basic health and readiness endpoints.

The next step is to make their production semantics more explicit and useful for operators and orchestrators.

A canonical production deployment path is also still planned.

Local deployment already exists, but I want one clearly documented production reference stack instead of treating development deployment as production guidance.

There are also features I am intentionally not rushing into yet:

SCIM
SAML
billing/licensing
multi-IdP
PostgreSQL migration
full active/active HA

I would rather finish the operational foundation properly before adding more enterprise surface area.

Final thought

Building this project has changed how I think about testing infrastructure.

The difficult part is rarely:

Can Playwright click this button?

The more interesting questions are:

Can I trust this result?

Can another engineer reproduce it?

What evidence supports the conclusion?

What happens when two people change the same state?

What happens when the database upgrade crashes?

What happens when a backup restores old credentials?

What happens when the system itself is uncertain?

Those questions are what pushed Universal Bug Hunter from a collection of automated tests toward a broader Quality Intelligence platform.

The project is still evolving, but the direction is much clearer now.

If you work in QA, DevOps, platform engineering or test infrastructure, I would be interested in feedback on one question in particular:

What would a self-hosted quality platform need to replace the collection of disconnected testing dashboards your team uses today?

I Built Bug Hunter: A Self-Hosted Full-Stack Testing Tool for Web Apps and APIs

Sandro — Wed, 15 Jul 2026 13:24:52 +0000

Modern web application failures rarely happen in one isolated place.

A user clicks a button, the frontend sends an API request, the backend returns an unexpected response, and the interface remains stuck in a loading state.

A health check may still be green. A unit test may still pass. The visible symptom may appear in the browser, while the actual cause is somewhere between the frontend, API, runtime environment, and application configuration.

I built Universal Bug Hunter to make those failures easier to detect, investigate, reproduce, and document.

It is a self-hosted testing tool that combines:

browser testing with Playwright and Chromium,
direct API smoke testing,
OpenAPI discovery,
optional AI-assisted test proposal generation,
deterministic bug detectors,
runtime evidence collection,
finding reproduction,
static analysis integrations,
and HTML/JSON reporting.

The goal is not to replace QA engineers, security testers, code review, or existing test suites.

The goal is more practical:

Execute realistic application flows, preserve useful evidence, and make failures easier to understand and reproduce.

Why I built it

Many automated checks answer only one narrow question:

Did the endpoint return HTTP 200?

That is useful, but it does not tell you what happened after the page loaded.

It does not tell you whether:

the browser logged a JavaScript error,
an API call returned HTTP 500,
the interface became stuck,
a click produced no visible state change,
the page overflowed horizontally,
a loading indicator never disappeared,
a test failed because of the application,
or the testing engine itself failed operationally.

I wanted one workflow that could test a web application from the outside, like a real user, while still collecting enough technical context for a developer or operator to investigate the result.

That idea became Universal Bug Hunter.

What Universal Bug Hunter does

The current workflow is:

Create project
→ Discover routes
→ Review and approve routes
→ Generate optional AI test proposals
→ Review and approve proposals
→ Compile proposals into scenarios
→ Execute browser and API scenarios
→ Detect findings
→ Reproduce supported findings
→ Generate HTML and JSON reports

The approval steps are intentional.

Discovery does not automatically execute everything it finds.

AI does not approve or run its own proposals.

Compilation creates scenario files, but it does not automatically launch the browser.

The operator remains in control of what is allowed to run.

Browser testing with Playwright

Universal Bug Hunter uses Chromium through Playwright to test an application as a user would experience it.

Browser scenarios can navigate through the application, interact with visible elements, verify UI state, and capture screenshots.

A simple scenario can look like this:

steps:
  - navigate:
      path: /login

  - waitForVisible:
      target:
        label: Username

  - captureScreenshot:
      name: login-page

During execution, Bug Hunter can collect:

browser console messages,
uncaught page errors,
failed network requests,
HTTP 4xx and 5xx responses,
screenshots,
DOM snapshots,
navigation information,
and other runtime evidence.

The current deterministic detector set includes checks such as:

console-error
page-error
failed-request
http-error
blank-page
horizontal-overflow
stuck-loader
no-state-change

These detectors do not depend on an LLM. They evaluate collected evidence using predictable rules.

Direct API testing

Browser testing only covers backend requests that are actually triggered by the frontend.

To improve backend coverage, I added direct HTTP scenarios.

For example:

steps:
  - httpGet:
      path: /ready
      target: api

  - assertHttpStatus:
      status: 200

A POST scenario can look like this:

steps:
  - httpPost:
      path: /api/auth/login
      target: api
      jsonBody: {}

  - assertHttpStatus:
      status: 400

Browser scenarios and HTTP-only scenarios use separate execution paths.

A composite orchestrator can still run both types as part of the same batch.

This keeps browser execution and direct API execution clearly separated while allowing them to contribute to the same project-level test workflow.

OpenAPI discovery and API smoke generation

For applications that expose an OpenAPI specification, Bug Hunter can import the specification and build an inventory of API operations.

The basic flow is:

OpenAPI specification
→ operation discovery
→ generated API smoke scenarios
→ scenario approval
→ execution
→ report

The current generator supports basic GET and POST smoke coverage.

For example, an imported API specification can produce scenarios for:

GET /health
GET /ready
POST /api/auth/login

This is intentionally conservative.

The current version does not yet attempt to generate complex destructive requests automatically.

Support for OpenAPI parameters, authentication profiles, request body generation, response schema validation, and negative API testing is planned for future versions.

AI-assisted exploration with human approval

AI exploration is optional.

When enabled, an LLM receives a controlled representation of:

approved routes,
discovered interactions,
existing scenarios,
and detected coverage gaps.

It can propose read-only test scenarios using a restricted action set such as:

navigate,
click,
assert visible,
assert URL,
capture screenshot.

Every proposal passes through a deterministic safety pipeline.

A proposal must:

target an approved route,
use only permitted actions,
remain read-only,
stay within configured step limits,
avoid credentials and sensitive values,
and conform to a strict schema.

Passing this validation does not mean the proposal is automatically approved.

The workflow remains:

AI-generated
≠ safe by default

Safety accepted
≠ human approved

Human approved
≠ automatically executed

The operator reviews each accepted proposal and decides whether it should be approved, rejected, or compiled into a scenario.

Findings, evidence, and reproduction

A useful bug report should not only say:

A request failed.

It should help answer:

Which scenario triggered the problem?
Which route was active?
Which action happened before the failure?
What did the browser log?
Which request failed?
Was the behavior reproduced?
Is there a screenshot?
Is there a DOM snapshot?
Is the finding eligible for reporting?

Bug Hunter stores evidence separately from project configuration.

A typical run can contain:

batch-report.json
batch-report.html
batch-state.json
runs/
  run-summary.json
  findings.json
  evidence/
  screenshots/

When supported, a finding can be replayed in a fresh browser session.

This helps distinguish a reproducible application issue from one-time browser or environment noise.

Execution success is not the same as a passing test result

This distinction became one of the most important parts of the system.

A job can complete successfully from an infrastructure perspective while the tested application still produces findings.

For example:

Execution job: completed
Scenarios executed: 6
Passed: 3
With findings: 3
Operational failures: 0

This means:

the execution engine completed,
all six scenarios were executed,
three scenarios produced no findings,
three scenarios produced detector findings,
and the runner itself did not fail operationally.

That is different from:

Operational failures: 3

An operational failure may indicate:

the browser could not start,
navigation timed out,
a required element could not be found,
the scenario could not complete,
or the runtime environment failed.

I am continuing to improve this distinction in the operator dashboard so that Completed, Passed, With findings, and Operational failure cannot be confused with each other.

Testing localhost applications from Docker

One of my main requirements was testing applications before they are publicly deployed.

Bug Hunter can run locally through Docker while testing another application that is running:

directly on the Windows host,
inside another Docker Compose service,
on a private development address,
or on a regular staging URL.

From inside a container:

localhost

refers to that container itself.

For an application running directly on the Windows host, Bug Hunter uses:

http://host.docker.internal:3000

A local target can be configured like this:

target:
  baseUrl: http://host.docker.internal:3000
  environment: local
  allowedDomains:
    - host.docker.internal

A full-stack project can define separate frontend and API targets:

project:
  type: fullstack

targets:
  frontend:
    baseUrl: http://host.docker.internal:3000

  api:
    baseUrl: http://host.docker.internal:8787
    healthPath: /ready

Private and loopback targets are not enabled globally.

They must be explicitly allowed through the local environment and network policy configuration.

The same allowlist logic is applied to:

browser navigation,
redirects,
direct HTTP scenarios,
and OpenAPI retrieval.

This preserves the SSRF protection while still allowing intentional localhost testing.

Static analysis integrations

Bug Hunter also includes a static analysis layer with provider adapters for:

Semgrep for SAST,
Trivy for dependency and filesystem analysis.

The static analysis command writes normalized results into the project workspace.

If a configured tool is not installed, the pipeline reports that the provider is unavailable instead of crashing the entire workflow.

This is still an early integration.

The goal is not to replace dedicated Semgrep or Trivy workflows.

The longer-term goal is to present dynamic browser findings, API findings, dependency findings, and static analysis results within the same project context.

Architecture

Universal Bug Hunter is a TypeScript monorepo built with:

Node.js 22
TypeScript
pnpm workspaces
Fastify
Next.js
Playwright
Chromium
TanStack Query
Zod
Docker Compose
OpenAI as an optional exploration provider
Semgrep
Trivy
HTML and JSON reporters

The system is divided into focused packages for:

core domain models,
configuration and validation,
browser execution,
direct HTTP execution,
route discovery,
OpenAPI discovery,
AI exploration,
evidence storage,
deterministic detectors,
finding reproduction,
scenario execution,
reporting,
API services,
CLI commands,
and the web operator interface.

I intentionally avoided placing browser control, filesystem access, AI calls, HTTP testing, reporting, and security policy inside one large service.

Testing systems become difficult to maintain when every responsibility is tightly coupled to the runner.

The operator workflow

The web interface follows the project lifecycle:

Overview
→ Discovery
→ Exploration
→ Proposals
→ Scenarios
→ Runs

The operator can:

create a project,
start route discovery,
approve or reject discovered routes,
start optional AI exploration,
review proposals,
approve or reject proposals,
compile approved proposals,
run all approved scenarios,
run selected scenarios,
inspect execution history,
review findings,
and download HTML or JSON reports.

The interface is deliberately operator-focused.

It does not expose target URL changes, browser configuration, credentials, or reporting configuration during scenario execution.

Those values remain controlled by the project manifest and backend policy.

Local verification

I tested the current full-stack workflow in two different ways.

Host execution

The first test executed directly from the host against the local web UI and API:

Selected: 6
Passed: 6
Operational failures: 0
Exit code: 0

The batch contained:

three browser smoke scenarios,
three direct API smoke scenarios.

Docker-to-host execution

The second test ran from the Docker API container against the Windows host through host.docker.internal:

Selected: 6
Executed: 6
Passed: 3
With findings: 3
Operational failures: 0
Exit code: 1

The three API scenarios passed.

The three browser scenarios completed operationally but produced console or network findings.

This demonstrated an important behavior:

The execution engine can complete correctly while the tested application still produces reportable findings.

An exit code of 1 does not necessarily mean the testing infrastructure crashed.

It can mean that relevant findings were detected.

Current limitations

Universal Bug Hunter is still evolving.

The current version has several known limitations:

job state is stored in memory and is lost after an API restart,
authentication currently supports one local admin account,
the execution queue runs inside one Node.js process,
API smoke generation has limited OpenAPI parameter and body support,
HTTP-only scenarios do not yet have the same reproduction flow as browser scenarios,
backend logs and distributed traces are not yet correlated with browser requests,
static analysis integrations are still basic,
artifact retention and cleanup need stronger lifecycle controls,
concurrency and browser resource limits need further hardening,
and deployment is currently focused on local self-hosting.

I prefer being clear about these limitations.

An automated testing tool should not create false confidence.

A successful run does not prove that an application has no bugs.

It only proves that the selected scenarios completed under the tested conditions without producing findings recognized by the enabled detectors.

What I am improving next

The next areas I am working on include:

job concurrency and queue limits,
browser session limits,
artifact retention and cleanup,
structured operational logging,
better runtime status visibility,
OpenAPI parameter support,
request body generation,
authentication profiles for API scenarios,
negative API test generation,
response schema assertions,
backend log and trace correlation,
and clearer result summaries in the operator dashboard.

One longer-term goal is to correlate the complete path:

Browser action
→ frontend state
→ API request
→ backend response
→ log or trace
→ one combined finding

That would make Bug Hunter more useful than a collection of disconnected browser, API, and static checks.

Why this project matters to me

I built Universal Bug Hunter as a practical QA automation, DevOps, and DevSecOps project.

It combines several areas I regularly work with:

browser automation,
API testing,
TypeScript,
Docker,
application security,
evidence collection,
reporting,
CI/CD design,
and system architecture.

The most interesting part was not simply making Playwright click through a page.

The harder questions were:

What should the system be allowed to execute?
How do you prevent AI proposals from bypassing safety rules?
How do you distinguish a product bug from an environment problem?
How do you preserve useful evidence without leaking secrets?
How do you reproduce findings deterministically?
How do you test localhost applications safely from Docker?
How do you explain that a job completed even when tests found problems?

Those questions shaped the architecture more than the UI itself.

Current status

Universal Bug Hunter currently runs as a local, self-hosted testing environment.

I am testing it against local applications before considering a public deployment.

The complete current flow works from:

URL discovery
→ route approval
→ optional AI exploration
→ proposal review
→ scenario compilation
→ browser and API execution
→ findings
→ report download

I am sharing the project to get feedback from:

QA engineers,
developers,
DevOps engineers,
platform engineers,
and security practitioners.

I would especially appreciate feedback on:

whether the workflow is understandable,
whether findings contain enough evidence,
whether operational failures and application findings are clearly separated,
which API checks would be most useful,
whether the approval workflow feels too strict or appropriately safe,
and what would make the tool useful in a real development workflow.

Universal Bug Hunter is still a work in progress, but the core idea is already clear:

Find problems through realistic application flows, preserve the evidence, and make the result easier to understand and reproduce.

I Built PentestScan: A Simple Web & API Security Scanner for Developers and Small Teams

Sandro — Mon, 18 May 2026 06:30:58 +0000

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:

https://pentestscan.app/

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.