Cyber Security Testing
Secure Source Code Review
Manual and SAST-assisted review that finds the classes of flaw black-box testing cannot reach.
Every engagement includes manual validation, a two audience report and free re-testing.
Get a scoped quote+91 96682 00222What this actually is
Black box testing finds what is reachable. Code review finds what is there. Some of the worst flaws we have reported sat in code paths that were not reachable during a test but were one feature flag away from being live.
We review by hand, supported by static analysis, and prioritise the classes of flaw tooling reliably misses. Authorisation logic, cryptographic misuse, injection through unusual sinks, race conditions, and secrets committed to history.
You get findings mapped to the exact file and line, with a fix written in the language your team actually uses.
What we go after
- Authentication and authorisation logic
- Injection sinks across SQL, command, template and deserialization
- Cryptographic implementation and key handling
- Secrets in code and in commit history
- Input validation and output encoding
- Race conditions and concurrency flaws
- Third-party dependency and licence risk
- Security of the build and release pipeline
How we run it
- 01
Scope and authorise
Targets, testing windows, escalation contacts and safety limits, all agreed in writing before anyone touches anything.
- 02
Map the surface
We enumerate what is actually exposed, which is usually more than the asset register says.
- 03
Test by hand
Tooling gives coverage, our engineers give proof. Every finding is reproduced before it is written down.
- 04
Report
An executive narrative your board can act on, and a technical annexe with the exact request, payload and fix.
- 05
Re-test and sign off
Once you have fixed it we verify each one at no extra cost, then close the engagement properly.
What you receive
- Findings mapped to file and line with a suggested patch
- Secrets audit across current code and history
- Dependency and supply chain risk report
- Secure coding guidance tailored to your stack
- Optional pipeline integration so this keeps running
Who needs this
Product teams shipping code that handles money, identity or health data, and any organisation whose regulator asks for secure development evidence.
How long it takes
One to three weeks depending on codebase size and language count.
Standards this satisfies
- OWASP ASVS
- CERT-In
- PCI DSS
- ISO 27001
- SOC 2
Why it matters
Some vulnerability classes are effectively invisible from outside. A race condition, a cryptographic misuse, a hardcoded key on a path that only triggers under load. Testing the running application will not find them reliably; reading the code will.
It is also the cheapest point to fix. A flaw caught in review costs a change to a branch. The same flaw caught after release costs an incident, a re-test and a conversation with a customer.
Choose the depth you actually need
Most of the price difference between quotes comes down to this one choice, and it is rarely explained. Pick one to see what it covers, what it suits and what it costs you.
You give us working accounts at each privilege level and a short walkthrough. We then test what a real attacker reaches after the first stolen password, which is where the findings that matter almost always live. This is what we recommend for most engagements.
Choose this when
- Any application with authenticated functionality
- Multi-tenant products, where tenant isolation is the real risk
- Getting the most findings for the money
Effort and cost
Moderate effort and by far the best coverage per rupee. Most of the serious findings we report come out of authenticated testing rather than unauthenticated.
Tested against OWASP ASVS, not a checklist we invented
We test to the OWASP Application Security Verification Standard, which sets verification levels across authentication, session management, access control, input validation, cryptography, error handling and business logic. Working to a published standard means you can tell an auditor or a customer exactly what was verified and to what depth. It also makes this year's test comparable with last year's, which a bespoke in-house checklist never is.
Scope it yourself, before you call anyone
Answer a few questions and you get an indicative number, the working behind it and what your answers tell us. It runs in your browser, so nothing you type reaches us.
What needs testing?
Pick everything in scope. Effort is driven by unique functionality, not by how many IP addresses you own.
What we look for, and keep finding
These are the classes of problem this work exists to surface. Not every engagement finds all of them, but these are the ones that turn up often enough to be worth naming.
Broken access control
The most common serious finding we report, and the one scanners miss most reliably. An identifier that is not checked against the caller, an admin function reachable by guessing its path, a role that can be changed in the request. The user is logged in. They are simply reading or doing something that is not theirs.
Injection and unsafe query construction
SQL, NoSQL, OS command and template injection. Modern frameworks prevent most of it, which is exactly why the remaining cases hide in the hand written query somebody added under deadline, or in the reporting module nobody has looked at since it shipped.
Authentication and session weaknesses
Tokens that do not expire, password reset flows that can be redirected, multi-factor that can be skipped by replaying an earlier step, and sessions that survive a password change. We test the whole lifecycle rather than just the login form.
Business logic abuse
Nothing is technically broken. The application simply allows a sequence it should not: a discount applied twice, a payment confirmed before it clears, a limit avoided by splitting a request. This requires understanding what the application is for, which is why automation cannot find it.
Sensitive data exposure
Data returned by an API that the interface never displays, secrets in client side code, verbose errors that reveal structure, and personal data in logs. The response body is where we find most of it.
Security misconfiguration
Default credentials, directory listing, debug endpoints reachable in production, permissive CORS and missing security headers. Individually minor, and routinely the first step in a chain that ends somewhere serious.
Who runs your engagement
A senior tester, named before you sign
Testing is led by an engineer holding OSCP, CREST or equivalent, and you are told who it is before the engagement starts. They write the report themselves rather than handing notes to someone else, and they are on the call when findings are walked through. If the person changes, we tell you why.
Questions we get asked
Do we have to hand over our source code?
Yes, and we understand that is a decision. We can work inside your environment, under NDA, with access revoked at the end. Several clients have us review on a screen-share basis for their most sensitive repositories.
Can you just run a SAST tool for us?
We could, and you would get a lot of noise. The value here is a human reading the authorisation logic. We use tooling to find candidates and engineers to decide what is real.
Often scoped alongside
- Web Application Security TestingOWASP-aligned manual and automated testing of web applications, with validated proof-of-concept for every finding.Read more
- Mobile Apps Security TestingAndroid and iOS binary, runtime and API-layer assessment against OWASP MASVS.Read more
- Network Penetration TestingInternal and external network exploitation, lateral movement and privilege escalation testing.Read more
- API Security TestingAuthentication, authorisation, rate-limiting and business-logic testing across REST, GraphQL and gRPC.Read more
Ready to scope your secure source code review?
Thirty minutes with a senior engineer, and you leave with a written scope and indicative effort.