Secure development and deployment guidance

This is a problem for security because complexity hides bugs, some of which may result in security vulnerabilities.

An attacker only needs to find one way into your system. As the defender, you must try to find and mitigate them all. This task gets harder as your codebase grows in size and complexity, but you can minimise this effect by writing clean code.

If you created a flow graph of your code components, would it resemble a clean London underground tube map, or a complex mashup of spaghetti lines? The former is the goal.

A well thought out software architecture and consistent coding style will help your code base to be readable and maintainable. Code should be written in such a way that it is self documenting. Supplementary material, which is simple to understand, should be maintained alongside the system as it evolves.

Documenting a specification before writing code can help to reduce the complexity of the code itself, and a machine-readable specification can even be used to check the correctness of code automatically.

Sources of complexity

Understand the sources of complexity and try to avoid them:

• unstructured software architectures
• vague naming of coding primitives such as classes, methods, functions and variables
• confusing file naming conventions and folder structures
• inconsistent code layouts and styles developing as contributors use their own individual styles and conventions
• lack of additional supporting documentation (for example inline code comments, specifications, or system design documentation)
• writing code without thinking about how it can be tested or checked for correctness

Having well-defined coding standards and a culture that enforces them means that a readable and logical code base can be maintained as your system develops.

Writing defensive code will be easier to achieve, security mistakes easier to spot, and issues, once identified, will be easier to fix. Following the advice outlined in this document will provide benefits that are not limited to security.

Peer-reviewing code

Having two or more people review code will increase your confidence in the quality and security of your product before release. This process should be enforced within your deployment pipeline to help reduce the likelihood of damaging code changes being pushed to your production environment.

Any issues identified should be followed through with a fix. Remember, individuals can also review their own code, which can often save time before another person looks over it.

When reviewing code, you should consider:

• Who performs the review?
  Does the person performing the code review have the correct security skills and knowledge of the system?
• What is being reviewed?
  Try to avoid parts of your code being missed during review. It's easy to overlook issues in a large code base. This can be achieved by using small and regular code commits with comments or supporting analysis tools. Following a checklist of things to look for may help.
• How are reviewers incentivised?
  Is the reviewer given the time to perform a meaningful review, or is there pressure to meet release deadlines? Is the reviewer blamed when issues are found that delay a release?

External dependencies

The code that you often write only makes up a small fraction of the total code base that represents your system. Third party coding frameworks and libraries also need to be considered in the same light as the code you author. If third party components are themselves vulnerable, this is likely to also impact your system.

There is no easy way to mitigate the risks of third party code, but asking these questions may help:

• If there is a security vulnerability in the third party components of your code, what security impact may this have on your system?
• Is the dependency actively developed and maintained?
• If a vulnerability is found in one of your dependencies, would you know? Who would fix it?
• Are you using any old versions of third party code known to contain security vulnerabilities?
• Do you know anything about the author and maintainer of the dependency? How do they view and approach security?
• Does the dependency have any history of security vulnerabilities? What's important here is not necessarily that issues are discovered, but how they are handled.
• If third party code is dynamically included into your product during the build or deployment process, can you ensure that it can't be maliciously modified? You could achieve this by verifying its origin and integrity, for example.
• If the third party dependency you are using is configurable, consider disabling or removing unneeded functionality which may widen the attack surface of your product.