Secure Code Review

Developing Secure Apps

Developing secure apps starts with ensuring your code is secure

Perhaps you need to develop a new e-commerce platform. Perhaps you’re considering a new customer portal. Or perhaps your organisation needs to be able to transmit high volumes of data securely.

Whatever the reason, when it comes time to develop or upgrade your organisation’s web applications, having strongly written code is the first step towards ensuring your app will be secure.

From the outset of the Software Development Lifecycle (SDLC), you’ll be faced with a clear choice: to make use of closed-source or open-source code.

In this blog we’ll examine the pros and cons of both options and the importance of incorporating Secure Code Reviews from the earliest stages of the development pipeline.

Depending on the complexity of the web app you’re developing, a review could be as simple as a colleague looking over your code. However, when developing more complex commercial applications, in which private data is being transmitted, a professional Secure Code Review is essential. Having experts review your code, both at the early stages and throughout the project, after major releases or automatically on code commits, significantly improves the chances your final product will be a secure web application.

Secure Code Review

Closed-Source Code

For many organisations, the default choice when it comes to app and software development is closed-source code.

There are a variety of reasons why closed-source code can be a good choice for many organisations.

  1. QUALITY: Closed-source code tends to be developed to a high standard. As a product developed with commercial imperatives in mind, closed-source code writers naturally seek competitive advantages by updating their code and adding additional functionality. Given they are likely providing customer support, they have an interest in writing it well.
  2. COMPLIANCE: There is a tendency for closed-source code developers to align their code with a range of compliance standards. Many organisations have compliance obligations that determine how they handle and store data. Whilst open-source code may meet these requirements, often closed-source providers guarantee their product complies with certain security standards. This can make life much easier when developing an app that needs to align with specific compliance standards.
  3. SUPPORT: When purchasing closed-source code, it usually comes with developer support for a period of time. This can be extremely beneficial while building your application. Any questions or challenges you experience with the code can be addressed by the developer. Of course the level of customer support will vary between providers, but reputable code suppliers should offer prompt support to customers.
  4. SECURITY: When embarking on the process of developing an app, many organisations will be swayed by the notion that proprietary closed-source code must be more secure than free, open-source code. Having been developed in a corporation by a team of professional code writers, often with the funds to use security tools and employ security professionals, closed-source code usually undergoes extensive quality assurance vetting. In theory, this should help significantly reduce the number of vulnerabilities or bugs in the code. While such claims are hotly contested by advocates of open-source code, purchasing closed-source code from a reputable developer, who can be clearly identified and contacted in the event of any problems, gives many app builders a greater sense of security.

Should you decide to go down the closed-source route, it’s important to remember that only the original authors have complete access to view and alter the code. Typically, you don’t usually purchase the source code outright, rather you pay a license fee to access and use it. That could turn out to be a problem as you will be wholly dependent on the developers should any problems with the source code manifest.

In the event that you find vulnerabilities in the code, responsibility to fix them rests with the code’s authors, not you as the final user. While this can be a good thing, as the onus of responsibility isn’t yours, there’s no guarantee the vendors will be able to patch vulnerabilities quickly. With proprietary code, there may only be a small team of developers working on the project. Capacity constraints can mean patches are slow to be rolled-out. With only one place for you to go for support, patching and functionality enhancements, you’re essentially locking yourself in. If the vendor doesn’t fix bugs in a timely manner, you could be putting your entire web app project at risk as you’re totally reliant on a single supplier’s code.

Open-Source Code

When it comes to open-source code, some organisations are inclined to avoid it on the basis that it is free, and thus perceived as inferior. However this perception is not correct. Open-source code is ‘free’ in the sense of ‘free speech’.

The move towards opening up source code to the public started in reaction to frustrations developers faced with the restrictive practices of corporations who followed the proprietary model. Many companies refused to provide users with the ability to view or alter their source code, limiting developers in their capacity to adapt software to meet their specific requirements.

For Richard Stallman, a software programmer at the Massachusetts Institute of Technology, the problems posed by closed-source code became untenable. In the 1980s, Xerox had supplied Stallman’s department with a free prototype Xerox printer. The printer was prone to paper jams. Stallman, who had access to the source code, was able to write a simple script notifying the person waiting for documents that the printer was jammed and they should walk down the corridor to fix it. That simple work-around ensured people weren’t left for long periods of time waiting for their documents. However, one day Xerox sent a newer printer to Stallman’s department. It too was prone to paper jams, but this time Xerox refused to supply the source code. Stallman couldn’t write his simple script.

The experience was instrumental in convincing Stallman of the benefits of open-source code. Opening-up the source code didn’t deprive the people who developed the code of anything, yet it could enable code enhancements that would benefit everybody.

Stallman went on to developed a suite of free software tools, known as the GNU project. By 1991 he had teamed up with another programmer, Linus Torvalds, who had developed Linux. Together, GNU/Linux became the world’s first completely free and open-source computer operating system. 

Free-market economist, Friedrich Hayek, had long espoused the concept of the ‘Knowledge Problem’ in which no one individual, or even group of well-informed individuals, could ever have enough knowledge to plan a market. This same principle drove the advocates of open-source code. The knowledge bank in any corporation, even large ones like Xerox, Microsoft or Unix, could never compete against the vast collective knowledge of thousands of individuals. Source code was viewed as a shared resource. However, unlike other shared resources, it avoids the ‘Tragedy of the Commons’ problem. Whereas most shared resource are depleted the more they are used, source code becomes more valuable as it is used, because thousands of individuals contribute improvements to it and develop fixes whenever bugs are discovered. 

From a security point of view, the great advantage of open-source code is the more people inspect and use the code, the greater the chance that any vulnerabilities are identified and fixed promptly. 

Given enough eyeballs, all bugs are shallow

This principle became known as ‘Linus’s Law’ and was described in Eric Raymond’s seminal 1999 book ‘The Cathedral and the Bazaar’.

Raymond identified two competing approaches to development:

  • Cathedral approach: This was a conventional, closed development style. It included tight specification of objectives, small development teams, with the entire project run in a fairly hierarchical and authoritarian manner. This approach was also characterised by long release intervals.
  • Bazaar approach: This was a decentralised approach with a strong emphasis on peer to peer reviews. It involved constant solicitation of feedback from people who were formally outside the development project. The approach was characterised by very short release intervals.

For advocates of the Bazaar, or open-source approach, trading away the proprietary advantages of the closed-source approach was justifiable as it resulted in the very significant advantage of massive independent peer review. Having large numbers of independent people checking the code on an ongoing basis, ultimately resulted in superior code.

The notion that open-source code would be messy, inconsistent, vulnerable or inelegant, turned out to be incorrect. Open-source code projects still had a small team of core developers. These people acted as gatekeepers in order to filter the contributions and patches of the outside public and maintain the architectural integrity of the project.

There are a number of ways open-source code can be monetised. Some companies, such as Red Hat, enable customers to access code free of charge, but then charge for customer service. Other companies offer code for a license fee but allow the licensee the freedom to change the code as they see fit.

The core business case behind open-source is that real value isn’t derived from the code itself, but the way the code can be used to enable other commercial activities. Everyone therefore benefits when the code is regularly enhanced.

The major concern regarding open-source is that hackers have as much opportunity to inspect and scrutinise the code as anyone else. This may enable them to identify and exploit vulnerabilities before the general public has an opportunity to develop patches. Heartbleed and Shellshock are examples of two vulnerabilities that were discovered in code many years after the code was released. Some believe that the ‘many eyeballs’ theory falls short because only relatively few of those people have the time, skills and motivation to fix code, some of which has been in the public domain for many years.

Why you need a Secure Code Review

Whether you opt for using closed-source or open-source code, a Secure Code Review should be an integral part of your development lifecycle.

It is much less expensive to build a secure app than to retroactively fix security issues after completion. Some estimations suggest that implementing patches to remedy vulnerabilities is 60x more expensive than building-in security from the outset. This of course does not take into consideration the potentially devastating costs your organisation can face in the event of a serious security breach.


Code reviews are one of the most cost-effective ways to prevent vulnerabilities and help ensure your project is secure. A code review can be as simple as giving your code to a colleague to look over before implementation. It should be noted however that this approach may not be rigorous enough if the code you are using is complex.

At Shearwater, our methodology when conducting a Secure Code Review is multifaceted and includes both automated and manual investigations.

    To start, our team of experts will conduct a rigorous process of information gathering. This is the time when we gain a broad understanding of the context of the application, its business functions and any potential security concerns.
    To start, our team of experts will conduct a rigorous process of information gathering. This is the time when we gain a broad understanding of the context of the application, its business functions and any potential security concerns.
    Using Static Application Security Testing (SAST) scanning tools, such as Fortify, or Secure Code Analysis (SCA) tools, like OWASP Dependency Checker, our experts will interrogate the code for a wide range of common vulnerabilities. This includes examining source code from a multitude of languages and frameworks, such as Java, .Net, Python, Node.js and Ruby, regardless of whether they’re compiled or uncompiled. Automated scans can identify classes of vulnerabilities that occur regularly in code, such as injections.
    Also known as ‘Code Crawling’, a manual review is when our team of experts physically read the code base. We do this in order to locate and analyse potential vulnerabilities in areas of the application code that are likely to have security implications, and that may not be picked up during automated scans.

The key to successful code reviews is to begin in the early stages of the development pipeline, known as the ‘Shift-Left’ approach. Start by conducting code reviews at the beginning of the journey and ensure that your development team are trained in good code hygiene practices. At each stage of the development lifecycle, ensure that code is regularly reviewed.

By the time you come to the final stages of developing your app, have a 3rd party independently review the code again. It’s important to have this independent oversite. A fresh pair of eyes may identify vulnerabilities that had been missed.

Security Code Review in the SDLC

Source: OWASP:

How Shearwater can help you?

Integrating Security Code Reviews into your System Development Lifecycle (SDLC) can ensure the quality of your code, and the security of your application, are significantly enhanced.

Shearwater’s methodology for conducting Secure Code Reviews complies with industry best practice and combines both automated and manual investigations. We can also train your development team on the best ways to develop securely. 

A Secure Code Review should be seen as one of the layers in a defence-in-depth approach to app security.

For further information on Secure Code Reviews, Contact Shearwater today.