How We Approach Security Testing
A look inside the process — for anyone deciding who they trust with their application's security
We Don't Start by Looking for Bugs
Ask most security vendors how they work, and you'll hear some version of: "we scan your app, we find vulnerabilities, we send you a list." That approach produces reports. It doesn't produce security.
We do something different. Before a single test is run against your application, we spend real time simply understanding it — how it's built, how data moves through it, who's allowed to do what, and where the boundaries between "safe" and "exploitable" actually sit. You cannot properly secure a system you haven't first understood at that level of depth, and skipping that step is exactly why so many security assessments miss the vulnerabilities that matter most and pad their reports with the ones that don't.
This document walks through that process end to end — from the moment we receive access to your codebase, to the final report that lands in your inbox, to the verification pass that confirms your fixes actually worked.
0. Scoping, Rules of Engagement & Safe Onboarding
Before testing begins, we set up clear boundaries to ensure your production users, staging environments, and third-party integrations remain completely safe throughout the engagement.
Dedicated IP whitelisting & WAF bypass headers to prevent false-alarm Cloudflare rate limits or IP bans during active testing.
Encrypted source code handling on isolated workstations. Your codebase is never saved, distributed, or used to train external AI models.
Direct Slack/Signal escalation line to your tech lead for real-time alerts if a Critical zero-day is found on Day 1.
/// Do We Need Your GitHub Repository Access?
A common question from founders and engineering leads is: “Do I need to grant you full access to our GitHub organization to run a security audit?” The answer depends on the testing methodology — and we always recommend the approach that delivers maximum security depth without asking for unnecessary access.
Attacker Perspective
We test your application blindly from the outside with zero prior knowledge — exactly like a real-world adversary.
Source-Code Security Audit
Deep static analysis of your source code. Read-only repo access is sufficient — no full organization access required.
- • Read-Only GitHub/GitLab Repo
- • Specific Branch / Commit Hash
- • Env Configs & Dependency Files
- • Deployment Configs (where relevant)
Convergent Dual Audit (Maximum Value)
The gold standard. We test from both external attacker perspective AND internal source-code logic simultaneously to eliminate false positives and catch hidden flaws.
We hit the live staging application as an untrusted user. What endpoints can be discovered? What headers are exposed? What rate limits or auth bypasses exist in real time?
We trace backend handlers directly. Are authorization checks enforced on every query? Are dangerous functions sanitized? Are secrets or vulnerable dependencies present?
Reconciling the external live exploit findings against internal source-code logic ensures zero false positives, clear code-level remediation paths for your developers, and maximum return on security investment.
Note on Organization Security: We never require full GitHub/GitLab organization admin access. A read-only invite to the specific repository and branch being audited is all that is required, keeping your broader infrastructure completely isolated.
1. Building the Map
Every engagement starts the same way: not with an attack, but with a survey. We walk through your entire system, layer by layer, before we touch a single test case.
Each layer answers a different question. What framework and architecture are we working with, and what weaknesses does that stack typically carry? How does a request actually travel from the browser to your database and back? Where does the system decide who's allowed to see what? What third-party services does your application quietly trust, and what happens if one of them is compromised? By the time this phase is done, we're not guessing about your application anymore — we know it.
From this survey, we build an Attack Surface Map: a precise, complete inventory of every entry point into your system.
This isn't a generic list pulled from a crawler. Every single endpoint on this map is cross-referenced directly against your source code — what handles it, what data it touches, what checks (if any) stand between a request and the resource it's asking for. Nothing on this list gets tested blind, and nothing that matters gets left off it.
2. What We Actually Test
This is the core of the engagement, and it's worth walking through in detail — because the difference between a thorough assessment and a superficial one almost always comes down to what's on this list, and how carefully each item is pursued.
/// Authentication — Can someone get in who shouldn't?
We test whether unauthenticated users can reach routes that are supposed to be protected, whether sessions can be reused or hijacked after they should have expired, whether tokens (JWTs and otherwise) are actually validated the way the code assumes they are, and whether the authentication layer itself has a gap that lets it be bypassed entirely. Authentication is the front door. If it has a weak hinge, nothing else about your security matters.
/// Authorization — Can someone reach things that aren't theirs?
This is where the majority of real-world breaches actually happen, and it's the area we give the most deliberate, systematic attention.
Most applications correctly check whether you're logged in. Far fewer correctly check whether you're logged in as the right person for the specific resource you're requesting. That gap is called Broken Object Level Authorization (BOLA/IDOR) — and it's one of the most common, most damaging, and most consistently under-tested flaws in modern web applications. A single missed ownership check on an endpoint like /api/orders/:id can mean any logged-in user can read, modify, or cancel anyone's order simply by changing a number in the URL. We test every resource-handling endpoint on your map against this exact scenario.
/// Input Handling — What happens when data isn't what you expected?
Every field your application accepts — form input, URL parameters, headers, file uploads — is a potential doorway if it isn't handled correctly. We test each of these systematically:
- SQL Injection — can malformed input manipulate your database queries?
- Cross-Site Scripting (XSS) — can an attacker inject code that runs in another user's browser?
- Command Injection — can input reach the operating system shell?
- Path Traversal — can input be crafted to escape the intended directory and reach files it shouldn't?
- Server-Side Request Forgery (SSRF) — can your server be tricked into making requests to internal systems on an attacker's behalf?
- Server-Side Template Injection (SSTI) — can input reach a template engine and execute arbitrary code?
- Unsafe Deserialization — can crafted data, once deserialized, execute unintended logic?
These are old, well-documented vulnerability classes. That's exactly why they still work — they're boring to test for, so they get skipped more often than you'd think.
/// Cloud Infrastructure & Bill Amplification Risk — Can someone drain your cloud budget overnight?
Modern web applications rarely exist in isolation — they run on cloud platforms (AWS, GCP, Vercel, Cloudflare) connected to third-party APIs (OpenAI, Resend, Twilio, Stripe). We audit your cloud deployment for permission drift, exposed storage buckets, and Financial Denial of Service (FDoS) vulnerabilities. Unthrottled webhook endpoints or unvalidated AI prompts can allow an attacker to run automated loops that generate $10,000+ unexpected cloud API bills in hours. We test rate limiting, queue isolation, and cost-cap boundaries to shield your cloud budget.
/// Secrets & Configuration Exposure — Is the front door locked, but the key sitting on the porch?
We search for exposed API keys, cloud provider credentials, private keys, database passwords, authentication tokens, and .env files left reachable in code, configs, or build artifacts. This category of finding is unglamorous, and it is also, consistently, one of the fastest ways a real attacker actually gets in.
/// Dependency Risk — Is your foundation built on something already known to be broken?
Modern applications are assembled from hundreds of third-party packages, and every one of them is a piece of your attack surface whether you audited it or not. We run a full inventory of your dependency tree against known vulnerability databases to flag outdated or already-compromised components before someone else finds them for you.
/// Business Logic — Does the system behave the way it assumes it will?
This is the layer that automated scanners cannot see at all, because there's no signature to detect — the code isn't broken, the sequence of trust is. This is where we spend the most deliberate, manual effort, and it's usually where the most consequential findings come from.
We trace critical flows end-to-end, exactly as a real user or a real attacker would move through them:
THE CRITICAL QUESTION“Can a refund be triggered without a successful payment ever having occurred?”
Business logic flaws don't show up in a vulnerability scanner's output. They show up when someone deliberately tries to break the order of operations your system silently assumes will always hold — skip a step, replay a request, submit a refund before the payment webhook fires, request a discount code twice in the same session. Finding these requires actually understanding what your business is trying to enforce, not just what your code technically allows.
3. How the Pieces Come Together
None of this happens as a single linear pass. Two tracks run in parallel and then converge:
If our principal engineers uncover a Critical (CVSS 9.0+) vulnerability — such as an unauthenticated SQL Injection or Remote Code Execution — during active testing, we do not hold it for the end-of-engagement report. We issue a 1-page Flash Advisory to your technical lead within 2 hours, complete with emergency containment steps.
The source code tells us what the application is supposed to do and where the logic might quietly diverge from that intent. The live environment tells us what it actually does when real requests hit it. Neither view alone is sufficient — code review misses runtime behavior, and live testing alone misses context that only the source explains. Running both, and reconciling them against the same attack surface map, is what lets every finding in the final report be traced back to a specific line of logic and a specific, reproducible request.
We also draw a hard line here that matters for your production environment: no exploitation is ever run without deliberate scoping and containment. Testing a system for weaknesses and destabilizing it are two very different things, and we treat that distinction as non-negotiable, especially on anything live.
4. What You Actually Receive
We don't hand clients a line like "found 7 vulnerabilities" and call the engagement finished. Every assessment concludes with a full Security Assessment Report, built so that your leadership and your engineering team can both act on it immediately — without needing us in the room to interpret it.
Executive Summary
Written for decision-makers, not engineers — because the person deciding whether to fund the fix is rarely the person who'll write it.
Followed by a plain-language summary of the two or three risks that actually matter, without the noise.
Scope
Exactly what was tested and what wasn't: target systems, environment, testing window, the accounts used, and any systems explicitly included or excluded from the engagement. No ambiguity about what "tested" means.
Methodology
A transparent account of how the assessment was conducted — reconnaissance, attack surface discovery, authentication and authorization testing, API testing, input validation, business logic testing, source-code review, dependency analysis, and final verification. Nothing about how we reached our conclusions is a black box.
Attack Surface Summary
This is the section clients consistently tell us they found most valuable — often because it's the first time anyone has laid their real exposure out this plainly:
Most organizations underestimate this number by a wide margin. Seeing it in writing tends to change how a leadership team thinks about risk.
Findings
Every single finding — whether it's one of two or one of twenty — follows the same rigorous structure, so nothing gets lost in inconsistent formatting or vague language:
The authorization check on this endpoint verifies that a user is logged in, but does not verify that the requested order actually belongs to them.
Any authenticated user can access another user's private order data by modifying a single value in the request.
Captured request and response data demonstrating the exact exploit path.
- Log in as User A
- Access Order A and note the endpoint structure
- Modify the object ID to a different order
- Observe that User B's order data is returned without error
Enforce server-side ownership verification on every request to this endpoint, not just an authentication check.
Evidence
Every finding is backed by concrete, reproducible evidence: captured request and response data, screenshots, the relevant source-code snippet, the specific endpoint, the user role used to trigger it, and a timestamp.
We hold ourselves to one standard without exception here: a theory is not a finding. A vulnerability only makes it into your report once it has actually been reproduced and documented with evidence behind it. Speculation, "this looks like it could be an issue," and untested assumptions never appear in a client-facing report. If we can't show it to you, we don't claim it.
Risk Matrix
| Severity | Meaning |
|---|---|
| Critical | Severe compromise or major business impact |
| High | Significant unauthorized access or data exposure |
| Medium | Meaningful but limited impact |
| Low | Minor security weakness |
| Informational | Hardening opportunity or observation |
Where applicable, CVSS scores and vectors are documented alongside each finding, giving your team a standardized way to prioritize and track remediation internally.
Remediation
We don't stop at describing the problem and walking away. Every finding includes exactly what your development team needs to close it — written so a developer can act on it without a follow-up call:
This is where a QA-rooted approach to security actually shows up in the deliverable. We're not just telling you something is broken — we're telling you precisely how to confirm, on your own, that it's genuinely fixed once you've made the change.
Retest & Verification Report
Once fixes are deployed, we don't take your word for it and we don't take our own word for it either — every single finding gets retested against the live system, and the outcome is reported plainly:
This can be delivered as a standalone Remediation Verification Report, giving you a clean, dated record of exactly what's resolved and what still needs attention — useful for your own internal audit trail as much as for us.
5. Post-Audit Engineering Support & Debrief
Delivering a security report is only half the job; ensuring your team successfully fixes the vulnerabilities without breaking application features is where real security happens. Every engagement includes dedicated engineering follow-through:
1-on-1 Engineering Debrief Session (45 Mins)
A live walkthrough with your core developers and tech lead to explain the exact exploit vectors, answer technical questions, and discuss architectural remediation paths.
Code-Level Pairing & PR Guidance
Your developers can share code drafts or Pull Requests directly with our team to confirm that proposed authorization logic or input sanitization satisfies security requirements before merging to main.
Why This Process, and Not a Shorter One
It would be easy to skip most of this. A quick scan, a list of CVEs, a PDF with a red-yellow-green chart on the cover — that's what a lot of security engagements actually amount to, and it's fast to produce and easy to sell.
It also doesn't hold up. Automated scans miss authorization flaws by design, because they can't tell the difference between "User A accessing Resource A" and "User A accessing Resource B" — that distinction requires understanding what your application is supposed to enforce, not just what technically responds with a 200. They miss business logic flaws entirely, because there's no signature to match against a sequence of actions that individually look completely normal. And they produce reports that list problems without ever confirming whether the fix actually worked.
Our process exists to close exactly those gaps: a complete, evidence-backed picture of your real exposure, findings you can trust because they were reproduced rather than inferred, a remediation path your developers can execute without guessing at what we meant, and a retest that proves — not assumes — the fix held.
That's the standard we hold every single engagement to, regardless of size.
Common Questions About Our Security Process
Get your security audit conducted by senior engineers.
No automated scanners posing as reports. Full surface map, reproducible exploit proof, and verification pass.