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. 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.
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 -
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.
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.