Security Code Review

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

OWASP Foundation

Security critical applications deserve a manual code review!

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.


The power of a code review.

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 way more efficient for many types of vulnerabilities than 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. Are you really doing good, how can you improve, what's the root-cause of the issue and how can it be fixed (developers can be pointed to the right file and line-number).

When to code review?

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 inbetween to prevent dramatic design/code issues early and a final check at the end for full security sign-off.

Catch vulnerabilities early in your SDLC.

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

What about code scanning tools?

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.

More affordable than you think.

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!

A Security Code Review (SCR) is probably the single-most effective technique for identifying security flaws in your code.

How we work

  • 1

    Intake

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

  • 2

    Offer

    You will receive our proposal, including a detailed overview of the activities, deliverables, planning and costs.

  • 3

    Preparation

    When the proposal is accepted, we deliver a list of all the things that need to be prepared for the testing activities.

  • 4

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

  • 5

    Findings meeting

    Once all testing activities have been executed, a findings meeting will be arranged to explain, demonstrate and discuss findings, impact and fixes.

  • 6

    FInal report

    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.

Work with us →