Source Code
Security
Review
Manual security review of application source code to identify weaknesses in authentication, authorization, business logic, data handling, cryptography and API implementation — with findings your developers can act on.
See the Security Logic
Source code review gives security engineers visibility into implementation details that may be difficult to establish from external testing alone. It can expose flawed authorization decisions, unsafe data flows, insecure cryptography and business-logic weaknesses before or alongside runtime testing.
For SaaS and fintech teams, the review can focus on high-value workflows such as authentication, tenant isolation, payment or transaction logic, privileged operations and API trust boundaries.
What We Find
Review scope is tailored to the application and codebase. We combine manual analysis with appropriate automated tooling to investigate security controls, attack paths and high-risk implementation areas.
SQL, NoSQL, LDAP, OS command, and SSTI injection — tracing unsanitised input from entry point to database or system call, including second-order injection and ORM-level bypasses.
Broken algorithms (MD5, SHA1, DES, ECB mode), hardcoded IV/keys, predictable random number generation, insecure key storage, and custom crypto implementations that should never exist.
API keys, database credentials, JWT signing secrets, cloud access tokens, and private keys hardcoded in source files, config files, build scripts, and git history.
Broken auth logic, missing authorisation checks, JWT algorithm confusion (alg:none), mass assignment, IDOR, privilege escalation paths, and insecure session management.
Reflected, stored, and DOM-based XSS, server-side template injection (SSTI), unsafe innerHTML usage, missing Content-Security-Policy, and dangerous eval() / dangerouslySetInnerHTML patterns.
Path traversal, unsafe deserialization, unrestricted file uploads, XXE in XML parsers, zip slip vulnerabilities, and insecure temporary file handling that enables arbitrary read/write.
Review Methodology
Manual-first analysis with tooling assist — our engineers read your code, not just run scanners against it.
Codebase Intake & Scope
Receive source via secure Git access or encrypted archive. Map technology stack, frameworks, and entry points. Define high-value targets — auth flows, payment logic, admin functions, and API endpoints.
Automated SAST Scan
Use appropriate SAST and dependency-analysis tooling for the technology stack to surface candidate findings. Triage and validate those results so automated noise does not become your remediation backlog.
Manual Data Flow Analysis
Trace all user-controlled input from source to sink — manually following data through business logic, across service boundaries, through ORMs, and into storage to find what SAST tools miss entirely.
Business Logic Review
Review application-specific logic — transaction flows, access control decisions, state machine flaws, race conditions, and workflow bypasses that require understanding the application's intent to identify.
Dependency & Supply Chain Audit
Audit third-party dependencies for known CVEs, abandoned packages, typosquatting risks, and overly-permissive library versions. Review npm, Maven, pip, and Gradle lockfiles for supply chain exposure.
Annotated Report & Fix Review
Deliver findings as annotated code with line-level references, severity ratings, and exact fix recommendations. Optional: review developer fixes before merge and provide a cleared retest confirmation.
What We Support
Supported languages and frameworks depend on reviewer availability and engagement scope. Confirm your stack during scoping.
Code Review vs SAST vs Pentest
These approaches answer different security questions. A source-code review focuses on implementation and security logic; SAST scales automated pattern analysis; penetration testing validates behaviour in a running environment.
| Capability | Source Code Review | SAST | Penetration Testing |
|---|---|---|---|
| Reads source code | Yes | Yes | Usually no |
| Automated at scale | Optional | Yes | Optional |
| Manual security reasoning | Strong | Limited | Strong |
| Business-logic analysis | Strong | Limited | Strong |
| Runtime behaviour | Limited | No | Yes |
| Best used for | Implementation weaknesses | Pattern discovery | Exploitability and runtime risk |
What We Need From You
What You Get
Annotated Findings Report
Findings are documented with affected component or code location where appropriate, severity, security impact, evidence, and practical remediation guidance.
Executive Summary
A non-technical summary of overall code security posture, risk exposure, and top priority fixes — written for engineering leadership and CISOs, not developers.
Machine-Readable Output
Machine-readable output can be provided where agreed during scoping. Confirm the required format and integration before engagement.
Retesting
After remediation, Grey Shield can perform a retest to verify that agreed findings have been addressed. Exact retest scope and timing are confirmed during engagement.
Developer Debrief Session
A live walkthrough with your engineering team — explaining attack scenarios for each finding, answering fix questions, and advising on secure coding patterns to prevent recurrence.
NDA & Source Code Protection
Source-code handling, access controls, retention and deletion procedures are agreed before the review. [INFORMATION REQUIRED: publish only the storage and deletion commitments Grey Shield actually follows.]
Source Review FAQ
What is a source code security review?
It is a security-focused examination of application source code to identify weaknesses in implementation, security controls, data flows and application logic.
Is manual review different from SAST?
Yes. Automated analysis can identify useful patterns and candidate issues, while manual review adds context around business logic, authorization, data flow and application-specific security decisions. OWASP describes the two as complementary approaches.
Can you review APIs and business logic?
Yes, where those components are included in scope. The review can trace API inputs, authorization decisions and business workflows through the relevant implementation.
Should source review replace penetration testing?
No. Source review and runtime testing answer different questions. Using them together can provide stronger coverage of both implementation weaknesses and observable application behaviour.
Find the Flaws
Before Merge
Send us your repository — we'll review it line by line and return findings your developers can act on immediately. Engagement timing depends on codebase size, technology stack, scope and review depth. Confirm timing during scoping.