PentestOPS

Context

Engineering thesis project, Computer Systems Engineering (ISI), École Supérieure en Informatique 08 Mai 1945 (ESI-SBA), academic year 2025–2026. Supervised by Manel Baba-Ahmed and Islem Meghnine.

PentestOPS is the practical counterpart to a companion master's thesis that studies why traditional penetration testing methodologies struggle with cloud-native, API-centric and continuously changing infrastructures.

The problem

The companion thesis identifies five structural limits in current pentesting practice:

• Tool fragmentation across heterogeneous data formats.
• Manual chaining of workflows between lifecycle phases.
• No unifying orchestration mechanism.
• Limited scalability on large or distributed infrastructures.
• Static, point-in-time assessments that do not fit dynamic cloud environments.

A review of PTES, OSSTMM, NIST SP 800-115 and OWASP WSTG found that they define testing phases well but offer limited support for automation, orchestration or continuous operation. Existing tools split the same way: automation-oriented tools such as ReconFTW or the ProjectDiscovery ecosystem lack platform-level management, while management-oriented platforms such as Faraday, DefectDojo or Reconmap lack native workflow automation.

System architecture

A layered web application: a Flask backend, a PostgreSQL database accessed through SQLAlchemy, and a stateless REST API consumed by an HTML5, Bootstrap and JavaScript (ES6) frontend. Authentication uses JWT. Four actors are modelled: Pentest Admin, Pentester, Client, and an automated System actor that handles workflow orchestration and background processing.

Security is enforced in three nested layers: JWT authentication outermost, role-based access control in the middle, and project-level data isolation innermost, enforced through foreign-key constraints and middleware checks.

Reconnaissance pipeline

Eight stages run one after another, each feeding the next without manual handoff. The engine orchestrates established tools (subfinder, assetfinder, httpx, naabu, nmap, nuclei, katana, ffuf) and normalizes their different outputs into one data model, instead of reimplementing scanning logic.

Technical contributions

• Modular architecture. One Flask application with separate layers for API routes, authentication, database models, scanning logic and shared helpers.
• Stateless REST API. Supports concurrent projects and users and decouples the frontend from the automation engine.
• Role-based access control. Permissions scoped by role and by project, so administrators, testers and clients see different data on the same engagement.
• Workflow automation. Scans run in the background with per-stage progress tracking, so long scans do not block the platform.
• Vulnerability management. Findings with severity classification, evidence attachment and an open-to-remediated workflow.
• Structured reporting. A guided report builder that pulls findings into PDF reports with an executive summary.
• Run archive. Timestamps, durations and raw tool output are kept for every past execution.

Design decisions

• Flask keeps the codebase simple to run while allowing a clear separation of concerns.
• PostgreSQL with SQLAlchemy instead of a document store, because project isolation and RBAC depend on relational foreign keys that are easier to enforce and audit.
• JWT instead of sessions for statelessness and horizontal scalability.
• Orchestrate trusted tools instead of rebuilding them, prioritizing integration over reinvention.

Challenges and lessons

The central difficulty was integrating third-party security tools that each emit output in a different format and at a different level of structure. Letting the system run multi-stage pipelines unattended had to be reconciled with strict role-based access and project isolation.

Reliability under tool failure was handled with soft-fail isolation, so one failing tool does not halt a pipeline, and atomic workflow commits, so partial results are never shown as complete. The main lesson: orchestrating external security tools is as much a governance and failure-isolation problem as an automation problem.

Outcome and scope

The work produced a working system, not performance benchmarks, so its outcomes are architectural: automated recon without manual transitions, reproducible runs from the archive, a modular structure that can absorb more tools, and a layered security model.

Future directions

• LLM-assisted generation of executive summaries and finding narratives from scan results.
• An exploitation module integrating Metasploit to suggest and validate exploitation paths.
• Distributed, Kubernetes-based scanning for parallel pipeline execution.
• WebSocket push updates in place of polling for live, stage-by-stage visibility.
• Further research lines: autonomous reconnaissance, intelligent vulnerability prioritization, and SIEM/SOAR integration.