Source code review is a security check of your application's code, carried out by a security engineer with the help of automated scanners. The aim is to find vulnerabilities such as injection flaws, broken access control, hard-coded secrets and risky third-party libraries before an attacker, a customer's security team or an auditor finds them.
For most Indian companies, a source code review takes 3–5 working days, ends with a report that maps every finding to OWASP and tells developers exactly how to fix it, and is priced on the size of the codebase. This guide explains how the process works, what you should receive, how it differs from a penetration test and what drives the cost.
Key takeaways
- Source code review combines automated static code analysis (SAST) with manual review by a security engineer. Tools alone miss business-logic and access-control flaws.
- A code review finds problems from the inside, in the code itself. A penetration test attacks the running application from the outside. Most teams need both.
- Common triggers in India: a major release, enterprise security questionnaires, ISO 27001 or SOC 2 evidence, investor due diligence and STQC testing for CCTV and IoT products.
- A good report gives severity, file and line references, OWASP and CWE mapping, and a step-by-step fix for every finding, followed by a retest.
- Cost depends mainly on lines of code, languages, number of modules, deadline and retest scope. Typical delivery is 3–5 working days.
What is source code review?
Source code review, also called secure code review or a source code audit, is a security assessment in which reviewers read an application's code to find weaknesses that could be exploited. It usually covers your own code, configuration files, infrastructure-as-code templates and the open-source libraries your application depends on.
It is not the same as peer review on pull requests. Peer review asks, "Does this work, and is it maintainable?" A secure code review asks, "How could someone abuse this?" Reviewers trace user input to see where it reaches a database query, file path, system command or authorisation decision without proper checks.
Manual review and automated static code analysis
Static code analysis, or SAST (Static Application Security Testing), uses tools that scan code without running it and flag known risky patterns. Scanners are fast and consistent. They are good at catching SQL queries built by string concatenation, weak cryptographic functions and secrets committed to the repository.
But scanners do not understand your business. They cannot tell that a refund API lets one customer act on another customer's order, or that an admin check is missing on one endpoint out of fifty. They also raise false positives. Manual review fills both gaps: it confirms which findings are real and uncovers the logic flaws tools miss.
A credible source code review uses both. Tools give coverage; people give judgement.
Source code review vs automated SAST vs penetration test
Buyers often ask whether they need a code review or a penetration test (VAPT). The two answer different questions. A penetration test attacks the running application the way a real attacker would and shows what is exploitable in that environment. A code review looks for the root cause inside the code and can reach code paths that a tester never triggers.
| Aspect | Manual source code review | Automated SAST only | Penetration test |
|---|---|---|---|
| What it examines | Source code, configuration and dependencies, with business context | Code patterns matched against rules | The running application, APIs and infrastructure |
| Access needed | Read-only repository access | Repository or CI/CD pipeline | URLs, test accounts, sometimes VPN |
| Business-logic and access-control flaws | A key strength | Rarely found | Often found, if the flow is reachable during testing |
| Points to exact file and line | Yes | Yes | No, it reports the symptom |
| False positives | Low, findings are verified by hand | Can be high | Low, findings are demonstrated |
| Hidden or rarely used code paths | Covered | Covered | Limited to what is reachable |
| Time taken | Days | Minutes to hours | Days |
| Best for | Pre-release assurance, compliance evidence, due diligence | Continuous checks on every commit | Proving real-world exploitability |
In practice, mature teams run SAST in their pipeline every day, commission a manual source code review before major releases or audits, and run a penetration test on the deployed product. If you need the outside-in view as well, see our services for web application penetration testing, API penetration testing and mobile app penetration testing.
When do companies in India need a source code review?
- Before a major release. A new payment flow, a rebuilt login system or a large refactor are good moments for a review. Fixing a flaw in code before go-live costs far less than handling an incident after it.
- Enterprise customers and security questionnaires. Banks, large enterprises and global customers often ask whether your code has been independently reviewed. A third-party report answers that question with evidence rather than a promise.
- ISO 27001 and SOC 2 evidence. ISO/IEC 27001:2022 Annex A includes controls for secure coding (8.28) and security testing in development and acceptance (8.29). SOC 2 auditors look for evidence that changes are tested before release. An independent code review report supports both.
- Investor due diligence or acquisition. Technical due diligence often looks at code quality and security. A recent review, with fixes verified, reduces surprises late in the deal.
- STQC certification for CCTV and IoT products. CCTV cameras and related devices sold in India go through security testing under government essential requirements at STQC or other recognised labs, and source code review is part of that testing. A pre-assessment source code review for STQC helps manufacturers find and fix issues before the lab does. A private security firm cannot issue STQC certificates; the value lies in getting your code ready.
Not sure whether you need a full review or a focused audit of one module? Share your repository size and tech stack, and Xtreme InfoSec will suggest a sensible scope. See how our source code review service works.
The source code review process, step by step
1. Scoping
The reviewer needs the languages and frameworks, the repositories and modules in scope, the approximate lines of code (a tool such as cloc counts them quickly) and the deadline. Say why you want the review, for example a customer audit or an STQC submission, so effort goes where the risk is.
2. NDA and secure code access
A non-disclosure agreement should be signed before any code changes hands. The safest options are read-only access to a specific repository or branch on GitHub, GitLab or Bitbucket, or an encrypted archive shared over a secure channel. Agree up front how the code will be stored during the engagement and when it will be deleted.
3. Automated scans
Scanners give broad coverage quickly. Commercial SAST tools such as SonarQube and Checkmarx are often paired with open-source tools: Semgrep for custom rules, Gitleaks for hard-coded secrets, OWASP Dependency-Check and Syft/Grype for vulnerable third-party components and a software bill of materials (SBOM), Cppcheck and Flawfinder for C and C++, and Binwalk and Ghidra when firmware is involved.
4. Manual review
This is where most of the value sits. Engineers read the high-risk areas by hand: authentication, session handling, authorisation, input validation, cryptography, file uploads, error handling, logging and business logic. The OWASP Top 10, the OWASP Application Security Verification Standard (ASVS) and the CWE list give a consistent checklist.
5. Triage
Every scanner result and manual observation is verified. False positives are removed, duplicates are grouped and each real issue gets a severity rating based on how easily it can be exploited and what damage it could do.
6. Report and walkthrough
The report is delivered with a call that walks your developers through the critical and high findings.
7. Fix support and free retest
Developers fix the issues, ideally with the reviewer available for questions. The reviewer then retests the fixes and issues an updated report showing which findings are closed. That closed-out report is what auditors and customers usually want to see.
What a good source code review report contains
- Executive summary in plain language for management: overall risk, number of findings by severity and the top issues to fix first.
- Scope and method: repositories, branch or commit hash, lines of code, languages, tools used and dates. For audit evidence, this proves exactly which version of the code was reviewed.
- Detailed findings, each with a title, severity, file path and line numbers, the vulnerable code snippet, a clear explanation of impact, and its OWASP Top 10 and CWE mapping.
- Step-by-step remediation for each finding, ideally with a secure code example in your own language and framework.
- Dependency and secrets findings, listing vulnerable library versions to upgrade and credentials to rotate.
- Retest status showing which findings are fixed, partly fixed or still open.
One red flag: a raw scanner export with hundreds of unverified items. It pushes the triage work back to your developers.
How to prepare your team and repository
- Freeze a branch or tag and share the commit hash, so the review targets a stable version.
- Share the code as it is. Do not clean it up first; reviewers need to see real configuration files too. If you already know secrets are committed, rotate them anyway.
- Give context: a simple architecture diagram, the user roles and which modules handle payments or personal data.
- Include dependency manifests such as package.json, pom.xml or requirements.txt, so library scanning is accurate.
- Exclude what does not need review, such as generated code, vendored libraries and test fixtures. This keeps the line count, and the cost, honest.
- Name one technical contact who can answer reviewer questions within a day.
- Block developer time for fixes in the sprint after the report arrives, so the retest happens quickly.
Source code review cost in India: what affects the price
Source code review is usually priced on the size of the codebase rather than a flat fee. At Xtreme InfoSec, pricing is based on lines of code, with a minimum engagement of ₹15,000. Because every codebase is different, the quickest way to get a realistic figure is the free VAPT and source code review cost estimator.
These are the factors that move the number:
- Lines of code. The biggest driver. Count only the first-party code in scope, not third-party libraries or generated files.
- Languages and frameworks. Several languages in one project, less common languages, C or C++ with memory-safety concerns, and firmware all need more review effort.
- Number of applications or modules. A web front end, a mobile app and backend APIs are separate review areas, and microservices multiply the number of entry points.
- Deadline. Standard delivery is 3–5 working days for most projects. Express delivery within 2 working days carries a 25% surcharge. Very large codebases are scheduled after scoping.
- Retest scope. A retest of the reported findings should be included. Reviewing new features or a major rewrite later is new scope.
When comparing quotes, ask whether manual review is included, whether the retest is free, and for a sample report.
Frequently asked questions
Is secure code review the same as source code review?
In practice, yes. Both terms describe reviewing code to find security vulnerabilities, and "source code audit" is used the same way. A general code review for quality or style is a different activity.
How long does a source code review take?
Most projects take 3–5 working days from the time code access is shared. Express delivery within 2 working days is possible for an extra charge. Very large codebases are scheduled after scoping.
How much does source code review cost in India?
Pricing is based on lines of code, with a minimum engagement of ₹15,000. Languages, number of modules and deadline also affect the final quote. Use the free cost estimator for a quick figure based on your codebase.
Is it safe to share our source code with a security company?
It should be, if basic safeguards are in place. Insist on an NDA before sharing, give read-only access to only the repositories in scope, and agree in writing how the code is stored and when it is deleted. Working with an ISO/IEC 27001 certified provider adds assurance.
Do we still need a penetration test if we have done a code review?
Usually, yes. A code review finds flaws in the code, while a penetration test checks the deployed application, its configuration and infrastructure from an attacker's view. The two complement each other, and many customers and auditors ask for both.
Can static code analysis tools replace manual review?
No. SAST tools are excellent for continuous, automated checks and should run in your pipeline. They cannot judge business logic or access control and often report false positives, so a periodic manual review is still needed.
Get your code reviewed before your next release
Xtreme InfoSec is an ISO 9001 and ISO/IEC 27001 certified cybersecurity company that combines manual review with SonarQube, Checkmarx and open-source tools. Every engagement includes an OWASP-mapped report with step-by-step fixes and a free retest. Email contact@xtremeinfosec.com or call +91 98183 63944; we reply within 1 hour on working days.