CTO preparing for a customer security review
An enterprise buyer sent a 200-line questionnaire and nobody on the team can answer the sections on data handling or incident response.
Find the holes before someone else does
We review the software you already run, find what an attacker would reach first, and hand back fixes as pull requests rather than a PDF nobody actions.
What arrives
- A threat model naming what an attacker would reach first, and how
- A findings list ordered by what is actually reachable, not by scanner severity
- Pull requests fixing the issues we can fix without a product decision
- A dependency and secrets audit across the repository and its history
Who this is for
Three profiles. If none of them is recognisably you, this is probably the wrong page - and the line below is the one worth reading before you book anything.
Not a fit: Skip this if you need a signed ISO 27001 or SOC 2 certificate, because that is an auditor's job and we are not auditors.
Founder who inherited a codebase from an agency
The previous developer is gone, nobody knows what the API can do, and the app handles payment or health data.
Engineering lead after a near miss
A dependency alert or a scraped endpoint got attention, and you want to know what else is sitting there unnoticed.
What you get
- A threat model naming what an attacker would reach first, and how
- A findings list ordered by what is actually reachable, not by scanner severity
- Pull requests fixing the issues we can fix without a product decision
- A dependency and secrets audit across the repository and its history
- Answers written for the security questionnaire your buyer sent
- A retest of everything we reported, after your team has fixed it
What we build it with
- OWASP ASVS
- Semgrep
- Trivy
- Burp Suite
- gitleaks
- OWASP ZAP
- Dependabot
Chosen per project, not per fashion. If your team already runs something else and it works, we use that.
How the work runs
-
1
2-3 days
Scope
We agree what is in bounds, what must not be touched, and which environment we work against.
From you: A written authorisation, and a staging environment with realistic but non-production data.
-
2
3-5 days
Threat model
We map the data, the trust boundaries and the paths in, then decide where to spend the time.
From you: 30 minutes with whoever knows the architecture best.
-
3
1-3 weeks
Review and test
We read the code and exercise the running system, confirming each finding is genuinely reachable.
From you: Read access to the repository, and test accounts at each permission level.
-
4
1-2 weeks
Fix and retest
We raise pull requests for what we can fix, then retest after your team merges.
From you: A reviewer for our pull requests, and a date for the retest.
How we work together
Fixed project
Scope and price agreed up front. Best when the outcome is known and the deadline is real.
Dedicated team
A named team for a quarter or more. Best when the roadmap will change and you want the context kept.
Staff augmentation
Engineers inside your process and your tools. Best when you have the lead and need the hands.
Invoiced in
- USD
- EUR
- GBP
- CHF
- SGD
- AUD
- CAD
- AED
- SAR
- QAR
- JPY
- INR
Paid by
Card, netbanking, wallet and UPI through Razorpay, which is what our checkout runs on, so anything it accepts we accept. Bank transfer, SEPA, Wise and Payoneer for invoices that prefer it.
NDA before the first call. Full IP assignment on delivery. Contracts under Indian, English or Delaware law.
Work like this
Case studies are being written up
Three are in legal review. We can walk you through the work on a call in the meantime, including the parts that did not go to plan.
What clients say on Google
Live from our Google Business listing - not retyped here.
Loading reviews from Google - read them on Google.
Questions we get asked
Both, and the split depends on what you have. We read the source where we can get it, because source finds logic flaws a black-box test never reaches, and we exercise the running system because code review misses configuration. If you need a signed pentest report for a customer, say so at scoping and we format the output to suit.
Not in production, because we do not test production without a written agreement and a rollback plan. Work happens against staging with realistic data. Where a finding can only be proven in production, we describe it and let you decide. Nothing destructive runs without you naming a window and a person to call.
Reachability. A scanner reports every dependency with a published advisory, and most of them are not reachable from your code. We check which ones actually are, and drop the rest. The findings list is usually a tenth the length of a scanner report and every line on it is worth an engineer's afternoon.
Usually. Anything that is a coding error we fix ourselves and send as a pull request against your branch. Anything that needs a product decision, like changing what data you collect, we write up with the options and let you choose. We do not hold findings back to sell a second engagement.
Once a year for most teams, and again after any change that moves a trust boundary: a new integration, a new customer-facing API, a move to a different cloud. Between reviews, the dependency and secrets scanning we set up runs in your pipeline and catches the routine cases without us.
Want to know what is exposed?
Send us the stack and what worries you, and we will say what a review would actually cover.