I often get asked about pentesting and code review methodologies. It seems like people are hoping for a secret sauce that will make it rain bugs. I wish I could give them that.

The reality is that the methodology used during a test or review depends a lot on your goals and the target. You should not use the same strategy for all tests and all targets. And the methodology is dictated by your strategy.

If your target has been pentested every year for the past five years, you don't want to spend too much time on the basics.

If your target is going through its first test, you probably want to spend more time on the basics.

If you are trying to demonstrate impact, you may spend more time going down a few rabbit holes than if you want to provide a general security posture of the application.

In this blog post, I will try to illustrate what I mean...

A Simplified View

Let's say we have one application with many features, or perhaps multiple applications. It's pretty much the same concept for this discussion—basically, the number of things we have to test. We also have a “depth” indicator, which is completely arbitrary, just to demonstrate my point! It looks something like this:

This is what we are going to apply our testing to.

Vulnerabilities

Now, we also have vulnerabilities. Some have a small impact (small bugs), and some have a big impact (big bugs). Some are easy to find (shallow depth), while others are harder to find (deeper depth). It looks something like this:

Ideally, you should be able to find all of these bugs.

Time Constraints

Unfortunately, penetration testing and code review are usually time-bound exercises. Bug bounties are not so constrained, which is why they sometimes provide better results if you are lucky enough to have very resilient researchers on your program.

Checklist Methodology and Uniform Coverage

Many large companies have a dedicated checklist or methodology to follow. This is the kind of result you usually expect:

This is far from perfect, but at least you are covering a minimum level of security across assets and functionalities. The depth really depends on the quality of the methodology or checklist. You may get something like this:

The key point is this uniformity across all assets or functionalities. It is most likely what you want if you are buying your first pentest—a broader view of your security posture.

Demonstrating Impact

In some cases, you may want to demonstrate impact or test critical parts of the application or assets, so you may opt for something like this:

This is also often what you get when you have really good or very specialized people looking at your application(s). It is not necessarily better; it is just another strategy for testing.

Specialized Testing

You can also get testers or reviewers (especially for bug bounties) who are really good at one or a few specific things, and they will test those areas on all your assets or in all functionalities, leveraging those aspects of your application.

Deep Bugs

Some people only test for deep bugs and don't want to test for simpler issues. There are multiple reasons for this: often a bigger impact, less chance of duplicates in bug bounties, or a longer exploit lifespan for security researchers:

None of these strategies is necessarily better or worse than the others. It mostly depends on what you are testing and why you are testing.

Conclusion

Ultimately, choosing the right strategies comes down to aligning your goals with the nature of the target. Whether you aim for breadth to gain a general security overview or depth to demonstrate significant impact, your approach should be context-driven. Understanding your assets, the application's maturity, and your specific objectives will help ensure you get the most value out of your testing efforts.