Overview
Many US SaaS companies add a code review when a customer asks for deeper assurance than a black box test, or before a release that touches billing or tenant boundaries. We read the code paths that matter most, confirm suspected flaws against a running build where we can, and hand findings to your engineers with file and line references they can pick up inside a normal sprint.
A penetration test shows what an attacker reaches from outside; a code review shows why. By reading the source we can follow a piece of untrusted input from the moment it enters the application to the point where it reaches a query, a command, a file path or a template, and judge whether every step in between actually defends against abuse. That path is often invisible from the outside, especially where a flaw needs a specific state to trigger.
We combine static analysis tooling with manual reading so the hours land where they matter. Tools flag candidate issues at scale; our reviewers confirm which are real, discard the noise, and find the problems tools cannot reason about: broken authorization logic, unsafe deserialization, secrets committed to the repository, weak or home-grown cryptography, and dependencies with known vulnerabilities. We focus on the authentication, authorization and data-handling code first, because that is where a single mistake does the most harm.
Every finding points to the exact file and line, explains the flawed logic, and recommends a concrete code change, not a generic principle. Where a pattern repeats across the codebase we say so, so your team can fix the class rather than the instance. The review pairs well with a penetration test: one confirms exploitability, the other explains root cause and catches what external testing never reaches.
How US engagements run
- Delivered remotely from India, 9.5 hours ahead of US Eastern in US daylight time and 10.5 hours in winter; calls and testing windows are set around your time zone at scoping
- Fixed-price proposals in US dollars, with scope, dates and the free retest written in before any work begins
- Written authorization signed by someone with authority over every target, because the federal Computer Fraud and Abuse Act and state laws make permission the dividing line
- Reports that name the requirement a test supports, such as PCI DSS 11.4, the FTC Safeguards Rule or SOC 2, without claiming a QSA, ASV or C3PAO role we don't hold
What's included
Our approach
- Repository intakeWe take read access to the code and a short walkthrough of its architecture.
- Automated passStatic analysis flags candidate issues across the whole codebase at scale.
- Manual reviewReviewers trace data flows and read security-critical logic by hand.
- ValidationCandidate issues are confirmed, de-duplicated and ranked by real impact.
- Report & debriefWe deliver findings by file and line and brief your developers on fixes.
What you receive
- Findings mapped to exact file and line references
- Root-cause explanation for each issue
- Concrete code-level remediation, not generic advice
- Notes on recurring patterns to fix as a class
- Free re-review of fixed code on request
Standards & frameworks
- OWASP ASVS
- OWASP Top 10
- OWASP WSTG
- SANS CWE Top 25
- NIST SP 800-115
- CWE
- CVSS v4.0
- SOC 2
Frequently asked questions
Is this just running a SAST tool?
No. We run static analysis to cover breadth, but the value is in the manual reading that follows: confirming real issues, discarding false positives, and finding logic flaws no tool understands. You receive reviewed findings, not an unfiltered scanner export.
How much code can you review in an engagement?
Effort scales with size and complexity, so we agree a focus up front, usually the authentication, authorization and data-handling paths and any recently changed areas. For a very large codebase we prioritize the highest-risk components rather than skim everything shallowly.
Do you need to build or run our code?
Usually read access to the repository is enough, since the review is static. Being able to build or run the application helps us confirm a few findings, so we welcome a working environment where you can provide one, but it is not essential.
Will a SOC 2 auditor accept your application pentest report?
Penetration testing isn't written into the SOC 2 criteria, yet it is common for auditors and enterprise buyers to look for a recent test. Our report records scope, dates, method and rated findings, and the retest letter shows what was fixed. Your auditor still decides which evidence they accept.
Can testing fit around our US release schedule?
Yes. Testing windows, call times and code-freeze periods are agreed around your time zone at scoping. We deliver from India, which is 9.5 hours ahead of US Eastern during US daylight time and 10.5 hours in winter, and any critical issue is passed to your nominated contact the day it is verified.