Injection vulnerabilities
User input that flows unfiltered into SQL queries, operating system commands, LDAP queries, or template expressions enables data theft and can even lead to a full server takeover.
Security Services
Secure Code Review & Reverse Engineering
Security that starts in the code.
Many vulnerabilities can only be guessed at from the outside – in the source code, they often become clearly visible. With a secure code review, we analyze the security-critical parts of your software, check dependencies and secrets, and use reverse engineering to examine applications, firmware, and protocols for which no source code is available.
- Fixed price after scoping
- Free retest
- Quote within 24 hours
Definition
What is a secure code review?
A secure code review – also called a security code review or source code analysis – is the targeted examination of source code for security vulnerabilities. Unlike the functional review within a development team, it asks how an attacker could abuse the software: Where is input processed without validation, where are authorization checks missing, where is cryptography used incorrectly? We combine manual analysis with static application security testing (SAST) and are guided by the OWASP Code Review Guide and the OWASP Application Security Verification Standard (ASVS).
Reverse engineering comes into play where no source code is available: with purchased software, compiled applications, mobile apps, firmware from IoT and industrial devices, or proprietary protocols. Through disassembly, decompilation, and dynamic analysis, we reconstruct how they work and how they are protected – and find vulnerabilities, hidden access paths, or hard-coded credentials.
A penetration test shows what can be exploited from the outside. A code review additionally finds flaws that are hard to reach in a test – for example, in rarely used functions, in error handling, or in logic that only kicks in under certain conditions. And the earlier a vulnerability is caught in the development process, the cheaper it is to fix.
Code security is also gaining regulatory weight: the EU Cyber Resilience Act requires manufacturers of products with digital elements – with staggered transition periods – to implement security by design, vulnerability management, and a software bill of materials (SBOM). PCI DSS 4.0.1 requires bespoke and custom software to be reviewed for vulnerabilities before release (Requirement 6.2.3). With our report and test certificate, you can show customers, partners, and auditors that your software has been independently reviewed.
Our approach
How we review your code
We start by understanding the application: architecture, data flows, trust boundaries, and the functions with the highest protection requirements – such as login, payment processing, or tenant isolation. From this, we derive where an attacker would strike and focus the manual analysis on those areas.
Tools for static analysis, dependency scanning, and secret scanning provide a broad foundation. We assess every hit manually: Is the code location reachable, can the input be controlled, how big is the impact? Logic flaws, faulty authorization checks, and context-dependent cryptography issues can only be reliably identified through human analysis anyway.
For reverse engineering, we work with disassemblers and decompilers, with dynamic instrumentation, and – for hardware – by reading out flash memory and debug interfaces such as UART or JTAG. Where it makes sense, we combine the review with a penetration test of the running application to verify suspicious code locations in practice.
Common vulnerabilities
Vulnerabilities we find in code and binaries
Broken access control
Missing object-level authorization checks (IDOR), incomplete tenant isolation, or checks performed only in the front end open up access to other users’ data and functions.
Hard-coded secrets
Passwords, API keys, private keys, and tokens in source code, configuration files, or Git history can be used by anyone with repository access – and, after a leak, by any third party.
Insecure cryptography
Passwords stored with MD5 or SHA-1 instead of algorithms such as Argon2 or bcrypt, static initialization vectors, homegrown encryption, or predictable random numbers undermine the protection of sensitive data.
Deserialization and file handling
Deserializing untrusted data, path traversal, and unvalidated file uploads can lead all the way to malicious code execution on the server.
Vulnerable dependencies
Outdated libraries with known vulnerabilities, abandoned packages, and tampered components in the supply chain. Log4Shell showed how quickly a single library can become a risk for entire companies.
Logic and session flaws
Bypassable workflows, race conditions in payments or vouchers, insecure password reset flows, and faulty token validation – for example, with JWTs – remain invisible to scanners.
Memory corruption in native code
Buffer overflows, use-after-free bugs, and integer overflows in C and C++ components, firmware, or drivers can often be exploited all the way to code execution.
Options to fit your needs
Three ways to more secure software
These options aren’t fixed packages – during scoping, we put together the right scope and combine them as needed.
Source code available
Secure code review
Risk-based analysis of your source code – before releases, after major refactoring, or as a complement to a penetration test.
- Manual analysis plus SAST and SCA
- Aligned with OWASP ASVS and the Code Review Guide
- Findings with location and suggested fix
No source code
Reverse engineering
Analysis of binaries, apps, firmware, and protocols – when you need to assess purchased or compiled software.
- Static and dynamic analysis
- Search for backdoors and hard-coded credentials
- Assessment of protection and update mechanisms
Ongoing
Security in the development process
We help you integrate security testing into your development permanently, in the spirit of DevSecOps – instead of testing only now and then.
- Integration of SAST, SCA, and secret scanning into CI/CD
- Joint review of findings with your development team
- SBOM and vulnerability management for the Cyber Resilience Act
Process
How a code review works
Structured like all our security services, confidential, and closely coordinated with your development team.
-
01
Scoping & confidentiality
We clarify scope, technologies, and protection goals, as well as how the code will be exchanged securely. If you wish, we sign a non-disclosure agreement beforehand.
-
02
Fixed-price quote
Within 24 hours of scoping (on business days), you receive a fixed-price quote for the agreed scope – with no hidden costs.
-
03
Architecture and threat analysis
We get an overview of the structure, data flows, and trust boundaries and define the focus areas of the review.
-
04
Analysis
Tool-assisted and manual review of the critical components; for reverse engineering, static and dynamic analysis in an isolated environment.
-
05
Report & developer briefing
You receive a report with an executive summary and technical details. If you wish, we go through the findings together with your development team.
-
06
Retest & test certificate
After remediation, we recheck the fixes free of charge and issue a test certificate.
Reporting
Results your development team can act on right away
Our report brings together the perspectives of management and development. The executive summary rates the security level of your software and names the most important risks. The technical section describes each vulnerability with its location, evidence, CVSS rating, and a concrete suggested fix.
- Executive summary with a risk assessment
- Findings with file, line or function, and evidence
- CVSS ratings and classification according to the OWASP Top 10 or CWE
- Suggested fixes and pointers to secure alternatives
- Free retest of fixed vulnerabilities
- Test certificate to present to customers, partners, insurers, and auditors
Find security flaws before your software ships
Whether it’s just before a release, ahead of a due diligence review, or for purchased software without source code: we analyze what’s really inside your software.
FAQ
Frequently asked questions about code review and reverse engineering
Didn’t find your question? Call us at +49 2932 465265-0 or email info@rootsektor.de.
What is the difference between a code review and a penetration test?
A penetration test examines the running application from the outside, the way an attacker sees it. A code review analyzes the source code from the inside and also finds vulnerabilities that are hard to reach in a test. The combination is most effective: code findings can be verified in practice in a web application penetration test, and anomalies from the test lead directly to the responsible code location.
Isn’t an automated SAST tool enough?
SAST tools are a valuable building block, but they produce many false positives and miss entire classes of vulnerabilities – such as business logic flaws, missing authorization checks, or context-dependent cryptography issues. We use tools as a starting point and assess every hit manually. We’re also happy to help you integrate SAST and dependency scanning into your CI/CD pipeline in a meaningful way.
How do you protect our source code?
We agree on the exchange with you individually – for example, via time-limited read access to your repository or an encrypted transfer. If you wish, we sign a non-disclosure agreement before the project starts. After the project ends, the code is deleted or returned as agreed.
Do we have to have all of our code reviewed?
Not necessarily. For large codebases, a risk-based approach is usually more cost-effective: we focus on security-critical components such as authentication, access control, payment functions, interfaces, and the processing of external data. We define the appropriate scope together during scoping.
Is reverse engineering legal?
Yes, provided the requirements are met – for example, for your own software, with the manufacturer’s consent, or within statutory exceptions. Within narrow limits, German copyright law allows you, for example, to observe and test how a program works (§ 69d(3) UrhG, the German Copyright Act) or to decompile it to achieve interoperability (§ 69e UrhG). We clarify the framework with you before the project starts; if in doubt, we recommend a legal review.
Which technologies can you analyze?
We review code in the common languages for web, back end, and mobile – for example, Java, C#/.NET, PHP, Python, JavaScript/TypeScript, Go, Kotlin, and Swift – as well as native code in C and C++. For reverse engineering, we analyze Windows and Linux programs, Android and iOS apps, and firmware of embedded systems, among other things. We clarify which technologies you use during scoping.
When does a code review make particular sense?
Typical occasions are major releases, new security-critical features, taking over software through an acquisition or outsourcing, due diligence reviews, and requirements from customers or regulations such as PCI DSS 4.0.1 and the Cyber Resilience Act. After a security incident, a review also helps find the root cause in the code and track down similar flaws elsewhere.
Do you also analyze malware?
Yes – as a separate service in our Incident Response & Forensics practice. In code review & reverse engineering, we assess legitimate software, apps, firmware, and protocols for vulnerabilities in a planned engagement. By contrast, if malware is found, we examine it in a malware analysis: we determine what the program can do, which servers it communicates with, and how it persists, and we derive indicators of compromise (IoCs) and detection rules for your defenses.
Related pages
Let’s talk about your software
Briefly describe your project – application type, programming languages, and approximate code size, or the binary or firmware to be analyzed. We’ll get back to you with a proposal for the right approach.