Guidance

Security considerations when coding in the open

Published 27 September 2017

Coding in the open can create better code, support collaboration, and increase engagement with your users.

You should follow the recommendations in this guide and good security practices to keep your open code secure.

Some code, such as keys and credentials, should be stored separately and remain closed. Follow the guidance on when to keep code closed if you are unsure what code to open.

Open the code early

You should code in the open from the beginning of your project rather than opening it later. By opening early, you can address security and other issues as you go along and introduce best practices from the start.

Don’t rely on closed code as your only security measure

You should use multiple countermeasures to keep your system secure, known as the ‘defence in depth’ approach. You should not rely on keeping code closed to keep it secure. This is known as security through obscurity, which is considered insufficient by security experts.

Attackers can still learn many details about your code when it is closed. By keeping your code closed, you can also introduce other risks and complications including:

• deprioritisation of code review
• additional costs and complexity of access controls

The technology team at the Ministry of Justice has explained how it has considered the risks of keeping code closed and why it works in the open.

Open code can be just as secure or more secure than closed code. For example, cryptographic algorithms are open and prove their robustness through peer review. You should consider which code should be opened.

Follow good development practices

Good development practices are important when coding in the open. For example, using clear commit messages and comprehensive documentation is always important, but becomes more so if people external to your team or organisation will be reading or using the code.

You should review your code to make sure any changes do not introduce security vulnerabilities. For example, GDS teams review code via pull requests and have documented the review process in a coding style guide. Code reviews also help to catch bugs and reduce the risk of committing sensitive data. It’s even more important to ensure code reviews are taking place when the code is open.

You must keep your dependencies up to date and have a mechanism for making changes quickly if you need to deal with a mistake or security issue. The Service Manual has more guidance on managing dependencies and deploying software regularly.

When reviewing code, you should use automated tests and style enforcement.

You could also use security scanning tools. For example, a static analysis tool such as Brakeman.

You can also use tools to attempt to catch accidental disclosure of sensitive data. For example, you can use tools such as:

• GitRob to review code at a single point in time
• Talisman to review changes before they are committed

These tools should supplement your manual code review process and not replace it. Be aware the tools can alert mistakenly, known as ‘false positives’, which need careful management.

Keep keys and credentials closed

You must keep secret data such as keys or credentials closed.

Read more about how to decide what code must be kept closed

Assume accidental publications are compromised

If you accidentally publish a secret, you must revoke it and immediately provision new keys to the system. Once a secret has been published, you must assume that it is compromised no matter how quickly you are able to remove it as attackers have automated scanning tools that will pick up credential leaks immediately.

This means you must make sure that your system allows for keys and credentials to be changed and rotated easily, and for secrets to be revoked.

Deal with security vulnerabilities

If you identify a vulnerability, you should follow the specific security and mitigation policies in your team or organisation. However, you should also follow general practices for dealing with the issue quickly.

If you discover a vulnerability as part of your usual development and test cycle, or it was reported to you through a private vulnerability disclosure process, the risk of attack is low. You should deal with the vulnerability as a normal bugfix cycle, and release after the code is committed.

If someone has publicly disclosed the vulnerability, you should consider whether you need to make an emergency fix. You should also review the vulnerable parts of the system to check for inconsistencies to determine whether the vulnerability has been exploited.

If you’re given private information about a vulnerability that affects others, it might be appropriate to make the fix privately, deploy from a private repository and merge back into the public one when safe to do so. This will avoid putting other teams or systems at risk by leaking the information before it is made public.

You should never close an open repository. Once the code is public, it’s likely that users will make their own copies. By closing the code, you may draw attention to the issue and it may not be resolved as quickly.