© Crown copyright 2017
This publication is licensed under the terms of the Open Government Licence v3.0 except where otherwise stated. To view this licence, visit nationalarchives.gov.uk/doc/open-government-licence/version/3 or write to the Information Policy Team, The National Archives, Kew, London TW9 4DU, or email: email@example.com.
Where we have identified any third party copyright information you will need to obtain permission from the copyright holders concerned.
This publication is available at https://www.gov.uk/government/publications/open-source-guidance/when-code-should-be-open-or-closed
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.
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.
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.
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.
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.
Unless your database schema contains credentials it is not sensitive and can be open. You should store any credentials separately and keep them closed.
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.