How My Audit Methodology Changed When the Stakes Became Real

The difference between finding vulnerabilities in bug bounty programs and finding them in a product someone’s business depends on

There’s a version of security testing that optimises for impact per hour. Find the highest-severity vulnerability in the shortest time, write it up cleanly, collect the reward. That’s bug bounty hunting at its core, and it produces a particular kind of skill set.

Then someone hired me to audit their product before a Series A close.

The moment I understood that a missed finding wouldn’t just mean no reward — it might mean a founder’s company gets compromised six months after I said it was fine — my entire approach changed.

What follows is the methodology I’ve developed for structured security audits on early-stage SaaS products. It’s not the fastest approach. It’s the most thorough one I’ve been able to build.

Phase 1: Business Context Before Technical Testing

I spend the first two to three hours of every engagement not touching the application at all. Instead, I’m building a product-specific threat model.

This phase involves answering four questions:

1. What data does this application handle, and how sensitive is each category?
2. What actions can this application perform that, if done without authorisation, would cause real business damage?
3. Who are the different user roles and what should each one be able to access?
4. What are the third-party integrations and what trust boundaries do they create?

The answers to these questions determine where I spend my testing time. A product handling healthcare-adjacent data has a different risk profile from a developer tooling product. A multi-tenant B2B platform with enterprise customers has a different testing priority than a consumer application with no sensitive personal data.

The threat model I build in Phase 1 becomes the scope document for everything that follows. It’s also a deliverable I share with the client — most founders have never seen their product described in terms of its threat surface before.

Phase 2: Automated Reconnaissance With Manual Verification

I run automated tools. Automated tools are genuinely useful and I’d be wasting time not using them. But the discipline is in what you do with the output.

The process:

1. Subdomain enumeration to map the full external attack surface — not just the primary domain, but every subdomain and associated service.
2. Port scanning and service fingerprinting to understand what’s running and what’s exposed.
3. Automated DAST scanning against the application, recording every finding without dismissing anything.
4. Manual verification of every finding from the automated scan. Each one is either a confirmed vulnerability or a false positive.
5. Pattern analysis: three findings of the same type across different parts of the codebase isn’t three bugs. It’s a systemic architectural issue, and there are probably more I haven’t found yet.

Automated tools will find roughly 30–40% of what’s in a thorough manual audit of the same system. The percentage varies significantly depending on the application type — it’s higher for applications with lots of standard components and lower for applications with complex custom business logic. The manual work is where the meaningful findings usually come from.

Get Cyphersilhouette’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Phase 3: Manual Testing — The Application as Intended Versus as Implemented

After the automated work, I put the tools down and work through the application the way a motivated attacker with a legitimate account would.

The core question I’m asking throughout: what is this application supposed to allow me to do, and what does it actually allow me to do?

The gap between intention and implementation is where the interesting findings live.

What I Focus on in Manual Testing

• Every user permission boundary: what can a free user access that a paid user shouldn’t? What can a standard user access that an admin shouldn’t? What can a user from Tenant A access that belongs to Tenant B?
• Multi-step flows tested out of sequence: what happens if I skip Step 2 of a 3-step process? What happens if I repeat Step 1 after completing Step 3?
• API endpoints tested directly via proxy, not through the UI: does the API enforce the same constraints the frontend does?
• Error handling and information disclosure: what do error responses reveal about the internal structure of the application?
• Business logic edge cases specific to this product: if this is a billing product, what happens at the boundaries of billing cycles? If this is a workflow product, what happens when a workflow is in an unexpected state?

Phase 4: Business-Impact Scoring

Every finding gets two scores: a technical CVSS score and a business impact score specific to this client.

The technical score helps communicate severity in industry-standard terms. The business impact score answers the question the founder actually needs answered: if this vulnerability were exploited against our specific product with our specific customer base, what would it cost us?

A CVSS 7.5 finding in a module that stores no sensitive data might be a business impact 3. A CVSS 5.0 finding that allows unauthorized access to customer billing information in a company preparing for enterprise sales might be a business impact 9.

The business impact score drives the remediation priority list. A founder deciding what to fix before a board meeting needs to know which finding matters most in their specific context, not which one scores highest on a generic scale.

The Deliverable That Actually Gets Used

A security audit report that gets filed and forgotten is a failed engagement as far as I’m concerned.

The deliverable I aim for is a report structured as a decision-support document: here are the findings, here is the business impact of each, here is a specific remediation recommendation for your actual tech stack (not generic advice), and here is a suggested prioritisation given your current stage and upcoming commitments.

When the engineering team opens the report, they should be able to take the top three findings directly into a sprint without a translation step.

That’s the difference between a report that produces change and one that produces a checkbox.