Guidance

When code should be open or closed

Published 27 September 2017

You should open all new source code in accordance with point 3 of the Technology Code of Practice.

There are grounds for keeping some code closed. This guide outlines what they are and why you should open configuration and security-enforcing code.

Closed code

You should keep some data and code closed, including:

• keys and credentials
• algorithms used to detect fraud
• unreleased policy

Keys and credentials

You must keep secret data such as keys or credentials closed, as this information could allow someone to gain access to your system.

You must keep code that uses secrets away from the secrets themselves. This includes storing secret keys and credentials separately. You can then open the code while keeping the secrets closed and secure.

For example, you can use a secret management system to store and secure your secrets, but allow applications to use them where necessary. A secret management system makes sure the keys can only be accessed by authorised staff. The system also makes it easier to provide different keys for different environments and rotate keys if needed.

Follow the guidance on dealing with security vulnerabilities if you accidentally expose a secret.

Fraud detection algorithms

You should close any algorithms you use to detect fraud. You should also separate any code using them from the algorithms themselves. The separation will make it easier for you to update the algorithms as you learn more about the attempts to defraud your system.

The Service Manual provides further guidance on protecting your service against fraud.

Unreleased policy

If the code makes clear details of a policy that has not yet been announced, you should keep the code closed until the policy is announced.

However, you must develop the code as if it’s already open and continue to follow good development and security practices. You must open the code as soon as possible after the policy is announced.

Open code

You should open all other code. This includes:

• configuration code
• database schema
• security-enforcing code

The Service Manual contains more guidance on making code open and reusable.

Configuration code

You should open any configuration code as long as it does not contains keys or credentials. For example, the GOV.UK Puppet code is open.

Whether your configuration code is open or closed, you must keep your dependencies up to date. Potential attackers will know which vulnerabilities you are susceptible to if you do not update your dependencies. This applies even if your code is closed as there are many ways to find out what versions of dependencies you are using without access to the code.

The Service Manual has more guidance on how to manage software dependencies.

Database schema

Unless your database schema contains credentials it is not sensitive and can be open. You should store any credentials separately and keep them closed.

Security-enforcing code

You should open security-enforcing code. Open code can still be secure. For example, Keycloak, a widely-used identity and access management solution, is Open Source and the code is available on GitHub.

Most cryptographic standards are developed in the open by standards authorities. The US National Institute of Standards and Technology (NIST) concluded a 9-year process from open competition to standardisation for the SHA-3 cryptographic hashing algorithm.

A good analogy is that of a padlock. Everyone knows how a padlock works, but it’s still secure because you cannot open it without the key. Security-enforcing software, such as RSA, works in the same way. Good cryptographic algorithms have been reviewed by many professional peers and prove their security through public review.

You should consider using a third-party library for authentication. A third-party library will be more secure and robust than one you might build yourself. It’s still secure to open your code when you use a third-party authentication library.

If you’re building a service and think your security-enforcing code needs to be closed, you’ll have to explain why in your service assessment.

You should also follow security best practices when coding in the open.