Editors note and the use of AI

I used ChatGPT to assist with formatting, spelling, sentence structure, and the creation of visualizations designed to make the concepts easier to understand. I also used Claude Code to review our existing repository of hundreds of pentesting methodologies and help inform the article’s structure and graphics.

The ideas, conclusions, and final editorial decisions remain my own.

Enjoy the read.

Best regards,
Chris Dale

How we turn “hack this thing” into a repeatable, compounding technique, one asset at a time with the MVP.

I am pleased to present this article, which explores practical and adaptable approaches to pentesting. Its focus is on methodologies that help testers think clearly, prioritize effectively, and demonstrate meaningful risk, rather than relying solely on broad frameworks or exhaustive checklists.

Established resources such as PTES, OSSTMM, the OWASP Web Security Testing Guide, and ASVS remain valuable references, however they can be difficult to apply efficiently in every engagement, especially when testers need focused guidance for a specific target or technology. This article proposes a more concise and reusable approach that is intended to complement, rather than replace, those resources.

The problem with “just pentest it”

Every penetration test starts with the same quiet anxiety: did we cover everything? Two testers pointed at the same target will explore it differently, chase different rabbit holes, and document their findings in different ways. The hard-won knowledge of exactly how to attack a Keycloak instance, an LDAP endpoint, or an S3 bucket often lives in senior testers’ heads and disappears between engagements.

We wanted the opposite: testing that is consistent, teachable, and compounding, where every engagement makes the next one sharper. That is what the MVP is.

What is an MVP?

MVP means Most Valuable Pentest, or, if you prefer, Minimum Viable Pentest. It is the smallest reusable unit for attacking a single asset. It is not a tutorial or a report. It is a focused, timeless playbook for one specific target, such as Nginx, DNS, OAuth, a login flow, or WordPress.

The key idea is that an MVP is scoped to a technology mix, not an engagement. That single design decision is what makes the entire system composable, it is composed from smaller parts determined by the mix of technology. For example, a WordPress assessment might combine all of the below MVP methodologies:

• WordPress
• Nginx
• OAuth
• Postgres
• Login functionality
• Password reset functionality
• Search functionality
• REST API

These MVPs are written once and reused across every new assessment in the future with similar technology mix.

The anatomy of an MVP: an inverted pyramid

Every MVP, regardless of what it targets, follows the same six sections. They are deliberately ordered as an upside down pyramid, moving from broad and sometimes expensive techniques down to specific and creative testing, with automation via tools at the end as a safety net. The methodology can be visualized in different ways (for example here: https://riversecurity.eu/penetration-testing-methodology/), but below shows the general idea of what a MVP is comprised of.

Read the graphic as a flow, not a checklist, and not necessarily as a waterfall that always moves downward:

1. Discovery
   What attack surface exists, and how do I find this asset? This is often an expensive and broad step. Crucially, it is also what feeds the recursion, which we will return to below.
2. Fuzzing
   Actively probe the surface you found, or make the asset fail in ways that reveal even more surface.
3. Test Cases & Hypotheses
   Once you understand the technology, apply the specific, known ways to attack it.
4. Business Process & Logic Flaws
   Escalate to creative, context-specific reasoning. This is where you find the flaws that scanners are structurally unable to detect.
5. Frameworks & Resources
   When your own attacks stall, draw on community knowledge, established methodologies, and standards. For example in testing a password reset, I like to draw on Troy Hunt’s password reset guidelines.
6. Tools
   Use automation as a fallback, but not only as a final step. If manual testing does not uncover a vulnerability, tooling can help identify what you may have missed. In practice, you will often use tools during discovery as well. The visual structure is a guide, not a rigid sequence, so do not let the abstraction slow you down or limit your judgment.

Each step consumes what the previous one produced. You cannot fuzz an attack surface you have not discovered. The heavier, more creative, and more automated techniques come later. It is more like a ladder, not a to-do list.

MVPs are recursive – One feeds into another

A target is never just one MVP. Discovery reveals new assets, and each asset becomes another node in the testing process with its own MVP pyramid.

For example, finding a web application leads you to the Web Application MVP. If the application runs Django, you add the Django MVP. If it exposes a password reset form, you add the Password Reset MVP. The test expands as each layer reveals the next.

An open port may reveal a web server. The web server may reveal an application, which in turn exposes frameworks, libraries, middleware, datastores, protocols, cloud services, and user-facing features. Each component has its own playbook, allowing the tester to move recursively through the target one asset at a time.

A penetration test is not the execution of one large methodology. It is the recursive traversal of a tree of assets, applying the same six-step technique at every node. Each node’s Discovery phase reveals new assets and creates the branches below it.

What the tester decides to include in-scope of this recursion tree might be obvious to them, but not necessarily to the customer. It is important to be transparent to all parties regarding what was considered in-scope and what was out-of-scope.

Composition: assembling a test from parts

Because MVPs are scoped to assets and designed for reuse, testing a real target becomes an act of composition. You do not write a bespoke guide for testing a specific WordPress instance from scratch. You assemble the test from the MVPs of its individual parts.

Write the Login MVP once, and it strengthens every application you test afterward. Improve the Nginx MVP after one engagement, and every future Nginx assessment benefits. The knowledge compounds instead of disappearing.

By combining different MVPs, you can assess an application using knowledge that compounds across technologies, components, and features. For example:

• The PHP MVP teaches you about concepts such as magic hashes and how they may support certain attacks.
• The Web Application MVP provides fuzzing and discovery techniques for identifying attack surface.
• The Apache MVP explains how insecure URL rewrite rules may be exploited.
• The WordPress MVP highlights commonly exposed functionality, such as the unauthenticated REST API and the login page typically located at wp-login.php.
• Feature-specific MVPs help you identify which attacks are most likely to succeed against particular application features.
• The MySQL MVP helps you understand the intricacies of attacking a MySQL database.

The name of the methodology matters

The discipline is in the name. An MVP is deliberately focused on what is most valuable, or minimally viable, to test. Its purpose is to help a tester achieve 80% of the value with 20% of the effort by concentrating on the areas most likely to matter in a given technology mix.

It can also be described as a Minimum Viable Pentest because, like many MVP methodologies, it condenses the absolute minimum a tester should consider before drawing conclusions or moving into deeper research.

MVPs are precise bullet points that define what to achieve, assuming the reader already understands the underlying technology. They are not how-to guides. Background material and tutorials belong in separate sections.

The goal of an MVP is to provide techniques that help demonstrate risk within a specific area. It should not become tool-of-the-week trivia or an endless checklist covering every possible scenario.

The broader methodology is designed to be timeless. It should be applicable to any target, at any time, while continuing to evolve as new techniques are discovered.

This restraint is what keeps the library usable at scale: hundreds of focused, skimmable playbooks that testers can combine in the field, rather than a small number of sprawling documents that nobody reads.

The loop closes after every engagement. When a tester discovers something new, the technique should be added back to the relevant asset’s MVP so that the playbook becomes sharper with every test.

The payoff

• Consistency: two testers converge on the same coverage, because they’re walking the same pyramids over the same tree.
• Onboarding: juniors inherit senior technique the moment they open the right stack of MVPs.
• Coverage you can see: gaps become obvious (a stubbed or missing MVP is a visible hole, not a silent one).
• Institutional memory: knowledge accumulates in the library instead of leaving with people.

Closing

A pentest doesn’t have to be a bespoke act of heroism every time. Break it into the smallest reusable pieces — one asset, one pyramid — let discovery drive the recursion, and compose the whole from the parts. The result is testing that’s consistent today and sharper tomorrow: a Minimum Viable Pentest that, repeated across a target’s every layer, adds up to a maximally thorough one.