A Security Code Review (SCR) is probably the single-most effective technique for identifying security flaws in your code. When used together with automated tools and manual penetration testing, a code review can significantly increase the cost effectiveness of an application security verification effort.
If you build or buy security critical software, deal with medical, financial or other highly confidential or privacy-sensitive information, a manual code review provides you with the corresponding high security assurance level.
When building software, security vulnerabilities are invariably introduced. Many of which cannot be discovered (or are very hard to discover) without looking at the source code. On top of that a manual code review is much more effective for many types of vulnerabilities than automated vulnerability scans and dynamic (pen)testing. To give an example, testing for SQL-injection vulnerabilities via scanning or fuzzing is a really bad choice if source code can be provided as well. In this case a code review is faster, more accurate and provides you with better recommendations. With a code review you can answer questions such as: Is the design of the environment actually secure? Are you doing good? How can you use it to improve organizational goals? What is the root cause of the issue, and what is the best way to fix it structurally? In our recommendations developers will be pointed to the right file and line number.
There is no bad time to conduct a code review! We review applications that have been in production for years, go to production the next day, or are still under heavy development. Preferably a code review is done early, when changes can still be applied and tested easily. A code review can be cut into pieces easily. A quick code check in between to prevent dramatic design/code issues early, and a final check at the end for a full security sign-off.
Catch vulnerabilities in the early stages of your SDLC, while still easy and cheap to fix. Don't wait until the last minute to discover them: who will be able to understand where and how to fix security bugs then? If you’re in the early stages of development, it helps set the team on the right path for the rest of the code that they have to write. A Security Code Review provides a great value for development teams since it provides highly detailed bug/flaw descriptions and recommendations - You did this at line 251 of file.java, which could be exploited as follows... We recommend you to change this code to... -
Many key security controls can only be properly verified via a manual code review. From our experience we learned that most of the high/critical issues we identify during our reviews are not discovered by static code analysis (SCA) tooling. These often include logical flaws, such as missing or broken authorization checks, or issues that are too application-specific for SCA to find. A manual code review reveals the application's internal architecture, context and data flows needed to pinpoint such issues.
When properly tweaked to your specific application environment (technologies, architecture, pitfalls) SCA can be a great scalable tool for picking up simple mistakes and violation of predefined patterns. This complements and speeds up your manual code review activities.
A security code review is not about reviewing the entire code-base line by line. In general less than twenty percent of a code-base is security relevant. We have reviewed thousands of applications and have seen a tremendous amount of both really bad and great code. With this experience we recognize things fast and know exactly what we're looking for. By following our structured approach and optimizing our effort for the set security objectives and time constraint, a code review can be surprisingly efficient and affordable. It certainly will have the best added value for your application security verification investment!
During the intake (free of charge) we discuss your project and tell you more about us and our modus operandi. The main purpose is to collect all the information we need to create our proposal (plan of action).
You will receive our proposal, including a detailed overview of the activities, deliverables, planning and costs.
When the proposal is accepted, we deliver a list of all the things that need to be prepared for the testing activities.
The scheduled security testing activities will be executed in the planned time window. During the test frequent updates of findings and progress will be shared.
Once all testing activities have been executed, a findings meeting will be arranged to explain, demonstrate and discuss findings, impact and fixes.
The results of the assessment will be reported in detail. Each finding will consist of a description of the risk, instructions on how to reproduce and verify the finding, and a recommendation on how to resolve the finding or to mitigate the risk.